pierce@lanai.cs.ucla.edu (05/23/89)
I think that the specification of Scheme, as well as many Scheme programs, would be made more elegant if an "unspecified-object" analogous to NaN in the IEEE numeric standard were introduced. Functions which return unspecified values now would be required to return an "unspecified-object" instead. -- Brad
jar@ZOHAR.AI.MIT.EDU (Jonathan Rees) (05/25/89)
Date: 23 May 89 01:51:40 GMT
From: pierce@locus.ucla.edu
I think that the specification of Scheme, as well as many Scheme programs,
would be made more elegant if an "unspecified-object" analogous to NaN in
the IEEE numeric standard were introduced. Functions which return
unspecified values now would be required to return an "unspecified-object"
instead.
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.mccarrol@topaz.rutgers.edu (Mark C. Carroll <MC>) (05/25/89)
In article <24169@shemp.CS.UCLA.EDU> pierce@lanai.cs.ucla.edu writes:
] I think that the specification of Scheme, as well as many Scheme programs,
] would be made more elegant if an "unspecified-object" analogous to NaN in
] the IEEE numeric standard were introduced. Functions which return
] unspecified values now would be required to return an "unspecified-object"
] instead.
]
] -- Brad
I agree quite strongly with this. The scheme that I've been hacking at
lately is Ed Puckett's AmiScheme for the Amiga. In Amischeme, there is
an object called #u, the sole member of the "unit" domain. Any
internal function that the standard says returns an "unspecified"
result returns #u. In my functions, I try to do this also - any
function that exists for its side-effects returns #u. In addition to
adding clarity, it has proven quite useful for debugging.
<MC>
--
=| Mark Craig Carroll: <MC> |=
=| mccarrol@topaz.rutgers.edu,...!rutgers!topaz!mccarrol |=
=| "Your only obligation in any lifetime is to be true to yourself" |=
=| -Richard Bach,_Illusions_ |=pierce@lanai.cs.ucla.edu (Brad Pierce) (05/25/89)
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. -- Brad
dorai@titan.rice.edu (Dorai Sitaram) (05/26/89)
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. -------------------------------------------------------------------------------