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
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
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
[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 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
36 matches
Mail list logo
