[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
>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.