[This started out just as a response, but I've been wading through the
original post at the same time so it sort of drifts]
At 02:47 PM 4/23/2001 -0300, Filipe Brandenburger wrote:
>At 05:21 PM 20/04/2001 -0400, Dan Sugalski wrote:
>>At 06:08 PM 4/20/2001 -0300, Filipe Brandenburger wrote:
>>>I'd rather be flexible on the low-level and have `default' or
>>>`catch-all' functions that call the cmp-style function than have to
>>>`trick' the language by modifying the parser to do what we want. But
>>>that's really not my choice. I only think implementing
>>>backwards-compatible `use overload' without these entries would be nasty...
>>
>>You're thinking at both too high and too low a level, I think. (I've been
>>working through what you've written, but there's rather a lot of it)
>
>Please be more specific... I really am not understanding with what you
>mean by ``too high level'' and ``too low level''. I feel you mean
>something important but I'm not getting it yet...
Well, as an example, the add opcode calls the add vtable function of the
left-hand PMC. That's it. What goes in that vtable and how it gets there
(overloading, tying, type methods, Arcturan mind control rays...) is
irrelevant, really. Talking about tying, overloading, or whatever doesn't
really matter--the only difference there is which vtable methods get
provided by perl and which the module provides. Talking about perl-level
overloading interfaces and whatnot obscures the underlying mechanisms.
Also there's the matter of whether:
$a = $b;
assigns just the value of $b, or the type as well. I'll get to that further on.
>>It might be best if everyone thought of the interpreter as essentially
>>language-neutral. Some stuff is appropriate for the interpreter
>>(basically the vtable stuff) while other things like the
>>perl-source-visible bits of overloading are more the province of the parser.
>
>Source visible bits of overloading???
Yes. The overloading interface provided to perl source. The fact that a
module has to do a "use override" and provide a PLUS method isn't really
relevant at the interpreter level. That's all parser stuff.
>I though overloading was about changing the behaviour of an operation
>without having to change the source code... I thought it was about writing
>$a + $b when what actually happens is $a->PLUS($b) or something like this...
That's essentially what is *always* going to happen. You do a:
my Foo $bar;
and the vtable for package Foo gets slammed into $bar's vtable slot. Same
thing as when you do:
tie $bar, 'Foo';
To be honest, I don't see any reason for a technical distinction between
overloading and tying in perl 6. (I can see keeping them separate at the
level presented to perl programmers for conceptual clarity reasons) There
won't even really be a difference in initial parameters, since these two:
my Foo $bar : file("login.com");
tie $bar, 'Foo', "login.com";
could potentially do the same thing at the interpreter level. (Though the
named parameters/attributes are arguably clearer)
>If you mean the parser should do the translation of ``$a + $b'' to
>something like ``$a->PLUS($b)'' (or better the call on the vtable entry of
>$a that etc. etc.), well, Ok, but if you mean the parser should do it only
>to what is overloaded, well, the parser has no way to know what is and
>what is not overloaded...
No, the parser does it regardless. The whole PLUS sub thing's a bit of a
confusing red herring. When the parser sees it (or any other "magic
function") it'll have to build up a vtable. We should, arguably,
unconditionally build up a vtable for each package and just fill it in with
default functions unless we see otherwise.
As to whether the value or value and type of a variable is copied in an
assignment, that's the province of the parser, not the interpreter. More
specifically, either or neither, if we care to alias instead) is
potentially correct. The statement:
$a = $b;
might generate the opcode stream:
destroy a;
clone a, b;
to copy both the value and type, or:
get_type temp_type_1, b;
set_value a, b, temp_type_1;
to copy the value only. Or even:
ifcustom b, 10$;
get_type temp_type_1, b;
set_value a, b, temp_type_1;
jump end;
10$:
destroy a;
clone a, b;
end:
to conditionally copy the value in the case where $b is a
non-custom-datatype, or value and type if it is. (Or do it in the case of
$a, or both, or whatever)
Heck, Larry might even mandate a weighting system where the type and value
is copied if the destination variable's type's weight is less than the
weight of the source type.
The choice of which opcode stream to spit out depends on the language
definition, which puts it in the realm of the parser, and it might be
dependent on the language source. We might, for example, copy the value if
a variable was given a type with my, and copy the value and type if it wasn't.
FWIW, I'm also thinking that reference stuff doesn't belong in vtables.
References are funky interpreter doodads and, while it's fine to have a
reference in a scalar, taking a reference and checking the type of a
reference really don't belong in the vtable.
Also, I think all the character set/string handling bits might want to be
abstracted out into a separate set of tables outside the variable vtables.
The core will probably need to be doing character conversions and such
without necessarily involving actual scalars/hashes/arrays, so the proper
place for it all is in character encoding loadable modules. (Or something
of the sort)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
