Thoughts on laziness (long)

[matthias@REDACTED]

 > Advantages of gb-trees are that they are much more lightweight (an empty
 > tree is a tuple {0, nil}, so you can create and throw away as many as you
 > like on the fly, and that they do no copying, since they reside on the
 > local heap - you could try the same test inserting/updating/fetching some
 > bigger things than integers and see the difference.

Yes. If I use larger erlang structures, e.g. large tuples, large
lists, there's a marked slowdown in ETS. (If I avoid copying by using
binaries, there's no slowdown).

 > They should perform better in native code compared to ETS than under the
 > BEAM emulator, but in general the complexity of the algorithms would
 > remain the same.

I remember reading that the 'Mercury' people hoped to be able to
perform complexity reducing source->source transforms. Does HIPE do
that, or does the potential (I read "in general" to mean "there are
some cases where we can do better". That may have been reading too
much into what you wrote.) come from 'striking it lucky' when doing 
(local) optimisations on object code?

Matthias