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...



>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??? 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...

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...

Or you mean the perl-source-visible bits of *defining* overloaded 
behaviour? I think these should be easy once we have the underlying model 
to support overloading...

- Branden

Reply via email to