Dan Sugalski <[EMAIL PROTECTED]> wrote:
This becomes a bit less efficient when we're looking at intermediate values of expressions. Something like:
a = b + c + d
turns to
new $P0, SomeIntermediateType add $P0, b, c add a, $P0, d
and we need to create that $P0 temp beforehand. While that's fine, it leave things to the compiler to figure out what the intermediate type should be, and often ends up creating two temps instead of one.
Well, yes. It's up to the compiler. Perl6 would insert
$P1 = new PerlUndef
and Pie-Thon would have a C<new PieScalar> or such.
Except that in a multi-language environment (such as the one we're encouraging) the compiler can't know for sure what to insert, if theres a choice.
Why should it create two temps?
Well, if the vtable function that adds $P0 and D doesn't know anything about the structure of A (so it can't poke at its innards directly) it has to hand a value to A's assign method. If the addition of $P0 and D produces a non-simple value (something that's not an int, float, or string) then it'll end up creating a temp PMC, and calling set_pmc on A. That
> Moreover, it's distinctly possible that the temp that's created isn'tthe right type, as the compiler may not know what the intermediate expression will return.
The C<new Undef> something has to morph itself into an appropriate type IMHO.
I'm leaning that way myself, but I'm not 100% convinced yet.
> I see three options:
I think its really up to the HLL compiler to generate a suitable LHS PMC that (accompanied by appropriate assign vtables) does the right thing.
As I've said, it can't. There's too much uncertainty.
To you have examples, which indicate that this isn't possible?
Start mixing overloaded objects, python, perl 5, perl 6, ruby, and lisp returned values in an expression. It's not tough to come up with a whole slew of reasonable possibilities.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
