Namespaces again
Dan Sugalski
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, sub objects,
class objects -- actual "stuff". Languages seem to fall into two
categories -- those that group subroutines in with data and those
that don't. (Most generally do)
Second there's the structure of the namespace. I really do want
Foo::Bar to be handled with a Foo entry in the top-level namespace,
and a Bar entry in the Foo namespace, and nothing that anyone does to
any Foo "object" at the top level can damage that.
The fact that the Foo class has an object named Foo at the top level
which you can fool with is separate from the fact that there's a Foo
*namespace* at the top level. Using a filesystem analogy, I want to
have a directory and file named Foo, with file operations not
touching the directory, and directory operations not touching the
file.
It seems like the simplest thing to do is to have a *real* unified
system and go with a prefix or suffix scheme for namespaces that the
namespace ops automatically pre/post-pend on the names. If we do
that, I'm up for the NUL character, since we're pretty safe in
assuming that nobody allows NULs in their identifier names.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Larry Wall
: It seems like the simplest thing to do is to have a *real* unified
: namespace ops automatically pre/post-pend on the names. If we do
: that, I'm up for the NUL character, since we're pretty safe in
: assuming that nobody allows NULs in their identifier names.
Er.
${"foo\0bar"} = 42;
print ${"foo\0bar"},"\n";
For what it's worth, in Perl 5 namespaces have a "::" on the end of
their name, which is also rather unlikely to find in real identifier names.
Larry
Dan Sugalski
>On Mon, Sep 27, 2004 at 11:55:27AM -0400, Dan Sugalski wrote:
>: It seems like the simplest thing to do is to have a *real* unified
>: system and go with a prefix or suffix scheme for namespaces that the
>: namespace ops automatically pre/post-pend on the names. If we do
>: that, I'm up for the NUL character, since we're pretty safe in
>: assuming that nobody allows NULs in their identifier names.
>
>Er.
>
> ${"foo\0bar"} = 42;
> print ${"foo\0bar"},"\n";
Yeah, but just try feeding that to my or our. :-P
I'm perfectly willing to let people who muck about at the low levels
shoot themselves in the foot. I'm OK with shooting them ourselves,
too, if need be, so long as we don't need to very often.
Larry Wall
: At 9:08 AM -0700 9/27/04, Larry Wall wrote:
: >On Mon, Sep 27, 2004 at 11:55:27AM -0400, Dan Sugalski wrote:
: >: It seems like the simplest thing to do is to have a *real* unified
: >: system and go with a prefix or suffix scheme for namespaces that the
: >: namespace ops automatically pre/post-pend on the names. If we do
: >: that, I'm up for the NUL character, since we're pretty safe in
: >: assuming that nobody allows NULs in their identifier names.
: >
: >Er.
: >
: > ${"foo\0bar"} = 42;
: > print ${"foo\0bar"},"\n";
:
: Yeah, but just try feeding that to my or our. :-P
:-P your own self. I thought we were talking about symbol tables here.
Anyway, :: is just as rare in "real" identifiers, doesn't require
translation for either Perl 5 or Perl 6, and most importantly, is
*visible* if you try to print it out naively. The only argument I
can see against something like :: is efficiency, but that generally
only slows down the compiler a smidge, not the run-time, unless you're
into heavy-duty symbolic references.
But I really don't care so much what the flag is, as long as it's
visible on printout. I think even / would be better than \0.
: I'm perfectly willing to let people who muck about at the low levels
: shoot themselves in the foot. I'm OK with shooting them ourselves,
: too, if need be, so long as we don't need to very often.
By that criterion we should all be shot. :-)
Larry
Chip Salzenberg
> I really do want Foo::Bar to be handled with a Foo entry in the
> top-level namespace, and a Bar entry in the Foo namespace, and
> nothing that anyone does to any Foo "object" at the top level can
> damage that.
For Perl, I get that. But for Python, AFAICT, namespaces are
*supposed* to be in the same, er, namespace, as variables. No?
--
Chip Salzenberg - a.k.a. - <ch...@pobox.com>
"I don't really think it is a question of bright people and dumb
people, but rather people who can see the game they're playing and
those who can't." -- Joe Cosby
Aaron Sherman
> 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 are LISP variants, possibly
including scheme) that use ":" in identifiers.
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 it in the regular namespace, but
append noise like Perl or hide it in some creative way for other
languages). For the most part, there's no performance penalty in having
a callback that the language/library/compiler provides because access to
the objects in question will be via a PMC, and only LOOKUP of that PMC
will be via namespace, no?
In that way, you could:
namespace_register perl5_namespace_callback, "Perl5"
namespace_register python_namespace_callback, "Python"
[...]
namespace_lookup P6, "F\0o::Bar", "Perl5"
namespace_lookup P7, "foo.bar", "Python"
the namespace callback could take a string and return whatever Parrot
needs to look up a namespace (Array PMC?), having encoded it according
to Parrot's rules.
That way, you can solve this however you like (heck, put a § between
them if you want... in fact, I kind of like that).
--
☎ 781-324-3772
✉ a...@ajs.com
☷ http://www.ajs.com/~ajs
Jeff Clites
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, sub objects,
> class objects -- actual "stuff". Languages seem to fall into two
> categories -- those that group subroutines in with data and those that
> don't. (Most generally do)
>
> Second there's the structure of the namespace. I really do want
> Foo::Bar to be handled with a Foo entry in the top-level namespace,
> and a Bar entry in the Foo namespace, and nothing that anyone does to
> any Foo "object" at the top level can damage that.
What I proposed in my 9/26/2004 post to the "Namespaces, part 1 (new
bits)" thread directly accommodates all that.
Here is how that looks in data structure terms. (I'll use hash notation
here, though the actual implementation could optimize.)
Let's say that all you have around are $Foo and $Foo::Bar::baz -- that
is, a Foo variable at the top level, and a bar variable inside a Bar
namespace inside a Foo namespace. The namespaces involved could look
like this:
top-level namespace (say this is namespace #1):
{
variables => { Foo => <PerlScalar PMC (or whatever)> },
namespaces => { Foo => <PerlNamespace PMC, call namespace #2> }
}
namespace #2 (the namespace from above):
{
namespaces => { Bar => <PerlNamespace PMC, call namespace #3> }
}
namespace #3 (the namespace from immediately above):
{
variables => { baz => <PerlScalar PMC> }
}
It doesn't matter if the sigils are treated as part of the name--the
structure's the same, you just have "$Foo" and "Foo::" up there
instead. (Though Perl maybe could have done without the structure for
variable v. namespace, other languages don't have a natural syntax to
distinguish them.) And of course, you'd have a "subs => ..." section if
we had any subs in our example.
My above-mentioned post explained what you'd do for Python, and how it
fits well into this. And for languages which need more sections, they
would be accommodated as well.
> The fact that the Foo class has an object named Foo at the top level
> which you can fool with is separate from the fact that there's a Foo
> *namespace* at the top level. Using a filesystem analogy, I want to
> have a directory and file named Foo, with file operations not touching
> the directory, and directory operations not touching the file.
Yep, that does that.
> It seems like the simplest thing to do is to have a *real* unified
> system and go with a prefix or suffix scheme for namespaces that the
> namespace ops automatically pre/post-pend on the names.
I don't think there's any need for name mangling--that's the sort of
thing you do when you need to shoehorn extra information into a
structure that wasn't designed to hold it.
If you want to name mangle, _and_ not arbitrarily restrict what
characters a language might allow in identifiers, then it makes sense
to give everything a prefix, and it's unambiguous that the prefix is
everything up to your first separator character (say, slash); for
example: "namespace/Foo", "variable/Foo"--there's no ambiguity or
restriction, for instance "variable/foo/bar" is just the "foo/bar"
variable in some language which allows slashes inside of variable
names. 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
Logically, that's identical to what I have above--it's just another way
to express the same structure, just an internal implementation detail,
with some pros (maybe one less hash lookup) and cons (more intermediate
strings created). You'd still say a given namespace has different
"sections" to accommodate different categories of entities.
JEff
Jeff Clites
> 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 it in the regular namespace, but
> append noise like Perl or hide it in some creative way for other
> languages). For the most part, there's no performance penalty in having
> a callback that the language/library/compiler provides because access
> to
> the objects in question will be via a PMC, and only LOOKUP of that PMC
> will be via namespace, no?
>
> In that way, you could:
>
> namespace_register perl5_namespace_callback, "Perl5"
> namespace_register python_namespace_callback, "Python"
> [...]
> namespace_lookup P6, "F\0o::Bar", "Perl5"
> namespace_lookup P7, "foo.bar", "Python"
>
> the namespace callback could take a string and return whatever Parrot
> needs to look up a namespace (Array PMC?), having encoded it according
> to Parrot's rules.
That's similar in spirit to what I proposed of allowing PMC-subclassing
of the default ParrotNamespace, so that namespaces created from
different languages (often implicitly) could have different behaviors.
But I'd keep the pulling-apart of "F\0o::Bar" into ["F\0o"; "Bar"] a
compile-time task, so that at runtime the work's already been done
(since the compiler knows what language it's compiling).
JEff
Jeff Clites
> 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 would be different, but I'm trying to be
unambiguous here):
# $Foo::Bar::baz, or presumably Python's Foo.Bar.baz
lookupVariableInNamespace P1, ["Foo"; "Bar"], "baz"
# $::foo, or "foo" as a variable in the top-level namespace
lookupVariableInNamespace P1, [], "foo"
# &Foo::bar
lookupSubInNamespace P1, ["Foo"], "bar"
Now, the above are shortcuts (or optimizations) for the generalized op:
lookupInNamespace P1, ["Foo"; "Bar"], .VARIABLE, "baz"
And, they're also shortcuts for doing things more "manually":
# $Foo::Bar::baz
lookupNamespaceInNamespace P0, [], "Foo" # or rootNamespace P0
lookupNamespace P1, P0, "Bar" #lookup namespace "Bar" in namespace in P0
lookupVariable P2, P1, "baz" #lookup variable "baz" in namespace in P1
And if we must treat the sigil as part of the name for Perl6 at the
parrot level, we just get stuff like:
# $Foo::Bar::baz
lookupVariableInNamespace P1, ["Foo::"; "Bar::"], "$baz"
But, it seems better to not do that.
JEff
Chip Salzenberg
> 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 by this example. Don't you mean:
variables => { '$Foo' => <PerlScalar PMC (or whatever)> },
i.e. with the '$' in the key?
Jeff Clites
> 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 by this example. Don't you mean:
>
> variables => { '$Foo' => <PerlScalar PMC (or whatever)> },
>
> i.e. with the '$' in the key?
Sorry, accidentally sidestepped the array/scalar/hash issue. Given
$foo, @foo, and %foo, we could either do:
variables => { '$foo' => <whatever>,
'@foo' => <whatever>,
'%foo' => <whatever>
}
-or-
scalars => { 'foo' => <whatever> },
arrays => { 'foo' => <whatever> },
hashes => { 'foo' => <whatever> }
The infrastructure's the same, it just depends on whether we want to
(at the Parrot level) think of Perl as having one category of
variables, or three. We could even have:
scalars => { '$foo' => <whatever> },
arrays => { '@foo' => <whatever> },
hashes => { '%foo' => <whatever> }
...if we wanted to model Perl as having three categories, but still
treat the sigils as part of the name.
I think the second option has the most potential for smooth
interoperability with other languages.
Presumably, all of Pythons "stuff" would go in a single bucket in a
Python-originating namespace. So it might look like:
{
whatever => { a => <namespace>, b => <object>, c => <sub> }
}
Where there's only one category, and "whatever" could be "references"
or "objects" or "variables" or "scalars" or whatever made the most
sense from a cross-language standpoint. (I think the different
semantics of Perl v. Python variables means that it might be
appropriate for the categories to be different between the two
languages, though Python and Ruby might match one another. But, as all
Python variables are references, they're sorta-like Perl scalars, so
maybe the category for Perl-scalars should be the same as that for
Python-references--just depends on what works best for cross-language
access, but the infrastructure's the same.)
And what I mean here is that how many categories are inside a given
namespace depends on where it was created (in Perl code v. Python code,
for example), but after that point the usage is the same.
JEff
Aaron Sherman
> 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 noise like Perl or hide it in some creative way for other
> > languages).
> That's similar in spirit to what I proposed of allowing PMC-subclassing
> of the default ParrotNamespace, so that namespaces created from
> different languages (often implicitly) could have different behaviors.
> But I'd keep the pulling-apart of "F\0o::Bar" into ["F\0o"; "Bar"] a
> compile-time task, so that at runtime the work's already been done
> (since the compiler knows what language it's compiling).
Sounds reasonable, thought you can't ALWAYS do it in advance, you
certainly want to do as much as possible up-front.
Larry Wall
: You'd still say a given namespace has different
So what you're basically saying is that symbols should be stored in
some kind of extensible URL-ish space. Something to be said for that.
Larry
Chip Salzenberg
> 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 it into explicit named categories, thus
avoiding lots of anticipated string tricks.
Jeff Clites
> 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 it into explicit named categories, thus
> avoiding lots of anticipated string tricks.
Yep, exactly. And it works for Perl, but also fits languages which
don't have a built-in mangling-via-sigils, yet still have different
categories (like Common Lisp, which allows functions and variables of
the same name).
And the named categories don't necessarily imply an additional hash
lookup--with specialized ops for the common categories, we can
fast-path getting to the correct hash to do the final lookup.
JEff
Dan Sugalski
>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 sigil characters and associated
>>name mangling, turning it into explicit named categories, thus
>>avoiding lots of anticipated string tricks.
>
>Yep, exactly. And it works for Perl, but also fits languages which
>don't have a built-in mangling-via-sigils, yet still have different
>categories (like Common Lisp, which allows functions and variables
>of the same name).
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.
Chip Salzenberg
> 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 #2> }
> >>>}
> >>
> >>I think I get it. You're replacing sigil characters and associated
> >>name mangling, turning it into explicit named categories, thus
> >>avoiding lots of anticipated string tricks.
> >
> >Yep, exactly.
>
> categorize the same way as perl. :(
The horrible death you fear is unavoidable. The variable categories
are an impedance mismatch that namespaces can't paper over. Name
spaces have different dimensionality, if you will, in different
languages. We can't *fix* that without changing the languages.
You said on IRC that the Perl/Python gap would have to be bridged with
one-shot namespace connection, something like Exporter. (Perl "$a::b"
=> Python 'a.b', Perl "@a::c" => Python 'a.c', etc.) So the import
process could use Jeff-style categories to get some handle on what's
being imported. e.g.:
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', 'array') # here's a different category, to get '@c'
or some such. Yes it's ugly. But if we can't fix a ditch, the least
we can do is put a big friendly warning sign on it.
> As well as being really inconvenient for those variables that can
> express multiple classes of behaviours simultaneously.
You only get categories for *syntactic* categories, where this
objection does not apply. (These are *name* spaces.)
TOGoS
languages
> well as being really inconvenient for those
variables
> that can express multiple classes of behaviours
> simultaneously.
>
OK, I'm going to chime in and say what makes the most
sense to me, coming from a Ruby background.
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. When you do cross-language
foo::bar
this is what you get. Your language can feel free
to de-reference the value and convert it to another
type or stuff it into a fancy variable PMC, if it
wants.
Now, what we need is for each namespace to also have a
second set of values. These could accomodate your $foo
@foo &foo, etc with sigils, or whatever method your
language chooses to munge names. Though it might be
good to standardize that method ("namespace/foo",
"scalar/bar"), it's not necessary. Then you have two
opcodes:
get_namespaced ["foo","bar"]
get_namespaced_exact ["::foo","$bar"]
which use the LCD and separated namespaces,
respectively. You might need to mix-and-match:
foo = get_namespaced ["foo"]
bar = get_namespaced_exact foo, ["$bar"]
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Chip Salzenberg
> 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. I won't tell you which method to
call. Just pick one. Guess if you have to."
Ruby apparently has a unified namespace. Perl doesn't have one of
those. Pretending it does is just closing your eyes and humming.
TOGoS
--- Chip Salzenberg <ch...@pobox.com> 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
> requesting support for:
> "Call some method on this object. I won't tell you
> which method to
> call. Just pick one. Guess if you have to."
>
> 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. To those
languages perl should make visible a uified namespace.
It can feel free to have a second, non-unified one if
it likes. If you had bothered to read the second half
of the message you'd know that that's what I meant.
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
Chip Salzenberg
> > 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 aliasing requests.
> To those languages perl should make visible a unified namespace.
That's a level of DWIM inappropriate for a language runtime.
> It can feel free to have a second, non-unified one if it likes. If
> you had bothered to read the second half of the message you'd know
> that that's what I meant.
I read all of it. I know what you mean. What you are not realizing is
that the "appearance" of a unified namespace *is* a unified namespace.
A Perl runtime won't have the necessary information to present one.
TOGoS
> ...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 these cases, the perl
compiler would put 'foo' into the LCD namespace in
addition to putting $foo @foo or &foo into the perl
namespace. In cases where more than one is defined, it
could default to scalar (probably what the
hypothetical ruby/python programmer wanted), or let
the perl programmer specify which one to use:
add_module_accessor 'foo', $foo
(or whatever).
This reminds me just a little bit of what J# does to
implement accessors that can be used by other .NET
programs. It's a little clunky for the java
programmer, but it makes the interface for everyone
else much cleaner.
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
Chip Salzenberg
> Chip said:
> > A Perl runtime won't have the necessary information
>
> 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 analysis. But masking effects are serious
enough that it's a bad idea, IMO.
Consider: A working Perl/Python hybrid program would be broken by an
upward-compable upgrade of the Perl part that makes a given name
ambiguous, thus defeating the single-namespace view that used to work.
Requiring explicit imports avoids this problem.
> This reminds me just a little bit of what J# does to implement
> accessors that can be used by other .NET programs.
Do tell, please.
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 analysis. But masking
> effects are serious
> enough that it's a bad idea, IMO.
>
> Consider: A working Perl/Python hybrid program would
> be broken by an
> upward-compable upgrade of the Perl part that makes
> a given name
> ambiguous, thus defeating the single-namespace view
> that used to work.
>
> Requiring explicit imports avoids this problem.
Or explicit exports :) that way you only need to
define the interface once, and then all
unified-namespace languages can use it.
But we can have it both ways, if we want. The only
issue is 'how do we separate the imported/exported
namespace from the original'. Does ["Foo","bar"]
(external interface) become ["\0:Foo","\0$bar"], or
["\0namespaces","Foo","\0scalars","bar"], etc?
> > This reminds me just a little bit of
> > what J# does to implement
> > accessors that can be used by other .NET programs.
>
> Do tell, please.
Well, it's not entirely related, but it goes something
like this:
/** @property */
public void set_SiteTitle( String value ) {
this.siteTitle = value;
}
/** @property */
public String get_SiteTitle() {
return this.siteTitle;
}
The J# compiler then creates 'SiteTitle' accessor
methods. The point is that a C# programmer using your
object can say 'Server.SiteTitle' instead of having to
remember that you programmed the thing in Java (which
didn't originally have any way to make accessor
methods appear as fields) and calling it
'Server.getSiteTitle()'. The aliasing is taken care of
once, by the module, instead of each time someone
wants to use the module.
__________________________________
Do you Yahoo!?
Chip Salzenberg
> 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
unnatural (for them) interfaces. If module A asks for services from
module B, the onus for interoperability is on the petitioner: A.
Asking Perl programmers to go out of their way to present foreign and
unnatural interfaces is, well, foreign and unnatural for Parrot.
Suggesting that only Perl code that will be used from non-Perl has to
care about this issue misses the point. How am I, the module author,
to know whether my module will catch the fancy of a Python user?
In short: Any system that depends on prescience is doomed to failure.
I can tell you that in advance. :-)
> /** @property */
> public void set_SiteTitle( String value ) {
> this.siteTitle = value;
> }
> /** @property */
> public String get_SiteTitle() {
> return this.siteTitle;
> }
>
> The J# compiler then creates 'SiteTitle' accessor methods.
Ah, I see. I agree this is somewhat different; it's mapping a C#
language feature (for the CLR wouldn't have had this feature if C#
didn't need it) onto a language that lacks it.
On an even less related note, I'm really quite surprised that J#
doesn't use the bean method names. Or maybe it does, and I just
don't remember the bean method names correctly?
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.
>
> unnatural interfaces is, well, foreign and unnatural for Parrot.
However, I should add that I'm sure there will certainly be some
convenience tools provided very early on, which will do most of the
"usual" and "expected" things for common cases.
For example, I'd be really surprised if there weren't a wrapper
created quickly by someone[*] so that in Python you could say:
import perl5.File.Path
and get the appearance of what you asked for in your previous message:
all the exported Perl functions and variables, but without the sigils.
But my point is that the namespace mechanism need not provide much
support (or any, really) for this to work.
[*] Wrappers and adapters are all the rage in free software these
days. (Whatever memetic plage it is that afflicts Java people
seems to be contagious.) So it won't take long for people to write
what I'm describing. Heck, we might do it ourselves, just so we
can test the low-level interoperations more conveniently.
David Christensen
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?
So say I want to the P6 DBI (assuming there needs to be a specific
version), so I try to do something like this in Python (it's been a
while, so Guido, don't shoot me! :D):
dbi=import perl6.DBI;
c=dbi.connect(...) etc etc
Now, C<c> is (presumably) a Perl scalar PMC. Is it also a namespace,
in that there are a set of methods which can be called on this object?
What are the considerations when dealing with something like perl's
blessed references, which arguably have more than just a value
associated with them?
Feel free to tell me "we don't care about this now; that comes later",
"this is Larry's problem", or just "STFU: RTFM" -- I'm just trying to
gain a more complete understanding.
Regards,
David
</delurk>
-----
David Christensen
Founder and CTO
Yin Yan Software
Jeff Clites
Exactly. If Python want to alias to a Perl variable, it's going to have
to specify the category one way or another. Doing string-fiddling by
putting a sigil on the front of the string is one way, but just
specifying a category explicitly is another. The latter is a much more
natural thing to do, in regard to languages which don't themselves have
sigils. And the string-fiddling seems like more of a hack--why try to
shove the category and name information together, into a single string,
rather than leaving them separate?
I'm not even suggesting an implementation here really; it's just,
"namespaces need to handle multiple syntactic categories", and we need
to have API to reflect this. And you hit the nail on the head that
these are *syntactic* categories. These syntactic categories should
always be known at compile-time (which is what makes them syntactic
categories); for languages with sigils, its easy, and for languages
without them (most), the grammar of the language defines it.
And in terms of adaptors, I think that aliasing from Perl to Python is
going to end up aliasing '\@c', and never '@c' really (since Python
always holds references--really aliasing to '@c' would imply that
assignment within Python would copy); conversely, going from Python to
Perl would always end up as a scalar on the Perl side, since everything
from Python would look like a reference to Perl. (At least, this seems
like the most natural approach.)
JEff
Brent 'Dax' Royal-Gordon
Chip Salzenberg <ch...@pobox.com> 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', 'array') # here's a different category, to get '@c'
>
> or some such. Yes it's ugly. But if we can't fix a ditch, the least
> we can do is put a big friendly warning sign on it.
It seems to me that a much easier way to handle this would be to
mangle Perl variables to something that most languages *can* access:
$foo=s_foo
@foo=a_foo
%foo=h_foo
&foo=f_foo (for function)
::foo=n_foo (for namespace)
Yes, n_File.n_Path.f_new() is uglier than File.Path.new, but at least
there's no ambiguity.
Another way to do it would be to have each "category" actually be a
namespace. In other words, Perl's namespaces are structured like
this:
File => package {
ns => package {
Find => package {
sub => package {
find => { ... }
}
},
Path => package {
sub => package {
BUILD => { ... },
DESTROY => { ... }
}
}
...
},
scalar => package {
some_idiot => "put a variable in this package"
}
}
And Python would access them like so:
File.ns.Path.sub.new()
Not perfect, certainly, but it would work, and be reasonably elegant.
(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
language's namespaces.)
--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
There is no cabal.
[I currently have a couple Gmail invites--contact me if you're interested.]
--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
There is no cabal.
[I currently have a couple Gmail invites--contact me if you're interested.]
Chip Salzenberg
> Chip Salzenberg <ch...@pobox.com> 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
>
> mangle Perl variables to something that most languages *can* access:
>
> $foo=s_foo
> @foo=a_foo
That would work.
> [plan B:]
> Python would access them like so:
> File.ns.Path.sub.new()
>
> Not perfect, certainly, but it would work, and be reasonably elegant.
"Works for me."
> (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
> language's namespaces.)
Could you unpack this 'problem', and give an example?
Brent 'Dax' Royal-Gordon
> > 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
> > language's namespaces.)
>
> Could you unpack this 'problem', and give an example?
For the sake of argument, assume that we go with the latter scheme,
and somebody writes this in Perl:
$python::Foo::Bar::baz
A naive Perl 6 compiler would convert that to something like
find_global P0, ["ns"; "python"; "ns"; "Foo"; "ns"; "Bar"; "scalar"; "baz"]
But, since it's a Python namespace, it should really be looking up
find_global P0, ["python"; "Foo"; "Bar"; "baz"] #possibly with
an "ns" in front
One possible solution is to have a Perl 6 version of find_global:
find_global_p6 P0, ["::python"; "::Foo"; "::Bar"; "$baz"]
When find_global_p6 operated on a Perl6Stash (or somesuch), it would
use the sigil to find the appropriate type namespace; when it operated
on any other type of stash, it would strip off the sigils and do a
normal lookup. Thre are other solutions, of course, and I suspect
that many of them would be better than this one...
TOGoS
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['$foo']
::bar becomes namespace[':foo']
Now, if it wants to play nice with other languages
(especially, but not limited to, unified namespace
ones), it can alias either of those values to
namespace['foo']. Otherwise your python programmer has
to say import lib."$foo" or some such.
With this method, the *only* place you'll run into
trouble is in a language where any string can be a
variable identifier. For instance let's say lisp calls
its variables "\0func:foo" and "\0valu:foo", and
someone goes and declares a variable "\0func:hello:)".
Is that variable an aliased-to-the-outside value or
the internal function? (Will this happen often enough
that we care?)
You could solve this by declaring that *all* variables
in a namespace must begin with some sort of sigil, but
then you can't pass a namespace to a function and have
it be treated like a plain ole' associative array (or
at least one with nice keys).
You could also solve the problem by using separate
internal and external namespaces, but that's moving
away from Dan's dictum of 'namespaces are simple'.
Anyhoo. I think the method outlined above is *good
enough for now and likely a long time afterwards*, and
sucks a lot less than making python programmers say
"import Foo.ns.Bar.scalar.baz"
Thomas Seiler
> According to Brent 'Dax' Royal-Gordon:
>
>>Chip Salzenberg <ch...@pobox.com> 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 that a much easier way to handle this would be to
>>mangle Perl variables to something that most languages *can* access:
>>
>>$foo=s_foo
>>@foo=a_foo
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)...
#Python_on_Parrot Library function using inline PASM
baz = Parrot_GetNameSpace("Perl::Foo::Baz)
# Get the scalar
s_foo = baz["$foo"]
# Get the array
a_foo = baz["@foo"]
print Parrot_GetNameSpace("Perl::Foo::Baz")["$foo"];
For splitted namespaces (variable/function) we will then have to agree
on a per language basis how to distinguish them. For example a language
in which function calls have paranthesis can add them to the name to
distinguish a functions from a variable.
namespace["foo"] # variable
namespace["foo()"] # function
Simple yet intuitive. Other example: Lisp
lisp["foo"] # variable
lisp["(foo)] # function
My point is that a variable was represented as a string in the language
is was originally written, to access it from other languages, we should
use an interface that allows us to index it via just that string.
All the other logic needed to import stuff should be left to a module
for that given language. It knows better wich types have to be converted
which functions need wrappers, etc ...
just had to give my 2 cents on namespaces :)
Thomas Seiler
Leopold Toetsch
> 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 give the user direct access" thingy isn't in our scope. The
HLL semantics define that or not.
For Python it's a must:
>>> glob = {'foo' : 1}
>>> loc = {}
>>> exec 'bar = foo + 1' in glob, loc
>>> loc
{'bar': 2}
>>>
This is passing the global namespace "glob" and the local namespace
"loc" to the "exec" statement. Both are plain hashes. After executing
that line of code, the local namespace has a new entry "bar".
> #Python_on_Parrot Library function using inline PASM
That's not an option, there are many Python implementations out in the
wild. Having to change sourcecode for running on Parrot isn't the way to
go.
leo
Leopold Toetsch
> ... 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 making python programmers say
> "import Foo.ns.Bar.scalar.baz"
And that's not possible because CPython, JPython, IronPython, ...
wouldn't execute it.
leo
Jens Rieks
> > 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.
depends on a forgin language's module. Or how should that work?
jens
Leopold Toetsch
Oops. Severe lack of coffee on my side. But OTOH I can imagine that
finally standard modules are present in Parrot that do the right thing.
E.g. in Python
import os
would import a Parrot module that wraps these functions to Parrot. So
basically, when you have:
os.setsid() # Python
POSIX::setsid(); # Perl
these two functions would be the same, living in some Parrot lib and
aliased to the language's equivalent.
So the import or use syntax shouldn't be changed just to accomodate
Parrot's namespace internals.
> jens
leo
Jeff Clites
> [Argh...]
>
> Chip Salzenberg <ch...@pobox.com> 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', 'array') # here's a different category, to
>> get '@c'
>>
>> or some such. Yes it's ugly. But if we can't fix a ditch, the least
>> we can do is put a big friendly warning sign on it.
Turns out the ugliness isn't needed anyway; Python already has a syntax
to access a namespace entry by string name (via __dict__), and Python
import copy anyway, rather than alias. That is, this:
from os import WNOHANG
creates a "WNOHANG" variable in the local namespace with the value of
"os. WNOHANG", but it's a copy--changing one changes the other. So, one
could do this:
foo = Perl.Blah.__dict__["some-japanese-variable-name"]
when the variable name isn't something Python can accommodate directly,
and get the same result.
> Another way to do it would be to have each "category" actually be a
> namespace. In other words, Perl's namespaces are structured like
> this:
>
> File => package {
> ns => package {
> Find => package {
> sub => package {
> find => { ... }
> }
> },
> Path => package {
> sub => package {
> BUILD => { ... },
> DESTROY => { ... }
> }
> }
> ...
> },
> scalar => package {
> some_idiot => "put a variable in this package"
> }
> }
>
> And Python would access them like so:
> File.ns.Path.sub.new()
>
> Not perfect, certainly, but it would work, and be reasonably elegant.
Yep, this is exactly what I had in mind. Everything is hash-like
anyway, so whether you call the category a namespace or just something
namespace-like (since it's hash-like), doesn't matter so much, and on
the Python side they're all just things which allow named attribute
lookup.
> (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
> language's namespaces.)
I'd think that, when importing a module, you'd need a concept of what
structure of namespace you're dealing with (which maps roughly to what
language was used to implement the module, though "flat namespace"
languages might all act the same). As I touched on in another post, I
think you'd need to concept of a wrapper--for instance, when Python
code pulls in a Perl module, it would get a wrapper which acts
Pythonish, and acts as a go-between for the real namespace. (Probably,
this would be via namespace tie-ing.)
In this light, I think that going the other way is easy--all Python
variables would look to Perl like scalars holding references (since
this is the semantics that Python variables have). But see my recent
post in the "Namespaces, part 1 (new bits)" thread for some caveats.
JEff
mar...@kurahaupo.gen.nz
> With this method, the *only* place you'll run into
> trouble is in a language where any string can be a
>
> You could solve this by declaring that *all* variables
> in a namespace must begin with some sort of sigil, but
> then you can't pass a namespace to a function and have
> it be treated like a plain ole' associative array (or
> at least one with nice keys).
Why not put the sigil prefix in a separate parameter to the relevant fetch
and store opcodes, as a simple quoted literal string? Then you wouldn't have
to generate extra temporary strings to hold the concatenations, but where
you did have a string that included the appropriate sigil, it could be used
directly by having an empty prefix.
-Martin
Jeff Clites
> Jens Rieks <par...@jensbeimsurfen.de> 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
> Parrot that do the right thing.
> E.g. in Python
>
> import os
>
> would import a Parrot module that wraps these functions to Parrot. So
> basically, when you have:
>
> os.setsid() # Python
> POSIX::setsid(); # Perl
>
> these two functions would be the same, living in some Parrot lib and
> aliased to the language's equivalent.
>
> So the import or use syntax shouldn't be changed just to accomodate
> Parrot's namespace internals.
Well, it wouldn't be a syntax "change" per-se, and it wouldn't be to
accommodate Parrot--this is about language crossing.
You'd say, in Python, "import Perl.ns.Foo.ns.Bar.scalar.baz" only in
the case where the namespaces you are dealing with are of Perl origin.
This is Python accommodating Perl (or really, Perl accommodating
Python). Perl has more structure to its namespaces than Python
does--that's just a fact, and this is one way to deal with it.
In your example above, it looks like you're talking about one function,
ostensibly living in two namespaces. That's fine--if you author a
module in pasm (no HLL involved), then you get to structure your
namespace any way you want. In this case, it sounds like you'd want
your module to implement two different interfaces, one intended for
Perl, and one intended for Python. That would be fine, and it would be
optimal for both languages--at the cost of extra work for the module
implementor, explicitly taking into account multiple languages. In the
case of someone just writing a module in Perl, not thinking about other
languages at all, the compiler will create a Perl-style interface for
its namespace, and Python programmers will still be able to use this
module, just with a somewhat odd-looking interface. But this isn't a
new syntax for Python--from a Python perspective, that really is the
structure of that module. It will just look like Perl programmers
create really nested modules.
JEff