Path: utzoo!utgpu!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ukma!rutgers!aramis.rutgers.edu!topaz.rutgers.edu!mccarrol
From: mccarrol@topaz.rutgers.edu (Mark C. Carroll <MC>)
Newsgroups: comp.lang.scheme
Subject: Re: unspecified-object
Keywords: standard, unspecified
Message-ID: <May.24.18.03.52.1989.19703@topaz.rutgers.edu>
Date: 24 May 89 22:03:56 GMT
References: <24169@shemp.CS.UCLA.EDU>
Distribution: na
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 24

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_                      |=