"Chris K. Jester-Young" <cky...@gmail.com> 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
