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.
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
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't
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
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, the
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 than
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 all,
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 those Pythons will
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 seems to me
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
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
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 seems
[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, 'c',
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
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,
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 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 names
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 = PerlScalar PMC (or whatever) },
namespaces = { Foo = PerlNamespace PMC, call namespace #2 }
}
I'm a bit confused
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 = PerlScalar PMC (or whatever) },
namespaces = { Foo = PerlNamespace
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
append
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
According to Jeff Clites:
top-level namespace (say this is namespace #1):
{
variables = { Foo = PerlScalar PMC (or whatever) },
namespaces = { Foo = PerlNamespace PMC, call namespace #2 }
}
I think I get it. You're replacing sigil characters and associated
name mangling, turning
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 = PerlScalar PMC (or whatever) },
namespaces = { Foo = PerlNamespace PMC, call namespace #2 }
}
I think I get it. You're replacing
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 = PerlScalar PMC (or whatever) },
namespaces = { Foo = PerlNamespace PMC, call namespace
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 = PerlScalar PMC (or whatever) },
namespaces = { Foo =
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 to
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 object.
--- 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 much sense as
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 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). In
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
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
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
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, foreign
delurk
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
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 = PerlScalar PMC
36 matches
Mail list logo
