lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> Because the second operand of an opcode can be a constant. So, Lua tries
> to move constants to the second operand (0<a => a<0, 2*x => x*2, etc.)

That's a code generation detail, since it only applies to built-in types
(numbers, in particular). So you can't tell as a programmer, so it needn't
be a rule of the language.

> Both in sets and matrices '+' is associative (well, assuming + is set
> union).

Yes, I suppose I'm thinking of things like monads where there's state 
involved in each operation, so changing the order of operations changes 
the effect on the (internal) state.

> Maybe we could specify when Lua changes the order? (It is only in the
> case that the first operand is a constant and the second is not; or it
> could be ;-)

If you specify, like Java, that the effective order is always as given by 
the programmer, then you're free to change the order as you do above 
(within IEEE rules), and you don't have to say anything about it in the 
language definition.

> Lua never breaks parentheses. If you really want "1.0 + (eps + eps)",
> keep the parentheses and Lua will respect your wish.

Great. That makes it easy to Do The Right Thing.

So I'd be happy with: drop optimisations of associative operations, and
don't mention optimisation of commutative operations in the language
definition, but only do it in cases where it makes no difference. Should
keep the performance win, make tagmethod/metamethod propeller-heads happy,
and slightly simplify the implementation, all in one go.

-- | Travail broadens the behind