🚀 go-pugleaf

david@gdstech.grumman.com (David Nettles) writes:

>Are lazy languages faster than eager languages?

>My intuition says that a lazy language would be a lot faster than an
>eager language simply because the eager language evaluates all of its
>arguements regardless of whether they are all needed by the function.

>The lazy language, by evaluating only what is necessary, appears to
>save time.

This reminded me of something else, which I thought maybe I'd bring
up, which is on a soemewhat related topic.  Anybody thought about the
question of _why_ CBV is more efficient?  I mean, for a theoretician,
there seems to be no really good answer.  But I'd like to be able to
argue for efficiency from purely theoretical grounds, and since I'm
interested in programming-languages research, that means to predict
the efficiency of programming languages.  Of course this depends on
all sorts of things - the quality of the implementation is paramount.
But there ought to be something which theory can say other than the
standard "asymptotic complexity" arguments - after all,

      almost compiler optimization comes down to shaving
      constant factors, eh?

So, anyway, on to CBV versus CBN:

(1) Looking at abstract machines, it seems like CBN should be the
    naturally more efficient evaluation mechanism.

(2) I had this conjecture that maybe it was the "simplicity of the
    standard reduction function" - but here, too, CBN wins - the CBV
    standard reduction sequence definitions are rather more
    complicated than those for CBN.

In the end, it came down for me to something disgustingly applied -
the frequency of expressions which are weak-head-normalizable to
closure-free objects (i.e. which compute to data-values) is very high
in normal programs - so CBV wins because it "represents" them
efficiently - as the values they denote.

In other words, the cost of manipulating "thunks" overwhelms the
savings from not evaluating unneeded arguments.  This seems like an
awfully specious argument, from a theoretical standpoint, and I sure
would like to hear something more firm.

--chet--