Re: GIT version: values writing

[Ludovic Courtès]

Hi,

Hans Aberg <address@hidden> 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’.