Re: when and unless

[David Kastrup]

"Chris K. Jester-Young" <address@hidden> writes:

> On Thu, Dec 08, 2011 at 09:42:36AM +0100, David Kastrup wrote:
>> So here is another proposal: (values) is not the same as *unspecified*.
>> But if you take the first value of a values list in single-value
>> contexts, there is nothing about that coercion mechanism that would keep
>> you from using *unspecified* whenever that values list would be empty.
>
> That's easy to implement (patch at bottom of post; I tested it). The
> question for the people on the list to decide is whether it's a good
> idea. :-) Personally, I don't object to it, but, perhaps others do.

Well, the bad thing about it is that using *unspecified* explicitly is
not equivalent to what Guile does (presuming that it uses (values)
whenever it does not return a value) even though it counts as eq?, just
like using (values #t #t) is not equivalent to what #t does, but will
still count as eq?.

It is somewhat similar to how Lua deals with nil (which is a mixture of
SCM_UNSPECIFIED and SCM_UNDEFINED in semantics) and tail call argument
lists and multiple/single/no value returns.  You can figure out the
difference between a nil return value and none, but not without
tail-calling another function in which you explicitly ask for the number
of arguments.

Anyway, in Guile there are wagonloads of C functions that return exactly
1 value.  I don't think you can always just let them blow up when they
don't have a value to deliver.  That would be a major migration pain.

If you want to discourage people at one time from confusing the two, let
the REPL print *unspecified* when that (rather than no value at all) is
returned.  But I don't think that you should start with this too early.
I suppose user-defined C functions, instead of returning
SCM_UNSPECIFIED, would have to call something like scm_return_values
(SCM_UNDEFINED); instead.

-- 
David Kastrup