Full Specification

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

>Three sources of underspecification:
>
>   1. Failure to achieve consensus on what a full specification should be.
>   2. A desire to not unduly impede implementations.
>   3. Attempting to simplify the specification by ignoring accidental or
>      unessential details.
>
>The first is unfortunate, and we should do better.
>
>The second is reasonable but not compelling.  Language designers
>should don their user hats.  From the standpoint of the user implementation
>considerations are significant only if they greatly affect speed, memory
>usage or reliability.  Thus implementation considerations should have veto
>power and perhaps be allowed to vote in case of a tie, but otherwise
>stay in the background (like a good implementation).

Yeah, but...  For a relatively new language like Scheme, we can't
always predict which language "features" will greatly affect
performance.  In my experience, the more I look at alternative
computer architectures (e.g., parallel processing) and alternative
compilation/optimization techniques, the more important under-
specification can become.  Still, our use of under-specification in
the document is often ad hoc and subjective, and I agree that we could
use some discussion on the topic.