Sunspecified object

[alms@spt.entity.com (andrew lm shalit)]

I see two reasons for having a function return an unspecified result:

1) discourage programmers from using this result.
2) give implementions flexibility, so they can operate efficiently.

Both of these goals are lost if #unspecified is introduced.

As examples, Common Lisp SETQ (and most all setting functions) are defined
to return the new value.  This is often useful, but sometimes leads to
very ugly code, for example:

    (setq temp (if (listp (setq temp (get-value)))
                   (car temp)
                   (get-another-value))

I don't think the efficiency concerns are really dramatic enough to be
a real argument against #unspecified.  On the other hand, the stylistic
issue of people using "unspecified" results programmatically is a pretty
valid argument.  Do you want things like:

  (if (eq (get-value) #unspecified) (get-value-again))

I have problems with this because it doesn't scale.  What if you want to
specify the value #unspecified?  It's an object that's likely to mess you up
when you try to use it in a first-class way.

On the other hand, #unspecified may be useful in the programming environment,
read-loop, etc, so users don't get confused and -think- they have a real value.
But I feel this should be left up to implementations, as the rest of the
programming environment is.


One question to those who favor #unspecified: what would
(if #unspecified 10 20) return?  I assume 10.  Or should it signal an
error?