More on Full Specification

[David Bartley <bartley@mips.csc.ti.com>]

From: Paul Hudak <hudak-paul@YALE.ARPA>
>[Concerning indeterminate argument evaluation order:]
>I wasn't around when the decision was made, so can't say whether it
>was "deliberate" or not, but in what sense is it "desireable"?
>Presumably the motivation for this was to allow implementation
>freedom, so why only stop half-way?  My guess is that the intent was
>as Robert Hieb states, except for the concurrency part (but maybe that
>was in somebody's mind too).  I wonder how many current
>implementations permute the arguments in different ways depending on
>context?  Seems useful to me ... and fully within the motivation for
>underspecification in the first place.

We certainly do, and it is indeed useful.

From: Robert Hieb <hieb@iuvax.cs.indiana.edu>
>Finally a note about implementation issues.  Although, as one greatly involved
>with implementing Scheme, I can understand their seduction, I think
>we should fight it.  First-class procedures and continuations combined with
>lexical scoping, assignments and indefinite extent for variables appeared 
>to deliver a knockout blow to implementation efficiency.  The fact that 
>good implementation techniques have appeared anyway is good reason not to
>be too quick to worry about implementations.  After all, an implementation
>can do what it pleases as long as no one can tell the difference.  Thus
>if it can prove that order of evaluation doesn't matter, or that variables
>can't be referenced before definition, it can make appropriate optimizations.
>The next great step in Scheme efficiency will require extensive program
>analysis anyway.  I think people are still attracted to Scheme by the
>structure and semantics of its powerful features, and that is what we should 
>concentrate on.

I don't think those features "appeared to deliver a knockout blow to
implementation efficiency."  What they did do (in combination) was
force us to look at compiling in new ways.  I was pleased, but not
terribly surprised, when we found efficient ways to cope with them.

It's a different story with your suggestions.  Fixing the order of
evaluation of arguments, for instance, has problems for optimising
compilers that are well known.  I could win with global analysis in
Pascal because I could see the entire program at a time and didn't
have real first-class procedures to deal with, but I'm stymied in
Scheme most of the time.

I agree with the spirit of your argument, though.  We shouldn't cast
in concrete only those language features that we already know how to
do well.

From: willc@tekchips.crl
>		 [...] I generally agree with Robert Hieb's analysis.
>I happen to think, however, that the three concrete underspecifications
>that Hieb proposed to fix (value returned by side-effecting procedures,
>order of evaluation of arguments, order of evaluation of definitions)
>are among the most justified underspecifications in all of Scheme.  Each
>of these underspecifications concerns something that programmers ordinarily
>do not care about because it doesn't matter; they have the effect of
>requiring programmers to write some explicit code in the exceptional case
>when they do want to use a specific value or order of evaluation.  If
>these underspecifications were "fixed", programs would be harder to read
>because you would have to assume that the order matters whenever you see
>a procedure call or internal definitions.  As things stand now, you know
>the order doesn't matter and this fact makes it easier to understand the
>program.

I think Will has summarized my thinking beautifully, so I'll leave it
at this: I agree that we should tighten up inadvertant or lazy
underspecification, but there are places, such as these, where it is
appropriate.

--db--