[CVS ci] object stuff
Leopold Toetsch
try to call a method.
Some remarks:
newclass P1, "Foo"
addattrib I1, P1, "i"
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"
Same with method calls:
newclass P2, "Foo"
set S0, "meth"
callmethcc # wants "Foo\x0meth"
end
.mangle "::" "\x00" # mangle from to
.pcc_sub Foo::meth:
...
And finally, I don't know, if Parrot_add_attribute() does the Rigth
Thing, please have a look at it.
Comments welcome
leo
Melvin Smith
> 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
Leopold Toetsch
Yeah its ungly. OTOH it should be really transparent for all possible
HLLs. And the NUL most certainly is.
> -Melvin
leo
Dan Sugalski
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
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Jeff Clites
> At 5:46 PM +0100 12/5/03, Leopold Toetsch wrote:
>> Melvin Smith <mrjol...@mindspring.com> 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
Luke Palmer
> 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"
>
> 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
Tim Bunce
>
> 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.
Melvin Smith
>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
Melvin Smith
> *{"Foo\0Bar\0Baz"}->{var};
>or
> *{"Foo\0Bar\0Baz\0var"};
>
>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.
Robert Eaglestone
>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?
Melvin Smith
>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?
Voting for myself for having the most consecutive posts with bad grammar.
-Melvin
Tim Bunce
> At 12:16 PM 12/10/2003 +0000, 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.
>
>
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.
Jeff Clites
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
Melvin Smith
>>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
Melvin Smith
>Melvin Smith <mrjol...@mindspring.com> wrote:
>
> >
> > The namespace lookup in Oracle::Init checks the Oracle config
> > parameters which is external code.
> >
> > All sorts of neat possibilities. :)
>
>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. Now that I think of it, I'm not sure I've seen
any official requirement for tying namespaces, but it is probably orthogonal
to tying classes. You might not want to take my example seriously
as I'm not a Perl6 authority.
-Melvin
Gordon Henriksen
> 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.
gor...@iclub.com
Chromatic
> 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
Dan Sugalski
>At 03:05 PM 12/11/2003 -0500, Gordon Henriksen wrote:
>>Melvin Smith <mrjol...@mindspring.com> 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.