On Tue 06 Dec 2011 17:42, David Kastrup <[email protected]> writes:
> Andy Wingo <[email protected]> writes:
>
>> On Tue 06 Dec 2011 12:17, David Kastrup <[email protected]> writes:
>>
>>> I've actually wondered if it would not make sense to return
>>> *unspecified* in the case of the plain else-less if even if the
>>> condition is true, namely when you write (if #t #t).
>>
>> A first (and probably worthwhile) step would be to warn if such
>> a statement is processed for value.
>
> Well, is it being processed for value if what I do with the value is
> calling unspecified? on it in order to find out whether I should warn
> about a function returning a value when it shouldn't?
Yes, it would be.
Note, in R5RS scheme, this should be true:
(eqv? (if #f #f) (if #f #f))
In R6RS (and R7RS, I think) scheme it does not have any meaning --
implementations are free to do what they like.
The reason is that (if #f #f) returns "unspecified values" rather than a
canonical "unspecified value". So the implementation may treat it like:
(eqv? (values) (values))
which is strictly unspecified, as it is returning an unexpected number
of values to a continuation.
Guile 1.8:
guile> (eqv? (values) (values))
#f
Guile 2.0:
scheme@(guile-user)> (eqv? (values) (values))
ERROR: In procedure values:
ERROR: Throw to key `vm-error' with args `(vm-run "Zero values returned to
single-valued continuation" ())'.
Not a nicely printed error, but oh well.
Guile 2.0 returns a canonical unspecified value in this situation. I
would like to consider returning 0 values instead in the future, but
figuring out how to do so without breaking the world is tricky. It's
useful to hear about your experiences with *unspecified*.
> I am working on a language where returning values in certain contexts
> might at one point of time might lead to the values being used. So I
> need to implement warnings to that effect in order to find out calls
> _not_ returning *unspecified*...
Have you considered using `(values)' as your way of saying, "I'm not
returning any values"?
Andy
--
http://wingolog.org/
