Hi, Hans Aberg <haber...@telia.com> writes:
> On 20 Jan 2011, at 16:16, Ludovic Courtès wrote: > >>> There seems to be a bug in GIT version when writing the 'values' data >>> type. >>> (list 2 (values 3 4) 5) >>> $1 = (2 3 5) >> >> This behavior is correct: in Guile 1.9, multiple-value returns are >> truncated any time the continuation expects fewer values. >> >> Here, the ‘values’ call returns 3 values, but the location where it’s >> called expects only 1, hence the automatic truncation. > > After the post, I saw that R5RS says the behavior is undefined. > > However, quietly loosing values is inviting bugs. I may seem sloppy, but I find it convenient. In the c.l.s thread you mentioned, Joe Marshall writes: With the current system, if you wish to add an extra return value, you have to adjust the code at *every* return site (provided you can enumerate all the return sites!). In Common Lisp, unexpected return values are silently discarded, so modifying a function to return extra information is a local change. Discarding the extra return values is somewhat sloppy semantically, but far more convenient from a coding standpoint. >>> with the value 4 lost In guile-1.8.8, it would write >>> (2 #<values 3 4> 5) >> >> The special “values” type in older Guile versions was an artifact of >> Guile’s implementation of multiple value support; objects of that type >> are normally invisible to user code, but they would show up in such >> situations (R5RS doesn’t specify what to do in these cases, so it was >> valid, but implementation-specific behavior.) > > The old style is a reification of the values, and could be turned into > a tuples object. The latter is what I am implementing, but I can make > my own type instead. > > It is discussed here, along with some other ideas. > > https://groups.google.com/group/comp.lang.scheme/browse_thread/thread/b72d987aa6626cd2/e2f7cfa55fb51d55?hl=en Interesting thread. Thanks, Ludo’.
