efficiency vs functionality

[Kent Dybvig <dyb%indiana.csnet@CSNET-RELAY.ARPA>]

A letter to the editor.

After sending my last note I got to thinking about how many
arguments for or against a particular feature have been based
on how difficult efficient implementation becomes.  Decisions
are often made by weighing functionality against efficiency
(as in the splitting/coalescing discussion).

It seems that the early development of Scheme was not affected
by efficiency arguments, otherwise who would have first-class
closures or continuations?  Would we like Scheme as much today
if the efficiency trade-offs had been factored in?  Would we
have bothered to learn how to implement first-class closures
and continuations efficiently if we did not have them in our
language?

Sure, we want to give implementors a fair chance to compete in
speed with other languages, but we may be making it a little to
easy on them.  At the very least, the decisions should be along
the lines of feasibility of efficient implementation, not ease
of efficient implementation.  We should never make life harder
for the user to make life easier for the implementor.

Tomorrow's editorial topic: the effect of "historical reasons,"
"existing documentation," and "1,000,000 lines of existing code"
on language design and standardization.