Re: Associativity

[Reuben Thomas <rrt@...>]

On Mon, 12 Aug 2002, Roberto Ierusalimschy wrote:

> > I was just glancing at the "Incompatibilities with version 3.2" section of 
> > the 4.0 manual, and read the bit that says "The pre-compiler may assume 
> > that some operators are associative, for optimizations".
> > 
> > Is this still the case in 5.0?
> 
> Yes. (And not only associative, but commutative, too.)

When is reversing the order of operands in a (built-in) commutative 
operator useful?

> > If so, is it worth removing? You can always make the optimisation by hand, 
> > and it avoids creating hard-to-find bugs in code with non-associative tag 
> > methods.
> 
> I don't like the idea of optimizing by hand. For instance, what
> about  "x = a..b..c..d" and "x = a..(b..(c..d))" ?

I'd assumed that .. associates to the left, since it's the natural way to 
build strings.

> Or to translate a formula "2x+1" as "x*2 + 1" (instead of a more natural
> "2*x + 1")?

Why does that help?

> I think that someone that puts a non-associative tag method into '+' is
> asking for hard-to-find bugs ;-)

There are plenty of algebras in which + isn't associative (or * isn't 
commutative). What about implementing algebras for sets or matrices? It's 
nice to use + and *, but the optimiser can easily mess up your program.

Also, it's natural to make tag methods for * to mean repetition (e.g. for
strings and lists. This * is not commutative.

Finally, the time taken by a tag method is often dependent on the size of
one of its arguments. In this case, "optimisations" can actually pessimise
(!) your program if your operator is more efficient in the other direction
from the built-in one.

It just seems to me that this is another place to make Lua simpler and
more flexible (both the language and the implementation) without
sacrificing much (these optimisations are rarely going to make a big
difference, and if they do, you can do them by hand anyway).

-- 
http://www.mupsych.org/~rrt/ | Analogy is a midwife, identity a murderer