On Thu, 2006-07-06 at 09:09 -0700, Larry Wall wrote:
> On Thu, Jul 06, 2006 at 10:40:21AM -0400, Audrey Tang wrote:
> : The : form is approved and canonical (line 303, the Modules spec, aka
> : S11.pm version 14).
> :
> : use perl5:DBI;
[...]
> : my $dbh = perl5:DBI; # currently parsed a
On Thu, Jul 06, 2006 at 09:09:08AM -0700, Larry Wall wrote:
: use **perl5::DBI;
which, if you don't like the two-character form, you can spell:
⁑perl5::DBI
:-)
Hmm, hmm, speaking of sanity, how 'bout user-defined sigils and twigils:
sigil ¢ = Capture;
twigil ¬ = "NOTREALLY::";
On Thu, Jul 06, 2006 at 10:40:21AM -0400, Audrey Tang wrote:
: The : form is approved and canonical (line 303, the Modules spec, aka
: S11.pm version 14).
:
: use perl5:DBI;
:
: However, currently it's only available at use/require line.
: Afterwards, the user simply say:
:
: my $db
在 2006/7/6 上午 3:30 時，Allison Randal 寫到：
Quick question, is there a syntax specified in Perl 6 for referring
to namespaces from other languages?
I'm reviewing the namespaces PDD and want to update this snippet:
--
IMPLEMENTATION EXAMPLES: Suppose a Perl program were to import some
Tcl m
On Fri, Jun 30, 2006 at 10:50:58PM -0700, Matt Diephouse wrote:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> >On Wed, Jun 28, 2006 at 11:40:28PM -0700, Matt Diephouse wrote:
> >> Tcl uses C< .namespace [''] > to refer to the root namespace (correctly,
> >> I think) and I can't think of any langua
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 [...]
It is, actually:
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
Note that all n
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
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"]. In any case, the current double colons a
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, and namespaces _are_ separate here. Don'
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 namespaces.
Ho
"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
cl = newclass 'Foo' #
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'd advocate
havin
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
> 'namespace' symbol name seems not
From: Matt Fowles <[EMAIL PROTECTED]>
Date: Sun, 4 Dec 2005 12:35:24 -0500
. . .
On 12/4/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> . . . Which HLLs are able to
> divide their symbols into above categories? . . .
>
> Remaining for me is the distiction between a
Leo~
On 12/4/05, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> On Dec 4, 2005, at 5:57, Matt Diephouse wrote:
>
> > Roger Browne <[EMAIL PROTECTED]> wrote:
> >> Leopold Toetsch wrote:
> >>
> add_sub($S0, $P0)
> >>>
> add_namespace($S0, $P0)
> >>>
> add_var($S0, $P0)
> >
On Dec 4, 2005, at 5:57, Matt Diephouse wrote:
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 th
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.
I don't think I f
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" namespace to store the subroutines that ma
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 that each
> language has sufficient abilit
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 namespace
of anothe
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 should use a namespace with an underscore and the
> > l
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 items.
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 capitalize). So Perl 5's
> > CGI
On 12/1/05, Matt Diephouse <[EMAIL PROTECTED]> wrote:
> After many months and lots of work, I'm happy to present you with the
> latest namespace spec draft. Comments are most welcome: to quote Chip,
> "The rest of the discussion would benefit from more eyes."
>
yay! your hard work shows... this was
> As I see it, HLLs are just languages, and it's not the _language_
> that "stamps all over" the data. It's really the code-generating
> tools that have the potential to mess about with data
Quite so, tho I wasn't aware that the tools might not have a one-to-one
relationship with languages.
I was
Michael Lacey wrote:
> I'd want to be able to write/use code from multiple HLLs without any danger
> of them stamping all over each other's data.
As I see it, HLLs are just languages, and it's not the _language_ that
"stamps all over" the data. It's really the code-generating tools that
have the p
Pardon my ignorance here.
>From an application programmer's (which is what I used to be) point of view
I'd want to be able to write/use code from multiple HLLs without any danger
of them stamping all over each other's data.
I'd assumed Parrot would be enforcing namespace integrity and not assumin
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 take one small part
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
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Since PIR behaviour is ours to define, it can do whatever we want.
> I'm inclined to rule that a plain
> bar()
> is equivalent to:
> current_namespace::bar()
> and as such the PIR compiler should look up the function by name in
> the current na
At 11:07 AM +0100 3/15/05, Leopold Toetsch wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
t/pmc/namespace.t
Please have a look at the supported syntax constructs. Are these
sufficient for HLL writers?
Some more thoughts WRT namespaces.
We can define a namespace, where a function or method i
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> t/pmc/namespace.t
> Please have a look at the supported syntax constructs. Are these
> sufficient for HLL writers?
Some more thoughts WRT namespaces.
We can define a namespace, where a function or method is stored:
.namespace ["Foo"]
.sub bar
On Sun, 3 Oct 2004, Jeff Clites wrote:
> I think that no matter what the approach, there's an unavoidable
> mismatch between Perl and Python when it comes to variable naming, it's
> going to be a bit awkward to access Perl variables from within Python.
...
> 1) Treat Perl variables as having the s
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Oct 4, 2004, at 9:58 PM, Brent 'Dax' Royal-Gordon wrote:
> > You can have "the current namespace" actually be [ ::Foo::Bar::Baz,
> > ::Foo::Bar, ::* ] (or, for the last one, whatever the namespace that
> > @*ARGS and friends are in is called), so that the
On Oct 4, 2004, at 9:58 PM, Brent 'Dax' Royal-Gordon wrote:
Tim Bunce <[EMAIL PROTECTED]> wrote:
Now, with that out of the way, let's talk about overlaid namespaces.
I don't think I ever read a description of what the purpose of this
was.
I get the "what" but not the "why". Without the "why" it's
On Oct 4, 2004, at 8:25 AM, Dan Sugalski wrote:
Okay, since we've got the *basic* semantics down (unified namespace,
namespace entries get a post-pended null character)
I'll ask again, what about subs? Do they get name-mangled too?
$Px = find_global [key; key; key], 'name'
As Leo pointed out in
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Next I want to add in the op variants:
> $Px = find_global [key; key]
> $Px = find_global $Px, [key; key]
> $Px = find_global $Py, 'name'
I've already proposed some time ago that these variants of namespace
manipulation aren't really necessar
Tim Bunce <[EMAIL PROTECTED]> wrote:
> > Now, with that out of the way, let's talk about overlaid namespaces.
>
> I don't think I ever read a description of what the purpose of this was.
> I get the "what" but not the "why". Without the "why" it's hard to
> critique the "how".
Clearly I'm not Dan
On Mon, Oct 04, 2004 at 11:25:47AM -0400, Dan Sugalski wrote:
> Okay, since we've got the *basic* semantics down (unified namespace,
> namespace entries get a post-pended null character) it's time for the
> ops to handle them, as well as some extended semantics.
I agree with Larry when he said "
I'll delurk here for a moment,
I am of the opinion that there is not that much of a need to allow for
simultaneous access to similarly named Perl data types in python. I am not
aware of any CPA modules that export two or more of the same name but for
different data types - such as $foo, @foo,
On Oct 1, 2004, at 5:45 AM, Leopold Toetsch wrote:
Jens Rieks <[EMAIL PROTECTED]> wrote:
On Friday 01 October 2004 08:42, Leopold Toetsch wrote:
sucks a lot less than making python programmers say
"import Foo.ns.Bar.scalar.baz"
But OTOH I can imagine that finally standard modules are present in
Pa
On Thu, 30 Sep 2004, TOGoS wrote:
> With this method, the *only* place you'll run into
> trouble is in a language where any string can be a
> variable identifier. [...]
>
> You could solve this by declaring that *all* variables
> in a namespace must begin with some sort of sigil, but
> then you can
On Sep 29, 2004, at 9:01 PM, Brent 'Dax' Royal-Gordon wrote:
[Argh...]
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
parrot_alias(a, 'b', # dest: Python is unified, no
need for a category here
a, 'b', 'scalar') # src: Perl is not unified, so
source category is requi
More detailed responses are below, but some general comments first:
I think that no matter what the approach, there's an unavoidable
mismatch between Perl and Python when it comes to variable naming, it's
going to be a bit awkward to access Perl variables from within Python.
I don't see any way
Jens Rieks <[EMAIL PROTECTED]> wrote:
> On Friday 01 October 2004 08:42, Leopold Toetsch wrote:
>> > sucks a lot less than making python programmers say
>> > "import Foo.ns.Bar.scalar.baz"
>>
>> And that's not possible because CPython, JPython, IronPython, ...
>> wouldn't execute it.
> Yes, but tho
On Friday 01 October 2004 08:42, Leopold Toetsch wrote:
> > sucks a lot less than making python programmers say
> > "import Foo.ns.Bar.scalar.baz"
>
> And that's not possible because CPython, JPython, IronPython, ...
> wouldn't execute it.
Yes, but those Pythons will not execute such a program at a
TOGoS <[EMAIL PROTECTED]> wrote:
> ... Otherwise your python programmer has
> to say import lib."$foo" or some such.
There is no such language syntax in Python. You just have bare words as
names - nothing else, especially no strings where you could place the
sigil.
> ... and
> sucks a lot less t
Thomas Seiler <[EMAIL PROTECTED]> wrote:
> For those languages that support native Hashes, it should be relatively
> simple to give the user direct access to a Namespace PMC as if it would
> be a native Hash, (all it needs is a Hash-vtable, maybe a Namespace PMC
> should be just a Hash)...
Well,
Chip Salzenberg wrote:
According to Brent 'Dax' Royal-Gordon:
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
parrot_alias(a, 'b', # dest: Python is unified, no need for a category
here
a, 'b', 'scalar') # src: Perl is not unified, so source category is
required
It seem
No no no. You've all got it all wrong. Except for the
Dans. :)
> Namespaces are going to be *simple*.
> They do two things, and only two things.
>
> 1) They provide a hierarchy for other namespaces
> 2) They bind names to PMCs
And that's all good. Here's what Perl can do:
$foo becomes namespace
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> According to Brent 'Dax' Royal-Gordon:
> > (This does pose a problem going the other way, but I suspect Perl
> > could simply mark its own packages in some way, and fall back to a
> > simpler scheme, such as "ignore the sigil", when it's munging another
According to Brent 'Dax' Royal-Gordon:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> >parrot_alias(a, 'b', # dest: Python is unified, no need for a
> > category here
> > a, 'b', 'scalar') # src: Perl is not unified, so source
> > category is required
>
> It se
Jeff Clites wrote:
That's it. No typing, no classification, no nothing.
By postpending a null character, below, you _are_ doing
typing/classification, of course. And, what about subs?
I was kind of inspired here. Just stick with me.
As Larry said, it's best to prepend it. And then we can call i
Jeff Clites <[EMAIL PROTECTED]> wrote:
> First off, Perl5 doesn't describe itself that way. The Camel states,
> "Note that we can use the same name for $days, @days, and %days without
> Perl getting confused."
While that's fine for Perl it doesn't help, if you want to access one
distinct "days" f
[Argh...]
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
>parrot_alias(a, 'b', # dest: Python is unified, no need for a
> category here
> a, 'b', 'scalar') # src: Perl is not unified, so source category
> is required
>
>parrot_alias(a, 'c',
> a,
On Sep 29, 2004, at 2:53 AM, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Okay, so we've got two points of dispute:
1) Jeff doesn't think the sigil should be part of the variable name
Which isn't practicable. We can't strip off the sigil for perl5. It's
part of the variable name,
On Sep 29, 2004, at 7:25 AM, Dan Sugalski wrote:
Okay, after seeing all the back and forth, here's what we're going to
do.
Namespaces are going to be *simple*. They do two things, and only two
things.
1) They provide a hierarchy for other namespaces
2) They bind names to PMCs
That's it. No typi
On Wed, Sep 29, 2004 at 10:25:29AM -0400, Dan Sugalski wrote:
: best to go with a unified hierarchy/variable namespace, so we'll
: postpend a NUL to the end of non-variables.
Well, I'd prepend the null just to reduce confusion (or rather,
to force the confusion earlier), but guess I really don't
> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes:
LT> If you want to use a perl5 module from Python which has both $foo and
LT> @foo exported, we can just pitch a fit. Everything else can be handled
LT> by the import module.
LT> And: we can't attach hints to the namespace lookup b
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, so we've got two points of dispute:
> 1) Jeff doesn't think the sigil should be part of the variable name
Which isn't practicable. We can't strip off the sigil for perl5. It's
part of the variable name, $foo and @foo are different items.
If you wan
On Sep 28, 2004, at 12:28 PM, Chip Salzenberg wrote:
According to Dan Sugalski:
At 11:58 AM -0700 9/28/04, Jeff Clites wrote:
On Sep 28, 2004, at 11:26 AM, Chip Salzenberg wrote:
According to Jeff Clites:
top-level namespace (say this is namespace #1):
{
variables => { Foo => },
na
Just a casual question here--how does the concept of shared namespaces
relate to getting and using a bless()ed object in perl from a different
language? Is this something that is dealt with at the Parrot level, or
it it merely an attribute associated with a scalar that some PMC takes
care of?
According to Chip Salzenberg:
> According to TOGoS:
> > Or explicit exports :) that way you only need to define the
> > interface once, and then all unified-namespace languages can use it.
>
> Asking Perl programmers to go out of their way to present foreign and
> unnatural interfaces is, well, fo
According to TOGoS:
> Or explicit exports :) that way you only need to define the
> interface once, and then all unified-namespace languages can use it.
I think an (until now) seldom-mentioned aesthetic of Parrot is that
all languages get to work in their own way, and don't have to present
unnatur
> According to TOGoS:
> > Chip said:
> > > A Perl runtime won't have the
> > > necessary information
> > > to present [a unified namespace].
> >
> > I'm not so sure about that. Most of the time,
> > only one variable with
> > a name will be defined ($foo, @foo, or &foo, but
> > not more than one)
According to TOGoS:
> Chip said:
> > A Perl runtime won't have the necessary information
> > to present [a unified namespace].
>
> I'm not so sure about that. Most of the time, only one variable with
> a name will be defined ($foo, @foo, or &foo, but not more than one).
That looks good in static
Chip said:
> ...the "appearance" of a unified namespace *is*
> a unified namespace.
Yup.
> A Perl runtime won't have the necessary information
> to present one.
I'm not so sure about that. Most of the time, only one
variable with a name will be defined ($foo, @foo, or
&foo, but not more than one
According to TOGoS:
> > Ruby apparently has a unified namespace. Perl doesn't have one of
> > those. Pretending it does is just closing your eyes and humming.
>
> Many other languages won't be able to access perl's various
> differently-typed variables, anyway.
Sure they will, with appropriate
--- Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> According to TOGoS:
> > Each namespace should have a
> lowest-common-denominator set of values
> > in it. These are not specified to be functions,
> namespaces, or
> > whatever. They're just pointers to values.
>
> What you write here makes as muc
According to TOGoS:
> Each namespace should have a lowest-common-denominator set of values
> in it. These are not specified to be functions, namespaces, or
> whatever. They're just pointers to values.
What you write here makes as much sense as requesting support for:
"Call some method on this obje
> And unfortunately dies a horrible death for
languages
> that don't categorize the same way as perl. :( As
> well as being really inconvenient for those
variables
> that can express multiple classes of behaviours
> simultaneously.
>
> This one, alas, I'm going to shoot down.
> - Dan
OK, I'm going
According to Dan Sugalski:
> At 11:58 AM -0700 9/28/04, Jeff Clites wrote:
> >On Sep 28, 2004, at 11:26 AM, Chip Salzenberg wrote:
> >
> >>According to Jeff Clites:
> >>>top-level namespace (say this is namespace #1):
> >>>{
> >>> variables => { Foo => },
> >>> namespaces => { Foo => }
> >>>}
At 11:58 AM -0700 9/28/04, Jeff Clites wrote:
On Sep 28, 2004, at 11:26 AM, Chip Salzenberg wrote:
According to Jeff Clites:
top-level namespace (say this is namespace #1):
{
variables => { Foo => },
namespaces => { Foo => }
}
I think I get it. You're replacing sigil characters a
On Sep 28, 2004, at 11:26 AM, Chip Salzenberg wrote:
According to Jeff Clites:
top-level namespace (say this is namespace #1):
{
variables => { Foo => },
namespaces => { Foo => }
}
I think I get it. You're replacing sigil characters and associated
name mangling, turning it into e
According to Jeff Clites:
> top-level namespace (say this is namespace #1):
> {
> variables => { Foo => },
> namespaces => { Foo => }
> }
I think I get it. You're replacing sigil characters and associated
name mangling, turning it into explicit named categories, thus
avoiding lots o
On Tue, Sep 28, 2004 at 08:58:05AM -0700, Jeff Clites wrote:
: You'd still say a given namespace has different
: "sections" to accommodate different categories of entities.
So what you're basically saying is that symbols should be stored in
some kind of extensible URL-ish space. Something to be
On Tue, 2004-09-28 at 12:05, Jeff Clites wrote:
> On Sep 28, 2004, at 7:02 AM, Aaron Sherman wrote:
>
> > why not have each language do it the way
> > that language is comfortable (e.g. place it in the regular namespace as
> > a "variable" like Python or place it in the regular namespace, but
> >
On Sep 28, 2004, at 9:54 AM, Chip Salzenberg wrote:
According to Jeff Clites:
Let's say that all you have around are $Foo and $Foo::Bar::baz ...
top-level namespace (say this is namespace #1):
{
variables => { Foo => },
namespaces => { Foo => }
}
I'm a bit confused by this example
According to Jeff Clites:
> Let's say that all you have around are $Foo and $Foo::Bar::baz ...
>
> top-level namespace (say this is namespace #1):
> {
> variables => { Foo => },
> namespaces => { Foo => }
> }
I'm a bit confused by this example. Don't you mean:
variables =>
On Sep 28, 2004, at 8:58 AM, Jeff Clites wrote:
And just to close the loop, you'd still express your $Foo::Bar::baz
lookup like:
lookupVariableInNamespace P1, ["Foo"; "Bar"], "baz" # the things in
the [...] are always namespace names
Here are more examples, just to be clear:
(and the actual op n
On Sep 28, 2004, at 7:02 AM, Aaron Sherman wrote:
Rather than trying to shuffle through the keyboard and find that
special
character that can be used, why not have each language do it the way
that language is comfortable (e.g. place it in the regular namespace as
a "variable" like Python or place
On Sep 27, 2004, at 8:55 AM, Dan Sugalski wrote:
Okay, I've come to realize that it really helps if I'm clear about
what I want, which kinda requires being clear about what I want.
There are two things in the namespaces I'm concerned about.
First are the actual objects one grabs out. Variables, s
On Mon, 2004-09-27 at 13:04, Chip Salzenberg wrote:
> For Perl, I get that. But for Python, AFAICT, namespaces are
> *supposed* to be in the same, er, namespace, as variables. No?
Yes, and what's more the suggestion of using "::" in Parrot won't work
perfectly either (I'm pretty sure that there
> > I think Guido might have made things a
> > bit harder to separate out than you
> > anticipate, unless I misread you. It
> > appears that modules and classes are
> > also imported into the same namespace
> > as everything else in python.
>
> Yeah, I had that pointed out in private
> mail. At thi
At Sat, 25 Sep 2004 00:53:25 -0400,
> By the way, this isn't the list for it, but it would be cool if perl6 had
> an interactive mode as good as python's. It's one of the few places I
> think python has a compelling lead.
I'm sort of partial to:
perl -MTerm::ReadLine -le '$t = new Term::ReadLine
On Fri, 24 Sep 2004 21:04:52 -0400, Dan Sugalski wrote:
> At 7:51 PM -0400 9/24/04, Jonathan Polley wrote:
>>On Fri, 24 Sep 2004 14:04:52 -0400, Dan Sugalski wrote:
>>
>>> ...
>>> (Though class names/namespaces seem to be separate)
>>> ...
>>
>>I think Guido might have made things a bit harder
At 7:51 PM -0400 9/24/04, Jonathan Polley wrote:
On Fri, 24 Sep 2004 14:04:52 -0400, Dan Sugalski wrote:
...
(Though class names/namespaces seem to be separate)
...
I think Guido might have made things a bit harder to separate out than you
anticipate, unless I misread you. It appears that module
On Fri, 24 Sep 2004 14:04:52 -0400, Dan Sugalski wrote:
> ...
> (Though class names/namespaces seem to be separate)
> ...
I think Guido might have made things a bit harder to separate out than you
anticipate, unless I misread you. It appears that modules and classes are
also imported into the sam
According to Matt Fowles:
> I personally thing that the suggestion of providing a base namespace
> PMC and letting each language create their own if they want overrides
> is a really nice idea.
I can't speak to that. However:
> I think the base one should have the maximum number of distinct
> su
All~
I personally thing that the suggestion of providing a base namespace
PMC and letting each language create their own if they want overrides
is a really nice idea. I think the base one should have the maximum
number of distinct subspaces with special functions to access them
(i.e. function, va
According to Dan Sugalski:
> I'm fine with mashing functions and variables into a single big mass...
Me too (FWIW). And I think it'll work.
PS: I've got the Glob Stick where I can reach it.
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I don't really think it is
On Wed, 22 Sep 2004 23:13:37 -0400, Dan Sugalski wrote:
> At 7:32 PM -0700 9/22/04, Jeff Clites wrote:
>>On Sep 22, 2004, at 10:58 AM, Dan Sugalski wrote:
>>
>>>*) There are three things that can be in a namespace: Another
>>>namespace, a method or sub, and a variable.
>>>
>>>*) The names of name
1 - 100 of 143 matches
Mail list logo
