be able to use 'get_pmc_keyed' here,
* but we can't because Parrot's default namespaces are not
* fully typed and there's a pseudo-typed interface that
* distinguishes 'get_pmc_keyed' from 'get_pointer_keyed';
* the former is for NS and the latter is for non-NS.
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46157]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46157 >
In src/global.c:internal_ns_keyed() there is the todo item:
/* TODO - stop depending o
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45983]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45983 >
In src/objects.c:parrot_class_register() there is the todo item:
/* XXX try HLL namesp
On Friday 17 August 2007 04:24:10 Badai Aqrandista wrote:
> Changed [ 'Test::More' ] to [ 'Test'; 'More' ]
Thanks, applied as r20648.
By the way, the justification for this is that PDD 15 says (or at least
should) that the proper approach to namespace nesting is to use keys, not
n-delimited st
On Thursday 16 August 2007 15:50:25 Badai Aqrandista via RT wrote:
> Sorry I just read the docs/submissions.pod and realized I shouldn't
> have submit the patch here. I'll resubmit it in proper way to
> parrotbug.
It's fine here; don't worry.
-- c
Hi,
Sorry I just read the docs/submissions.pod and realized I shouldn't
have submit the patch here. I'll resubmit it in proper way to
parrotbug.
--
Thanks,
Badai Aqrandista (cheepy)
Changed [ 'Test::More' ] to [ 'Test'; 'More' ]
Patch level 1
Source: 4c149bba-1ebb-4b29-940e-6c2cefc7587e:/parrot/local:599
Target: d31e2699-5ff4-0310-a27c-f18f2fbe73fe:/trunk:20643
(https://svn.perl.org/parrot/trunk)
Log:
[EMAIL PROTECTED]: cheepy | 2007-07-14 05:14:58 -0400
Cre
Hi chromatic,
Thanks for your prompt reply.
> The main change is to change all instances of [ 'Test::More' ] and the like to
> [ 'Test'; 'More' ].
Can you point to a document or a thread that explains about why this
change needs to happen?
I'm at work now. I'll work on it tonight.
--
Thanks,
On Wednesday 15 August 2007 13:42:39 Badai Aqrandista wrote:
Hi Badai,
> I'm new to the list. I'm a Perl Programmer doing web development in my
> day job and I'd like to help. I'll try to commit an hour or two per
> day to parrot project.
Welcome!
> Can you let me know what I should do to get t
Please include the string: [perl #44663]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=44663 >
>
>
> The Test::More namespace uses 'Test::More' instead of [ 'Test'; 'More' ].
#x27;More' ]. I
prefer the latter, now that nested namespaces work. The test modules and all
code which uses them needs to change to follow this example.
This should take about 20 minutes for a motivated CAGE cleaner. If no one
gets to it on the bug day, I'll do it.
-- c
On Saturday 17 February 2007 08:42, Allison Randal via RT wrote:
> On Thu Jan 11 09:58:32 2007, [EMAIL PROTECTED] wrote:
> > I've held off on applying it because Allison said we need a
> > deprecation cycle
> > for the name() -> get_name() rename.
> I've made a note in DEPRECATED.pod that the me
On Thu Jan 11 09:58:32 2007, [EMAIL PROTECTED] wrote:
> I've held off on applying it because Allison said we need a
> deprecation cycle
> for the name() -> get_name() rename.
I've made a note in DEPRECATED.pod that the method is being renamed
(r17030). Go ahead and apply this patch immediately aft
On Thursday 11 January 2007 07:37, Jerry Gay wrote:
> i'm sending this to rt so it doesn't get lost. i want it in before
> 0.4.8 next week.
I've held off on applying it because Allison said we need a deprecation cycle
for the name() -> get_name() rename.
-- c
week.
~jerry
-- Forwarded message --
From: chromatic <[EMAIL PROTECTED]>
Date: Dec 25, 2006 1:44 PM
Subject: [PATCH] Add get_name() Method to Namespaces
To: [EMAIL PROTECTED]
Here's a patch to implement get_name(), as specified in PDD 21. I haven't
checked it
Here's a patch to implement get_name(), as specified in PDD 21. I haven't
checked it in because it includes an API change. There was already a name()
method in namespaces; I renamed it per the PDD.
-- c
=== src/int
Matt Diephouse wrote:
One common use of anonymous subs in a dynamic language is
for later exporting them into another package (or multiple different
packages). In that case, you really don't want the sub to retain a link
to its defining namespace, you want it to fully adopt the namespace it's
p
From: Allison Randal <[EMAIL PROTECTED]>
Date: Wed, 22 Nov 2006 20:37:26 -0800
Ben Morrow wrote:
>
> ...but that's just a braino on Matt's part, and his point still stands
> for the code
>
> package Test;
>
> sub apply {
> my $func = shift;
Allison Randal <[EMAIL PROTECTED]> wrote:
Okay, so we're basically solving the same problem as Perl 5's "main"
routine, which it stuffs in an obscure C variable internal to the
interpreter, not accessible from the symbol table. (Talk about
less-than-transparent introspection.)
Huh. I don't know
Matt Diephouse wrote:
Let's try this again, starting from the Tcl side of things. Tcl code
can exist outside of subroutines. This, for example, is a valid Tcl
program:
set number 5
puts $number
[...]
But things get a
little hairier when we start using namespaces in Tcl:
namespace
:main
.local pmc number
number = new .TclInt
number = 5
set_global 'number', number
say number
.end
That doesn't look too bad. This actually works and correctly stores
the "number" variable in the root HLL namespace. But things get a
little hai
Jonathan Worthington wrote:
OK, so I've added a REQUIREMENTS section to the objects PDD now and
filled it out with some (hopefully most) of what Perl 6 and .Net need as
a start.
Thanks Jonathan, it's a great start!
Allison
Allison Randal wrote:
More specifically: If you have any questions related to a PDD in clip,
please add them to a QUESTIONS section at the end of the PDD. For
requirements, use REQUIREMENTS. Neither of these sections will live in
the final version of the PDD, so it's a flag for me to process th
To wrap up (or restart) the thread, here are some thoughts from a
high-level view:
HLL classnames should live in the symbol table (i.e. namespace), not in
Parrot's internal class registry. Yes, this means PIR/POST will need
different syntax for instantiating objects from HLL classes. But the
chromatic wrote:
On Monday 23 October 2006 09:49, Jonathan Worthington wrote:
Would it be a good idea to start collecting requirements together from
different language implementors so that when the time comes to work on
the OO PDD, there is already a good description of what it needs to do?
P
Am Montag, 23. Oktober 2006 15:14 schrieb Patrick R. Michaud:
> > .HLL 'pge', ''
> > ...
> > cl = newclass 'Exp' # ['pge'; 'Exp']
> > ...
> > .namespace ['Exp'] # ['pge'; 'Exp']
> > ...
> > scl = subclass 'Exp', ['Exp'; 'Closure'] # ['pge'; 'Exp'; 'Closure']
> > ...
>
> It
On Mon, Oct 23, 2006 at 05:49:08PM +0100, Jonathan Worthington wrote:
> Allison Randal wrote:
> >>I think the object model needs a thorough going over in general
> >Yup. It's on the list right after I/O, threads, and events.
> >...
> >Ruby is a serious OO language, but it's not finished yet. For t
On Monday 23 October 2006 09:49, Jonathan Worthington wrote:
> Would it be a good idea to start collecting requirements together from
> different language implementors so that when the time comes to work on
> the OO PDD, there is already a good description of what it needs to do?
> If so, I'm happ
Allison Randal wrote:
I think the object model needs a thorough going over in general
Yup. It's on the list right after I/O, threads, and events.
-- for
the reasons above and because it's an unproven system. I'm not
convinced that it will handle all of Perl 6's needs as is. No serious
OO langu
bothers me here -- I don't think
that a subclass should have to include the name of its parent in
the class name. It should be:
scl = subclass 'Exp', 'Closure'# ['pge'; 'Closure']
However, writing either this or
scl = subclass 'Exp'
space) with all the implications for naming it.
There was some discussion re unifying namespace and class 'namespaces' but it
stalled.
The "class isa NameSpace" thingy is still undecided.
leo
ge'; 'Exp']
> ...
> scl = subclass 'Exp', ['Exp'; 'Closure'] # ['pge'; 'Exp'; 'Closure']
> ...
I strongly disagree. I don't think that a subclass should have to
be named as a sub-namespace of its pa
Am Donnerstag, 19. Oktober 2006 23:19 schrieb Patrick R. Michaud:
> So, here's the revised version of the code to create
> the classes:
>
> .HLL 'pge', ''
>
> .sub __onload :load
> $P0 = newclass 'Exp'
[...]
> $P0 = subclass 'Exp', 'Closure'
> # ...
> .end
>
>
Matt Diephouse writes:
Allison Randal <[EMAIL PROTECTED]> wrote:
Matt Diephouse wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
>> On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
>> > This is unspecced. ATM, all classes go into the 'parrot' HLL. This
is
>> > a relic of
Allison Randal <[EMAIL PROTECTED]> wrote:
Matt Diephouse wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
>> On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
>> > This is unspecced. ATM, all classes go into the 'parrot' HLL. This is
>> > a relic of the past and I think it ne
Matt Diephouse wrote:
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
> This is unspecced. ATM, all classes go into the 'parrot' HLL. This is
> a relic of the past and I think it needs to change. I'm pretty sure
> that HLL classes w
he module
directly or have to take extra steps to reach it as a module outside
your current HLL. Or, if we say you can only directly access namespaces
within your current HLL, then it's a question of whether you can access
PGE modules in the 'parrot' HLL (so in the general case you
t if the Perl 6 programmer really wants to be using
the Parrot ResizablePMCArray, it will need to be imported into
the perl6 hll_namespace somehow, or otherwise given enough details
so that perl6's 'ResizablePMCArray' class object knows that it's
the Parrot class and not the Pe
blePMCArray to use internally? Or die because there's already a
ResizablePMCArray class? Remember that no matter how much name
mangling you do in this case, there's probably a language that doesn't
want to do any.
This isn't too much different from using keyed class names like
On Thu, Oct 19, 2006 at 10:01:29PM -0400, Matt Diephouse wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> > According to pdd21, each HLL gets its own hll_namespace.
> >PGE is really a form of HLL compiler, so it should have
> >its own hll_namespace, instead of using parrot's hll namespace:
really
ought to be referring to its classes as 'Match',
'Exp', 'Literal', etc. So, if we're in the PGE HLL,
we ought to be able to drop the 'PGE::' prefix from
our classnames and namespaces.
So, here's the revised version of the code to create
the
.
After the changes introduced by pdd21, I'm lost as to how
to deal with classname conflicts when multiple HLL namespaces
are involved. I have a very real example from PGE, but bear
with me as I present some background. Also, note that I've
simplified a few details here for illustrat
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #40312]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=40312 >
[info commands] needs to support namespaces.
--
Matt Diephouse
# New Ticket Created by Matt Diephouse
# Please include the string: [perl #39833]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39833 >
Namespace support has been added to Tcl, but [rename] doesn't have it
yet. See [proc
be the
root, or that some pseudo-HLL, perhaps the default "parrot" one, should have
the root namespace as its HLL namespace.
> >> Also, is there any reason we can't/shouldn't add find_global variants
> >> that lookup globals in HLL's? Right now we ha
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
On Wed, Jun 28, 2006 at 11:40:28PM -0700, Matt Diephouse wrote:
> The get_namespace opcode gets namespaces from the root namespace.
> Should it get namespaces from the HLL namespace instead? The PDD isn't
> explicit either way [.
On Wed, Jun 28, 2006 at 11:40:28PM -0700, Matt Diephouse wrote:
> The get_namespace opcode gets namespaces from the root namespace.
> Should it get namespaces from the HLL namespace instead? The PDD isn't
> explicit either way [...]
It is, actually:
=head2 Namespace Opcodes
I've started implementing namespace support in Tcl this week (yay!).
But I've run into a bit of trouble, so I have a couple questions:
The get_namespace opcode gets namespaces from the root namespace.
Should it get namespaces from the HLL namespace instead? The PDD isn't
explicit
> [coke - Mon Jun 12 10:29:50 2006]:
>
> Need a store_global opcode that takes a multi-element NS key.
>
Implemented, plus test case.
Jonathan
# New Ticket Created by Will Coleda
# Please include the string: [perl #39425]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=39425 >
Need a store_global opcode that takes a multi-element NS key.
--
Will "Coke" Coleda
[E
On Thu, May 25, 2006 at 01:09:47AM +0100, Jonathan Worthington wrote:
> This looks pretty nice.
Sometimes "dynamic" is remarkably convenient. :-)
> 1) (Can we|Will we be able to) do the whole newclass/addattribute/addmethod
> thing at compile time (in a :immediate), so that you have your classe
27;whatever']
$P0.foo()
.end
.sub whatever_foo :anon :method
print "Foo!\n"
.end
Note that the default implementation of vtable add_method() still depends
on
public namespaces. But we can fix that. }:-)
This looks pretty nice. A couple of init
.sub whatever_foo :anon :method
print "Foo!\n"
.end
Note that the default implementation of vtable add_method() still depends on
public namespaces. But we can fix that. }:-)
--
Chip Salzenberg <[EMAIL PROTECTED]>
On May 16, 2006, at 19:32, Chip Salzenberg wrote:
There's is a problem with the naming of classes and their associated
namespaces
that must be addressed.
The first question is: why is the namespace associated, or - in other
words - why does a class C a namespace instead of C
name
{ copied to P6L for the "use case" question below }
On Wed, May 17, 2006 at 12:18:27PM -0400, Will Coleda wrote:
> My concern is that, in an effort to work around this restriction,
> each language will end up implementing a workaround to hide the
> __parrot* namespaces: the
language will end up implementing a workaround to hide the
__parrot* namespaces: these workarounds will hinder interoperability
unless they are synchronized: if they're synchronized, why not
canonicalize them and put it in the core?
That said, I'm still trying to figure out why a class
There's is a problem with the naming of classes and their associated namespaces
that must be addressed.
Creating Parrot classes currently requires _typed_ namespaces, that is,
namespaces where more than one object can have the same fully-qualified
name. Parrot's default namespace a
On Mon, Apr 17, 2006 at 04:44:10PM +0200, Leopold Toetsch wrote:
> Thinking a bit more about it (and discussing this issue with pmichaud)
> on #parrot - it seems that we really want hierarchical class names too,
> the more that a Perl6 class isa NameSpace too.
>
> That means:
>
> * newclass, su
TODOs, part 2 ("todenda"?):
[[ NAMESPACE PMC ]]
* The .name() method is being renamed to get_name() for
consistency, and to allow for the possibility of set_name().
* The return value of .get_name(), the parameter to
.get_namespace(), and the parameter to the get_namespace opcode
should al
chromatic wrote:
What should the syntax for creating new objects be? That is, if I define an
object with its methods in the namespace [ 'PAST'; 'Node' ], how do I create
a new instance of that class?
.local pmc node
node = new ???
Thinking a bit more about it (and discussin
On Apr 17, 2006, at 8:02, chromatic wrote:
What should the syntax for creating new objects be? That is, if I
define an
object with its methods in the namespace [ 'PAST'; 'Node' ], how do I
create
a new instance of that class?
.local pmc node
node = new ???
.namespace ['PAS
On Sunday 16 April 2006 22:00, Chip Salzenberg wrote:
> * standard Parrot libraries not associated with any HLL should have their
> own namespaces
>
> For example, PGE should live in a ["pge"] namespace, or, conceivably,
> under ["parrot";"PGE&qu
Based on a status report from Leo {thanks!} and my recent revisions to
pdd21, here's a list of things that need to be done to bring parrot fully
into the new world of namespaces. The items are roughly in descending order
of importance. There's room for several contrib
On Mon, Dec 05, 2005 at 04:41:21PM +0100, Leopold Toetsch wrote:
> On Dec 5, 2005, at 5:55, Matt Diephouse wrote:
> >>- perl5: sometimes (via sigil, but $ref_tosub)
> >>- perl6: maybe (sigil is part of the symbol name, but $ref)
> >
> >Functions, variables, a
On Wed, Feb 08, 2006 at 08:49:54PM +0100, Leopold Toetsch wrote:
> I'm still having troubles, when thinking about namespace PMCs and
> implementation thereof. Especially the relationship of class namespaces
> and the store_global opcode.
As well you might. :-, There's a chi
On Feb 12, 2006, at 3:07, Jonathan Worthington wrote:
The usage of the C<.namespace> directive causes the creation of a new
namespace PMC with that name. Additionally the namespace PMC is
registered
as a type. This needs a bit of additional code that prevents
instantiation
of name
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
I'm still having troubles, when thinking about namespace PMCs and
implementation thereof.
Especially the relationship of class namespaces and the store_global
opcode.
We have e.g. this PIR snippets:
.sub main :main
I'm still having troubles, when thinking about namespace PMCs and
implementation thereof.
Especially the relationship of class namespaces and the store_global
opcode.
We have e.g. this PIR snippets:
.sub main :main
cl = newclass 'Foo' # a class isa
On Jan 26, 2006, at 5:35, Chip Salzenberg wrote:
Ah yes, of *course*. PMCs have methods, and the methods need to be
found
somewhere, so the default place to look should be vtable->namespace.
Is there a problem with killing vtable->namespace_name and replacing
its
usages with the existing vt
;class? (It's currently unused)
> >
> >Beats me. Vtables don't have namespaces.
>
> Given that in P6 speak ...
>
> 00:27 < stevan> Class.isa(Package)
> 00:27 < stevan> Class.isa(Module), Module.isa(Package), Package.isa(Object)
>
> See also pugs/
On Jan 25, 2006, at 21:21, Chip Salzenberg wrote:
On Tue, Jan 24, 2006 at 05:43:25PM +0100, Leopold Toetsch wrote:
*) what is vtable->package? A pointer to the namespace PMC of this
class? (It's currently unused)
Beats me. Vtables don't have namespaces. Pleaes just commen
ge,
I gather it's an attempt at layered or translucent namespaces -- where one
namespace underlies another and is only consulted when the top one does not
contain the name being searched for. Interesting, but puzzling. Let it
live. For now.
> *) I presume that the stash_hash is
*) what is Stash.parent_stash? (It's currently unused)
*) I presume that the stash_hash is the thing, that holds the top-level
namespace.
*) what is vtable->package? A pointer to the namespace PMC of this
class? (It's currently unused)
*) what is Parrot_Context.current_package? Shoudn't that bet
On Dec 5, 2005, at 5:55, Matt Diephouse wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Of course, now that I think about it more, it's possible that nothing
else will be adding namespaces for Python.
Or: only python itself can create Python namespaces.
In which case I
On Sun, 2005-12-04 at 12:25 +0100, Leopold Toetsch wrote:
> And it doesn't answer my question at all, sorry. Which HLLs are able to
> divide their symbols into above categories?
Ah, maybe I see what you're getting at.
At compile-time, a HLL knows whether it is compiling a sub or a
variable. But
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> And it doesn't answer my question at all, sorry. Which HLLs are able to
> divide their symbols into above categories? Further: as this proposals
> deals with the managment of namespaces, a special typed interface for a
> '
t; - ???
LISP - yes
Matt
Actually, it's "yes" for Common Lisp, and "no" for Scheme. But there's
a bit more to it than that: Namespaces in Common Lisp map a name
(string) to a symbol, which is the object that holds the name's global
function and/or va
;> implementation of "import_into" as a way for the source HLL to tell
> >> the
> >> target HLL whether to treat each name as a sub, namespace, variable or
> >> method.
> >
> > Yes, that's correct.
>
> And it doesn't answer my question a
r symbols into above categories? Further: as this proposals
deals with the managment of namespaces, a special typed interface for a
'namespace' symbol name seems not to be necessary, because if it
weren't evident, where a namespace is used, we couldn't deal with
namespaces
Roger Browne <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
>
> > > add_sub($S0, $P0)
> >
> > > add_namespace($S0, $P0)
> >
> > > add_var($S0, $P0)
> >
> > Which HLLs would use these interfaces?
>
> Maybe I'm missing the point, but I see these being used in the
> implementation of
Leopold Toetsch wrote:
> > add_sub($S0, $P0)
>
> > add_namespace($S0, $P0)
>
> > add_var($S0, $P0)
>
> Which HLLs would use these interfaces?
Maybe I'm missing the point, but I see these being used in the
implementation of "import_into" as a way for the source HLL to tell the
targe
On Dec 2, 2005, at 7:31, Matt Diephouse wrote:
Typed Interface
add_sub($S0, $P0)
add_namespace($S0, $P0)
add_var($S0, $P0)
Which HLLs would use these interfaces? Can you please provide some
examples of HLLs with the usage of these interfaces.
Thanks,
leo
On Dec 2, 2005, at 19:44, Matt Diephouse wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
I'm missing the policy in this proposal, e.g. what is allowed to be a
top-level global, how are HLL namespaces organized. And of course:
where is the Parrot namespace for it's PMCs.
Roger Browne <[EMAIL PROTECTED]> wrote:
> > HLL Private Namespaces
> > HLLs should use a namespace with an underscore and the lowercased
> > name of the HLL to store any private items. For instance, Tcl should
> > use the "_tcl"
On Fri, 2005-12-02 at 01:31 -0500, Matt Diephouse wrote:
> import_into($P0, ...)
> Import items from the current namespace into the namespace in $P0.
It might be clearer to change the name to "export_into", because it is
being called on - and controlled by - the source:
source_nam
> HLL Private Namespaces
> HLLs should use a namespace with an underscore and the lowercased
> name of the HLL to store any private items. For instance, Tcl should
> use the "_tcl" namespace to store the subroutines that make up the
>
Roger Browne <[EMAIL PROTECTED]> wrote:
> 1. LANGUAGES AND NAMESPACES
>
> In my previous messages, I was concerned that languages were being
> shoehorned too tightly into their own namespaces.
>
> But after a careful reading about "import_into", I am happy t
1. LANGUAGES AND NAMESPACES
In my previous messages, I was concerned that languages were being
shoehorned too tightly into their own namespaces.
But after a careful reading about "import_into", I am happy that each
language has sufficient ability to insert its symbols into the na
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> On Dec 2, 2005, at 7:31, Matt Diephouse wrote:
>
> [ Just a few notes, more to come. I've to read it some more times. ]
>
> > Naming Conventions
>
> > HLL Private Namespaces
> > HLLs sh
On Dec 2, 2005, at 7:31, Matt Diephouse wrote:
[ Just a few notes, more to come. I've to read it some more times. ]
Naming Conventions
HLL Private Namespaces
HLLs should use a namespace with an underscore and the
lowercased
name of the HLL to store any private
On Fri, Dec 02, 2005 at 11:50:15AM -0500, Matt Diephouse wrote:
> With that in mind, there are two possible ways to name namespaces and
> compilers:
>
> 1. Lowercase or uppercase them all. The Pugs code works with little or
> no effort.
And always use Unicode Normalised form C?
Nicholas Clark
jerry gay <[EMAIL PROTECTED]> wrote:
> On 12/1/05, Matt Diephouse <[EMAIL PROTECTED]> wrote:
> > User Defined Namespaces
> > All HLLs should prefix any namespaces with the lowercased name of
> > the HLL (so there's no question of what to ca
yay! your hard work shows... this was worth waiting for. i'm going to
be like everyone else and say this will take some time to digest, but
i have a question now.
> Naming Conventions
> For interoperability, languages should use hierarchical namespaces.
> There's no way to
ne
relationship with languages.
I was expecting Parrot to force code generating tools to specify the
namespace they want to work in.
I'm probably looking at this far too simplistically but I was expecting to
read something like this.
Naming Conventions
For interoperability, languages will
code-generating tools that
have the potential to mess about with data - and those tools don't
necessarily have a one-to-one relationship with languages.
Consider, for example, Perl 6.0 and Perl 6.1 - they will almost
certainly use namespaces in a compatible way - but there is no way that
Par
o digest all that, but
> already I have a question:
>
> > Synopsis
> > - Languages should contain their namespaces
>
> Suppose my application is multi-HLL. For example, some parts of it are
> written in Python and some in Ruby. Suppose I take one small part that
> is wr
Thanks Matt and Chip. It's going to take a while to digest all that, but
already I have a question:
> Synopsis
> - Languages should contain their namespaces
Suppose my application is multi-HLL. For example, some parts of it are
written in Python and some in Ruby. Suppose I tak
should contain their namespaces
- Namespaces should be hierarchical
- Add a get_namespace opcode (that takes an array or a multidimensional
hash index)
- Namespaces follow the semantics of the HLL in which they're defined
- Imports follow the semantics of the library&
Tim wrote:
Seems like the last major thread on namespace issues, especially
inter-language issues, was around October last year and didn't reach
any firm conclusions.
What's the current status?
Pretty much the same. There is now an additional namespace
"__parrot_core", where MMD subroutines are ga
Seems like the last major thread on namespace issues, especially
inter-language issues, was around October last year and didn't reach
any firm conclusions.
What's the current status?
Tim.
1 - 100 of 234 matches
Mail list logo
