On Mon, Feb 02, 2004 at 12:40:45PM -0800, Larry Wall wrote:
> On Fri, Jan 30, 2004 at 06:16:06PM +, Tim Bunce wrote:
> : In Java you would write "java.lang.String", naturally, and in Perl
> : you'd write "parrot::java::java.lang.String".
>
> That's okay if it's a string being interpreted by the
On Fri, Jan 30, 2004 at 06:16:06PM +, Tim Bunce wrote:
: In Java you would write "java.lang.String", naturally, and in Perl
: you'd write "parrot::java::java.lang.String".
That's okay if it's a string being interpreted by the appropriate
code, but as a Perl 6 name it won't wash. That's gonna
On Thu, Jan 29, 2004 at 09:16:33AM -0800, Jeff Clites wrote:
>
> >Then the question becomes, "What about namespace clashes?", which Tim
> >has already addressed.
>
> We could certainly do some sort of language-specific prefixing, as Tim
> suggested, but it seems that we are then going to troubl
Jeff Clites writes:
> We could certainly do some sort of language-specific prefixing, as Tim
> suggested, but it seems that we are then going to trouble to unify,
> only to immediately de-unify. Certainly, a random Java programmer
> shouldn't have to worry about naming a class so that it doesn't
On Jan 28, 2004, at 6:42 AM, Peter Haworth wrote:
On Thu, 15 Jan 2004 23:00:53 -0800, Jeff Clites wrote:
I think we shouldn't try to do any sort of cross-language unification.
That is, if we some day have a Parrot version of Java, and in Perl6
code I
want to reference a global created inside of s
On Thu, 15 Jan 2004 23:00:53 -0800, Jeff Clites wrote:
> I think we shouldn't try to do any sort of cross-language unification.
> That is, if we some day have a Parrot version of Java, and in Perl6 code I
> want to reference a global created inside of some Java class I've loaded
> in, it would be c
I've used non-hierarchical file systems in the distant past, and
it wasn't pleasant. I think aliases (symlinks) work much better in
a hierarchy. So do inner packages, modules, and classes, which we
plan to have in Perl 6. And package aliasing will be the basis for
allowing different versions of
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 12:49 PM +0100 1/16/04, Leopold Toetsch wrote:
>>
>>find_global P1, P2 ['global'; 'namespace'; 'hierarchy'; "thingname" ]
> No. The thing will be a separate parameter.
Why? Nested keys get you down the key chain until there is no more key.
This can
At 11:07 AM + 1/16/04, Tim Bunce wrote:
Here's my proposal:
I like it all except for the backlink part, and that only because I'm
not sure the names are right. I'm tempted to use reasonably
unavailable characters under the hood (yeah, I'm looking at NUL
(ASCII 0) and maybe SOH (ASCII 1) for
At 11:00 PM -0800 1/15/04, Jeff Clites wrote:
A key part of my argument (and it's find if you understood this, and
disagree--just wanted to make sure that it was clear) is that I
think we shouldn't try to do any sort of cross-language unification.
I saw that and wasn't really looking to deal with
At 12:49 PM +0100 1/16/04, Leopold Toetsch wrote:
Tim Bunce <[EMAIL PROTECTED]> wrote:
Here's my proposal:
* Basics:
Parrot uses nested hashes for namespaces (like perl does).
* Relative roots:
Namespace lookup starts from a 'root' namespace (think root directory).
Here the P2 argument h
On Fri, Jan 16, 2004 at 12:49:09PM +0100, Leopold Toetsch wrote:
> Tim Bunce <[EMAIL PROTECTED]> wrote:
> > Here's my proposal:
>
> > * Basics:
>
> > Parrot uses nested hashes for namespaces (like perl does).
>
>
> > * Relative roots:
>
> > Namespace lookup starts from a 'root' namespace (thin
Tim Bunce <[EMAIL PROTECTED]> wrote:
> Here's my proposal:
> * Basics:
> Parrot uses nested hashes for namespaces (like perl does).
> * Relative roots:
> Namespace lookup starts from a 'root' namespace (think root directory).
> Here the P2 argument holds the root namespace to start the lookup
Here's my proposal:
* Basics:
Parrot uses nested hashes for namespaces (like perl does).
The high-level language splits namespace strings using whatever
its separator is ('::', '.' etc) to generate an array of strings
for the namespace lookup.
* Relative roots:
Namespace lookup starts from a
Jeff Clites writes:
> On Jan 15, 2004, at 8:26 PM, Benjamin K. Stuhl wrote:
>
> >Thus wrate Dan Sugalski:
> >>At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
> >>>Short version: I was originally going to argue for fully
> >>>hierarchical namespaces, identified as above, but after turning this
> >>
On Jan 15, 2004, at 8:26 PM, Benjamin K. Stuhl wrote:
Thus wrate Dan Sugalski:
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
Short version: I was originally going to argue for fully
hierarchical namespaces, identified as above, but after turning this
over in my head for a while, I came to the co
On Jan 15, 2004, at 9:52 AM, Dan Sugalski wrote:
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
Here are some notes on namespaces, picking up a thread from about a
month ago:
On Dec 11, 2003, at 8:57 AM, Dan Sugalski wrote:
That does, though, argue that we need to revisit the global access
opco
Thus wrate Dan Sugalski:
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
Short version: I was originally going to argue for fully hierarchical
namespaces, identified as above, but after turning this over in my
head for a while, I came to the conclusion that namespaces are not
conceptually hierarch
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
>> Here are some notes on namespaces, picking up a thread from about a month ago:
>>
>>> That does, though, argue that we need to revisit the global access
>>> opcodes. If we're goin
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:
Here are some notes on namespaces, picking up a thread from about a month ago:
On Dec 11, 2003, at 8:57 AM, Dan Sugalski wrote:
That does, though, argue that we need to revisit the global access
opcodes. If we're going hierarchic, and we want to sepa
20 matches
Mail list logo
