Re: unspecified-object

[Dorai Sitaram <titan!dorai@rice.edu>]

In article <24244@shemp.CS.UCLA.EDU> pierce@cs.ucla.edu (Brad Pierce) writes:
$In article <8905241845.AA02829@zohar> jar@zurich.ai.mit.edu writes:
$
$>It doesn't make sense to specify that the object to be returned should
$>be unspecified.  It seems to me that if some specific object is to be
$>specified, then it should be a specific object, not an unspecific one.
$>Besides, if we specify what object should be returned, then that
$>object will no longer be unspecified.
$
$When a procedure is applied to valid input and the result is unspecified,
$valuable information is lost.  I am suggesting removing the possibility of
$leaving unspecified the result of valid procedure applications. I am also
$suggesting that there be a special object which represents the important
$information which is currently discarded. Practical benefits aside, I 
$simply find it aesthetically unpleasant to pass around values which have no
$information content, when an alternative approach is possible.

The above (Brad's posting, not jar's) goes against the principle of
orthogonality in Scheme's choice of primitives and core syntax. Let me
see if I can explain the violation in a "few" words. 

Each expression in Scheme returns a value, since Scheme is an
expression-oriented language. However the reason behind a primitive
procedure or a core syntax may not always be manifested in the value
produced by an expression using this primitive procedure or core
syntax. Some of these primitives may be there for producing
side-effects, e.g., set! or print. (Expressions using these primitives
are usually called "commands" in other languages.) The main point of
these primitives being the side-effect, it is not fair to burden them
with any responsibility other than their main goal. Ergo, they are
free to return an unspecified object.

The reason why Standards specify "unspecifiedness" (this is not
necessarily oxymoronic) is that they don't want someone to write
programs making use of the value returned by these command-type
primitives. Such a program is making use of a coincidental and totally
ad hoc (i.e., one with no semantic(s) underpinning) piece of
information, and as such, very likely requires rewriting.

(BTW, I don't understand how "specifying" the "unspecified-object"
facilitates debugging, as has been claimed by two posters.)

--dorai
-------------------------------------------------------------------------------
It may be that the gulfs will wash us down;
It may be we shall touch the Happy Isles.
-------------------------------------------------------------------------------