RE: [CVS ci] object stuff
At 3:42 PM -0500 12/11/03, Melvin Smith wrote: At 03:05 PM 12/11/2003 -0500, Gordon Henriksen wrote: Melvin Smith [EMAIL PROTECTED] wrote: my $foo = Oracle::Instance::DEV1::db_block_buffers; The namespace lookup in Oracle::Init checks the Oracle config parameters which is external code. All sorts of neat possibilities. :) It is truly remarkable the lengths that Perl programmers seem to be willing go to in order to hide a function call or obscure the existence of an object. :) I'm not an advocate of the feature, but it is novel. Tying is a requirement of Perl, or so Dan has told me. I'm not sure if Larry'll mandate it for perl 6, but I don't care--we're going to be able to have tied namespaces for parrot. We *must*, since that's a very good way of maintaining method caches, handling debugger data watching, and a variety of other interesting tricks one might wish to play without the knowledge of the code you're spying on or interfering with. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [CVS ci] object stuff
On Dec 10, 2003, at 12:37 AM, Luke Palmer wrote:
Dan Sugalski writes:
At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote:
set I2, P1[Foo\x00i] # I1 == I2
gets currently the attribute idx (0) of $Foo::i.
Q: Should the assembler mangle the Foo::i to Foo\0i
I don't like it either, but the alternative is to impose an external
hierarchic structure. Which we certainly could do, though it may make
some things more difficult.
I'm more than willing to entertain arguments for and against the
hierarchic structure, but we're closing in on the point where we fix
the scheme and don't change it any more.
I'm not sure mangling is a good idea: think about anonymous classes.
If
we assign a name to each lexical class, then there are problems when
one
instance of a class inherits from another instance of the same class.
That is:
sub make_class(Class $parent) {
return class is $parent {
has $.stuff;
}
}
my $class1 = make_class(Object);
my $class2 = make_class($class1);
So, if you name that lexical class _class_0001 or something,
_class_0001\0$.stuff refers to both attributes.
Melvin pointed out another reason why this shouldn't actually conflict,
but I'll also say: I would think that anonymous class wouldn't have
names (pretty much by definition), not even generated ones. So to
access class attributes of anonymous classes, you'd have to use
something like:
$class1-get_attribute(.stuff)
I don't know what actual syntax Perl6 would use, but what I mean to say
is that for an anonymous class you'd have to access anything about it
via a reference to the class object, not via name (since it won't have
one).
If you generate a name for each instance of a lexical class, you're
setting yourself up for some major runtime cost -- concatenating the
class name to the attribute on each access (or memory cost if you want
to cache).
I would think that we'd want to do it so that we don't have to do
by-name lookups behind the scenes if we're not doing that up front.
That is, I'd think that
$Foo::Bar::Baz::egg = 4;
would be doing a lookup to find the namespace Foo::Bar::Baz (may be
hierarchical or not), and then a lookup of egg in that. But that:
package Foo::Bar::Baz
sub something
{
$egg = 4;
}
would be able to do a more direct lookup. (That is, it would look up
egg in the package namespace without having to go find the package
namespace by name.)
I think a heirarchy is a good idea for namespacing in general. I've
always wanted to be able to tie namespaces in Perl 5. It would only
make sense that if I tie Foo::, that Foo::anything:: would also go
through that tie to get the anything:: stash.
What do you mean by tie here? Are you talking about namespace
aliasing, so that I can alias Foo to A::B::C::D::E, so that I can
say Foo::bar rather than A::B::C::D::E::bar? If so, it seems that
this would work with or without a hierarchical structure. Definitely
useful, though.
JEff
Re: [CVS ci] object stuff
I think a heirarchy is a good idea for namespacing in general. I've always wanted to be able to tie namespaces in Perl 5. It would only make sense that if I tie Foo::, that Foo::anything:: would also go through that tie to get the anything:: stash. What do you mean by tie here? Are you talking about namespace aliasing, so that I can alias Foo to A::B::C::D::E, so that I can say Foo::bar rather than A::B::C::D::E::bar? If so, it seems that this would work with or without a hierarchical structure. Definitely useful, though. Tying a namespace will involve allowing a namespace to basically hide its implementation, have a custom lookup routine, back-store its symbols, etc. I might tie a namespace to an Oracle database, so a lookup is really a callout to database code. my $foo = Oracle::Instance::DEV1::db_block_buffers; The namespace lookup in Oracle::Init checks the Oracle config parameters which is external code. All sorts of neat possibilities. :) -Melvin
RE: [CVS ci] object stuff
Melvin Smith [EMAIL PROTECTED] wrote: my $foo = Oracle::Instance::DEV1::db_block_buffers; The namespace lookup in Oracle::Init checks the Oracle config parameters which is external code. All sorts of neat possibilities. :) It is truly remarkable the lengths that Perl programmers seem to be willing go to in order to hide a function call or obscure the existence of an object. :) -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
RE: [CVS ci] object stuff
On Thu, 2003-12-11 at 12:05, Gordon Henriksen wrote: It is truly remarkable the lengths that Perl programmers seem to be willing go to in order to hide a function call or obscure the existence of an object. :) Not all of the poly- and allomorphism in the world comes from traditional object orientation. Syntax has to be good for something! -- c
Re: [CVS ci] object stuff
On Dec 9, 2003, at 3:40 PM, Dan Sugalski wrote: At 5:46 PM +0100 12/5/03, Leopold Toetsch wrote: Melvin Smith [EMAIL PROTECTED] wrote: At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote: set I2, P1[Foo\x00i] # I1 == I2 gets currently the attribute idx (0) of $Foo::i. Q: Should the assembler mangle the Foo::i to Foo\0i Why was this even needed in this example? Since P1 was the class Foo, why do we need scoping here--shouldn't the above just be: set I2, P1[i] # I1 == I2 Something about this embedded \0 character bugs me. I know its what Dan has in the design doc but it just seems too cryptic. Yeah its ungly. OTOH it should be really transparent for all possible HLLs. And the NUL most certainly is. I don't like it either, but the alternative is to impose an external hierarchic structure. Which we certainly could do, though it may make some things more difficult. I'm more than willing to entertain arguments for and against the hierarchic structure, but we're closing in on the point where we fix the scheme and don't change it any more. I don't see a big advantage of using a null byte over any other character--a null may seem unlikely to conflict with an HLL, but that's just hoping. If we're going to define a syntax, then we may as well make it easy to print out in the debugger, and use . or :, and either restrict identifiers to be underscore-letter-number combinations, or define an escaping syntax so that foo\.bar.baz means baz in the foo.bar namespace (ugly, but workable). If we _really_ want these to be strings and reserve some special character, then we should pick something in the Unicode private use area. But either way, I think we need an escaping syntax, so that I can really have a null byte (or whatever) in the middle of something. If we really want to allow the most freedom possible to HLLs, then these should be specified as arrays--no special characters needed. That is, foo:bar:baz in Perl code would assemble into an array of foo, bar, and baz (and foo.bar.baz in Java would assemble to the same thing). It would be natural then to store these in nested hashes, but not 100% necessary. I think this is what you meant by a hierarchic structure. It seems straightforward, though with some overhead. We could get around the need for hashes by defining an escaping scheme as mentioned above, but as an internal implementation detail--that is, the API uses arrays, but internally uses strings. Hiding that detail lets us change it later. JEff
Re: [CVS ci] object stuff
Dan Sugalski writes:
At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote:
set I2, P1[Foo\x00i] # I1 == I2
gets currently the attribute idx (0) of $Foo::i.
Q: Should the assembler mangle the Foo::i to Foo\0i
I don't like it either, but the alternative is to impose an external
hierarchic structure. Which we certainly could do, though it may make
some things more difficult.
I'm more than willing to entertain arguments for and against the
hierarchic structure, but we're closing in on the point where we fix
the scheme and don't change it any more.
I'm not sure mangling is a good idea: think about anonymous classes. If
we assign a name to each lexical class, then there are problems when one
instance of a class inherits from another instance of the same class.
That is:
sub make_class(Class $parent) {
return class is $parent {
has $.stuff;
}
}
my $class1 = make_class(Object);
my $class2 = make_class($class1);
So, if you name that lexical class _class_0001 or something,
_class_0001\0$.stuff refers to both attributes.
If you generate a name for each instance of a lexical class, you're
setting yourself up for some major runtime cost -- concatenating the
class name to the attribute on each access (or memory cost if you want
to cache).
I think a heirarchy is a good idea for namespacing in general. I've
always wanted to be able to tie namespaces in Perl 5. It would only
make sense that if I tie Foo::, that Foo::anything:: would also go
through that tie to get the anything:: stash.
There are, of course, disadvantages. It would be slower for cases where
$something::or::other are acessed a lot, as it's three lookups in the
absence of cache. Also, it's not as easy to tell where a symbol table
entry came from. I don't think either of these are major concerns, but
it depends on our ultimate goals.
I definitely want to tie namespaces though.
Luke
Re: [CVS ci] object stuff
On Wed, Dec 10, 2003 at 01:37:22AM -0700, Luke Palmer wrote:
I think a heirarchy is a good idea for namespacing in general. I've
always wanted to be able to tie namespaces in Perl 5. It would only
make sense that if I tie Foo::, that Foo::anything:: would also go
through that tie to get the anything:: stash.
That's a good point.
Another related one include any perl code that
manipulates/introspects/iterates over a package.
Package aliasing (something like *{Bar::} = \*{Foo::}) might
not work well in Perl 5 but I think Perl 6 is meant to be able to
do things along those lines.
But there may be some misunderstanding here (perhaps just on my part :)
Given
package Foo::Bar::Baz;
$var = 1;
In perl5 the var variable is stored something like this (excuse the
probably imprecise syntax, but you'll get the idea):
*{Foo::}-{Bar::}-{Baz::}-{var};
For parrot I'm not sure if Dan was proposing
*{Foo\0Bar\0Baz}-{var};
or
*{Foo\0Bar\0Baz\0var};
The first just flattens the package name but keeps the contents of
the package as distinct elements within the package 'object'.
The second flattens both the package name and the name of the item
within the package into a single key.
I think Dan was proposing the first and that's fine.
I think the second would be a mistake.
Tim.
Re: [CVS ci] object stuff
At 01:37 AM 12/10/2003 -0700, Luke Palmer wrote:
Dan Sugalski writes:
At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote:
set I2, P1[Foo\x00i] # I1 == I2
gets currently the attribute idx (0) of $Foo::i.
Q: Should the assembler mangle the Foo::i to Foo\0i
I don't like it either, but the alternative is to impose an external
hierarchic structure. Which we certainly could do, though it may make
some things more difficult.
I'm more than willing to entertain arguments for and against the
hierarchic structure, but we're closing in on the point where we fix
the scheme and don't change it any more.
I'm not sure mangling is a good idea: think about anonymous classes. If
we assign a name to each lexical class, then there are problems when one
instance of a class inherits from another instance of the same class.
That is:
sub make_class(Class $parent) {
return class is $parent {
has $.stuff;
}
}
my $class1 = make_class(Object);
my $class2 = make_class($class1);
So, if you name that lexical class _class_0001 or something,
_class_0001\0$.stuff refers to both attributes.
I don't think so. I'm definitely not up to your level regarding Perl6 but I
believe
the example you give translates to:
1st call
return class is Object {
has $.stuff # Object::_class_0001::$stuff
}
2nd call
return class is _class_0001 {
has $.stuff # Object::_class_0001::_class_0002::$.stuff
}
No collision.
$class2 has 2 $stuffs but at different class scopes.
I'm also not disagreeing, I prefer a hierarchical approach as well but I
need to
take time to formulate a good argument for Dan.
If you generate a name for each instance of a lexical class, you're
setting yourself up for some major runtime cost -- concatenating the
class name to the attribute on each access (or memory cost if you want
to cache).
This is why I don't like the non-hierarchical approach.
There are, of course, disadvantages. It would be slower for cases where
$something::or::other are acessed a lot, as it's three lookups in the
absence of cache. Also, it's not as easy to tell where a symbol table
I think this is a Perl6 problem more than a Parrot problem since no matter
how many optimizations we add to Parrot, Perl6 may or may not be
able to use them due to the dynamic nature it has.
I definitely want to tie namespaces though.
Me 2.
-Melvin
Re: [CVS ci] object stuff
At 12:16 PM 12/10/2003 +, Tim Bunce wrote:
*{Foo\0Bar\0Baz}-{var};
or
*{Foo\0Bar\0Baz\0var};
[snip]
I think Dan was proposing the first and that's fine.
I think the second would be a mistake.
Using a character that won't collide with HLL has a disadvantage
in the general case:
1) ALL qualfied names (not some) have to be translated/mangled.
What is the benefit, then, if all HLL compilers have to mangle it anyway?
It be a bit friendlier to make the scope resolution operator something
that at least 1 or 2 languages use as their own already; then all the rest
still have to mangle.
Benefits:
-Some languages don't have to translate, so they win.
-Parrot hackers don't have to write 'Foo\0Bar\0Baz'!
-Compiler hackers have enough headaches without worrying about handling
strings with embedded null characters.
-Melvin
PS: I still haven't seen Dan say if he has some other neat cheat trick
in mind for using \0. I can see that it would be pretty fast for tokenizing
Foo\0Bar\0Baz into its components given C strcpy semantics.
RE: [CVS ci] object stuff
Quoth Melvin Smith: It be a bit friendlier to make the scope resolution operator something that at least 1 or 2 languages use as their own already; then all the rest still have to mangle. Uh oh, time to vote?
RE: [CVS ci] object stuff
At 11:34 AM 12/10/2003 -0600, Robert Eaglestone wrote: Quoth Melvin Smith: It be a bit friendlier to make the scope resolution operator something ^^ ACK that at least 1 or 2 languages use as their own already; then all the rest still have to mangle. Uh oh, time to vote? Voting for myself for having the most consecutive posts with bad grammar. -Melvin
Re: [CVS ci] object stuff
On Wed, Dec 10, 2003 at 12:26:04PM -0500, Melvin Smith wrote:
At 12:16 PM 12/10/2003 +, Tim Bunce wrote:
*{Foo\0Bar\0Baz}-{var};
or
*{Foo\0Bar\0Baz\0var};
[snip]
I think Dan was proposing the first and that's fine.
I think the second would be a mistake.
Using a character that won't collide with HLL has a disadvantage [...]
I should clarify that I wasn't suggesting \0 itself was good, just the
principle that package names are stored as a single string and the names
of package contents don't include the package name.
I've no strong view about \0 vs other (presumably utf8) byte sequences.
Tim.
Re: [CVS ci] object stuff
At 5:46 PM +0100 12/5/03, Leopold Toetsch wrote: Melvin Smith [EMAIL PROTECTED] wrote: At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote: set I2, P1[Foo\x00i] # I1 == I2 gets currently the attribute idx (0) of $Foo::i. Q: Should the assembler mangle the Foo::i to Foo\0i Something about this embedded \0 character bugs me. I know its what Dan has in the design doc but it just seems too cryptic. Yeah its ungly. OTOH it should be really transparent for all possible HLLs. And the NUL most certainly is. I don't like it either, but the alternative is to impose an external hierarchic structure. Which we certainly could do, though it may make some things more difficult. I'm more than willing to entertain arguments for and against the hierarchic structure, but we're closing in on the point where we fix the scheme and don't change it any more. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [CVS ci] object stuff
At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote: set I2, P1[Foo\x00i] # I1 == I2 gets currently the attribute idx (0) of $Foo::i. Q: Should the assembler mangle the Foo::i to Foo\0i Something about this embedded \0 character bugs me. I know its what Dan has in the design doc but it just seems too cryptic. -Melvin
Re: [CVS ci] object stuff
Melvin Smith [EMAIL PROTECTED] wrote: At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote: set I2, P1[Foo\x00i] # I1 == I2 gets currently the attribute idx (0) of $Foo::i. Q: Should the assembler mangle the Foo::i to Foo\0i Something about this embedded \0 character bugs me. I know its what Dan has in the design doc but it just seems too cryptic. Yeah its ungly. OTOH it should be really transparent for all possible HLLs. And the NUL most certainly is. -Melvin leo
