GIT version: values writing

GIT version: values writing

[Hans Aberg]

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)
with the value 4 lost In guile-1.8.8, it would write
   (2 #<values 3 4> 5)

The top level write out all values:
   (values 3 4)
   $2 = 3
   $3 = 4

The values correspond to tuples, so they might be written out as  
ordinary tuples, though that is perhaps not Scheme style.

GIT version: values

[Hans Åberg]

It seems it is not only 'values' writing, but the new behavior seems  
to be to strip trailing values quietly:
   (define a (values 2 3 4))
   (call-with-values (lambda () a) (lambda x x))
in Guile 1.9.14.68-a7d8a computes to
   $1 = (2)

By contrast, in guile-1.8.8, it computes to
   (2 3 4)

Re: GIT version: values

[Andy Wingo]

Hi Hans,

Thanks for porting to the 1.9 development series!

On Wed 19 Jan 2011 15:44, Hans Åberg <hans.aberg-1@telia.com> writes:

> It seems it is not only 'values' writing, but the new behavior seems to
> be to strip trailing values quietly:
>   (define a (values 2 3 4))
>   (call-with-values (lambda () a) (lambda x x))
> in Guile 1.9.14.68-a7d8a computes to
>   $1 = (2)
>
> By contrast, in guile-1.8.8, it computes to
>   (2 3 4)

Indeed.  This and a (hopefully small) number of other differences are
noted in the NEWS.  In this case:

    ** Returning multiple values to compiled code will silently truncate the
       values to the expected number

    For example, the interpreter would raise an error evaluating the form,
    `(+ (values 1 2) (values 3 4))', because it would see the operands as
    being two compound "values" objects, to which `+' does not apply.

    The compiler, on the other hand, receives multiple values on the stack,
    not as a compound object. Given that it must check the number of values
    anyway, if too many values are provided for a continuation, it chooses
    to truncate those values, effectively evaluating `(+ 1 3)' instead.

    The idea is that the semantics that the compiler implements is more
    intuitive, and the use of the interpreter will fade out with time.
    This behavior is allowed both by the R5RS and the R6RS.

    ** Multiple values in compiled code are not represented by compound
       objects

    This change may manifest itself in the following situation:

      (let ((val (foo))) (do-something) val)

    In the interpreter, if `foo' returns multiple values, multiple values
    are produced from the `let' expression. In the compiler, those values
    are truncated to the first value, and that first value is returned. In
    the compiler, if `foo' returns no values, an error will be raised, while
    the interpreter would proceed.

    Both of these behaviors are allowed by R5RS and R6RS. The compiler's
    behavior is more correct, however. If you wish to preserve a potentially
    multiply-valued return, you will need to set up a multiple-value
    continuation, using `call-with-values'.

There is no tuple with multiple-valued returns: they are returned on the
stack.

Regards,

Andy
-- 
http://wingolog.org/

Re: GIT version: values

[Hans Aberg]

On 26 Jan 2011, at 21:51, Andy Wingo wrote:

>> It seems it is not only 'values' writing, but the new behavior  
>> seems to
>> be to strip trailing values quietly:
>>  (define a (values 2 3 4))
>>  (call-with-values (lambda () a) (lambda x x))
>> in Guile 1.9.14.68-a7d8a computes to
>>  $1 = (2)
>>
>> By contrast, in guile-1.8.8, it computes to
>>  (2 3 4)
>
> Indeed.  This and a (hopefully small) number of other differences are
> noted in the NEWS.
...
> There is no tuple with multiple-valued returns: they are returned on  
> the
> stack.

Right. I was implementing infix notation tuples syntax f(x_1, ...,  
x_k) using Bison on top of Guile, relying on the old behavior of  
'values'. It is possible to extend Scheme values as to infix tuples  
usage:

Think of Scheme (f x_1 ... x_k) as equivalent to f(x_1 ... x_k), and  
add the reduction of tuples singletons (x) = x. Then (f (values  
x_1 ... x_k)) is the same as f((x_1 ... x_k)) = f(x_1 ... x_k), that  
is (f x_1 ... x_k). However, if more than one of the x_i in is a non- 
singleton, it is an iterated tuple which cannot be reduced on its  
topmost level.

In addition, I extended so that if f = (f_1, ..., f_n), then f(x) is  
defined to (f_1(x), ..., f_n(x)). For values, ((values f_1 ... f_n)  
x_1 ... x_k) computes to (values (f_1 x_1 ... x_k) ... (f_n x_1 ...  
x_k)). With this syntax, one can write (atan ((values sin cos) x)).

Also, functions that return no value might just as well return  
(values) instead of an internal unspecified value. They will then work  
as in C/C++.

> Both of these behaviors are allowed by R5RS and R6RS.

This is correct.

> The compiler's
>    behavior is more correct, however. If you wish to preserve a  
> potentially
>    multiply-valued return, you will need to set up a multiple-value
>    continuation, using `call-with-values'.

But this is false. It prevents implementing tuples in Scheme, at least  
using 'values'.

The topic is discussed here:
https://groups.google.com/group/comp.lang.scheme/browse_thread/thread/b72d987aa6626cd2/e2f7cfa55fb51d55?hl=en

It mentions the above:
 > [E]very procedure takes exactly one argument and returns exactly one
 > result.  The argument and the result will always be a sequence. [...]
 > An expression in tail-recursive position returns a one-element
 > sequence.  Continuations accept sequences containing an arbitrary
 > number of elements as results.

Re: GIT version: values

[Andy Wingo]

Hi Hans,

On Thu 27 Jan 2011 00:34, Hans Aberg <haberg-1@telia.com> writes:

>>    If you wish to preserve a potentially
>>    multiply-valued return, you will need to set up a multiple-value
>>    continuation, using `call-with-values'.
>
> But this is false.

According to the standard, passing an unintended number of values to a
continuation is undefined.  To portably preserve a potentially
multiply-valued return, you need call-with-values.

You can still implement other paradigms on top of this.  If you want to
express some semantics that is not specified in the report, write a
macro that wraps your expressions in call-with-values.  This is
effectively what we will do for Lua, for example.

Regards,

Andy
-- 
http://wingolog.org/

Re: GIT version: values

[Hans Aberg]

On 27 Jan 2011, at 10:00, Andy Wingo wrote:

>>>   If you wish to preserve a potentially
>>>   multiply-valued return, you will need to set up a multiple-value
>>>   continuation, using `call-with-values'.
>>
>> But this is false.
>
> According to the standard, passing an unintended number of values to a
> continuation is undefined.

Right. Because of this, no extension is reliable - can be changed in  
the future.

> To portably preserve a potentially
> multiply-valued return, you need call-with-values.
>
> You can still implement other paradigms on top of this.  If you want  
> to
> express some semantics that is not specified in the report, write a
> macro that wraps your expressions in call-with-values.  This is
> effectively what we will do for Lua, for example.

Yes, this is what I do, first by a macro, and now, via a new tuple  
type (right now a smob), a function call.

But tuples might be integrated into Scheme, so that the underlying  
call-with-values become transparent.

For example, if (lambda x a) would have made the multiple values that  
x picks up as 'values', then (lambda x x) becomes the identity. Now  
this syntax is occupied, but it illustrates the idea.

GIT version: values

[Hans Aberg]

It seems it is not only 'values' writing, but the new behavior seems  
to be to strip trailing values quietly:
  (define a (values 2 3 4))
  (call-with-values (lambda () a) (lambda x x))
in Guile 1.9.14.68-a7d8a computes to
  $1 = (2)

By contrast, in guile-1.8.8, it computes to
  (2 3 4)

Re: GIT version: values

[Ludovic Courtès]

Hi,

Hans Aberg <haberg-1@telia.com> writes:

> It seems it is not only 'values' writing, but the new behavior seems
> to be to strip trailing values quietly:
>  (define a (values 2 3 4))
>  (call-with-values (lambda () a) (lambda x x))
> in Guile 1.9.14.68-a7d8a computes to
>  $1 = (2)
>
> By contrast, in guile-1.8.8, it computes to
>  (2 3 4)

This is the same problem as in your other message.

Ludo’.

Re: GIT version: values

[Hans Aberg]

On 20 Jan 2011, at 16:17, Ludovic Courtès wrote:

>> It seems it is not only 'values' writing, but the new behavior seems
>> to be to strip trailing values quietly:
>> (define a (values 2 3 4))
>> (call-with-values (lambda () a) (lambda x x))
>> in Guile 1.9.14.68-a7d8a computes to
>> $1 = (2)
>>
>> By contrast, in guile-1.8.8, it computes to
>> (2 3 4)
>
> This is the same problem as in your other message.

Yes, I thought it was first a printing problem, struggling with code  
that mysteriously was broken, before realizing that you merely dump  
the other values. It is OK with R5RS, which says that the behavior is  
undefined.

GIT version: segmentation fault

[Hans Aberg]

The code below causes Guile 1.9.14.68-a7d8a to crash (segmentation  
fault after awhile), on Mac OS X 10.5.8 PPC G4.


(defmacro call (f g)
     `(apply ,g (,f)))

(call (lambda () (values 4 5))
   (lambda (a b) b))

Re: GIT version: segmentation fault

[Andy Wingo]

On Wed 19 Jan 2011 20:40, Hans Aberg <haberg-1@telia.com> writes:

> The code below causes Guile 1.9.14.68-a7d8a to crash (segmentation fault
> after awhile), on Mac OS X 10.5.8 PPC G4.
>
>
> (defmacro call (f g)
>     `(apply ,g (,f)))
>
> (call (lambda () (values 4 5))
>   (lambda (a b) b))

Good catch!  It was an error in the error handling.  Fixed in git.  The
message is now:

<unnamed port>:2:1: In procedure apply:
<unnamed port>:2:1: Apply to non-list: 4

Cheers,

Andy
-- 
http://wingolog.org/

Re: GIT version: segmentation fault

[Hans Aberg]

On 26 Jan 2011, at 21:46, Andy Wingo wrote:

>> The code below causes Guile 1.9.14.68-a7d8a to crash (segmentation  
>> fault
>> after awhile), on Mac OS X 10.5.8 PPC G4.
>>
>>
>> (defmacro call (f g)
>>    `(apply ,g (,f)))
>>
>> (call (lambda () (values 4 5))
>>  (lambda (a b) b))
>
> Good catch!  It was an error in the error handling.  Fixed in git.   
> The
> message is now:
>
> <unnamed port>:2:1: In procedure apply:
> <unnamed port>:2:1: Apply to non-list: 4

Good you fixed it. I was actually trying some code from the link  
mentioned before, thinking "this cannot work", and lo and behold, a  
crash!
https://groups.google.com/group/comp.lang.scheme/browse_thread/thread/b72d987aa6626cd2/e2f7cfa55fb51d55?hl=en

GIT version: missing linking flag

[Hans Aberg]

In 'guile-config link', the flag '-lgc' is missing; it is needed when  
linking smobs. The function SCM_NEWSMOB calls  
GC_register_finalizer_no_order() in header gc.h

Re: GIT version: missing linking flag

[Ludovic Courtès]

Hi!

Hans Aberg <haberg-1@telia.com> writes:

> In 'guile-config link', the flag '-lgc' is missing; it is needed when
> linking smobs. The function SCM_NEWSMOB calls
> GC_register_finalizer_no_order() in header gc.h

It shouldn’t be needed when libguile is a shared library, at least not
on ELF platforms where the shared library contains ‘NEEDED’ headers.

It is needed when libguile is static, but in that case you should use
‘pkg-config guile-2.0 --libs --static’ (‘guile-config’ is deprecated.)

Thanks,
Ludo’.

Re: GIT version: missing linking flag

[Hans Aberg]

On 20 Jan 2011, at 16:20, Ludovic Courtès wrote:

>> In 'guile-config link', the flag '-lgc' is missing; it is needed when
>> linking smobs. The function SCM_NEWSMOB calls
>> GC_register_finalizer_no_order() in header gc.h
>
> It shouldn’t be needed when libguile is a shared library, at least not
> on ELF platforms where the shared library contains ‘NEEDED’ headers.
>
> It is needed when libguile is static, but in that case you should use
> ‘pkg-config guile-2.0 --libs --static’ (‘guile-config’ is deprecated.)


The file gc.h says that it is only for Java implementations. But as  
noted above, it is called by SCM_NEWSMOB, so until it is taken away, - 
lgc must be used, otherwise the linker will require it. My platform is  
otherwise Mac OS X; objective code format is Mach-O.

Re: GIT version: missing linking flag

[Ludovic Courtès]

Hello,

Hans Aberg <haberg-1@telia.com> writes:

> On 20 Jan 2011, at 16:20, Ludovic Courtès wrote:
>
>>> In 'guile-config link', the flag '-lgc' is missing; it is needed when
>>> linking smobs. The function SCM_NEWSMOB calls
>>> GC_register_finalizer_no_order() in header gc.h
>>
>> It shouldn’t be needed when libguile is a shared library, at least not
>> on ELF platforms where the shared library contains ‘NEEDED’ headers.
>>
>> It is needed when libguile is static, but in that case you should use
>> ‘pkg-config guile-2.0 --libs --static’ (‘guile-config’ is deprecated.)
>
>
> The file gc.h says that it is only for Java implementations. But as
> noted above, it is called by SCM_NEWSMOB, so until it is taken away, - 
> lgc must be used, otherwise the linker will require it. My platform is
> otherwise Mac OS X; objective code format is Mach-O.

Can you post the exact link command line and error message?

Thanks,
Ludo’.

Re: GIT version: missing linking flag

[Hans Aberg]

On 20 Jan 2011, at 22:01, Ludovic Courtès wrote:

> Can you post the exact link command line and error message?


$ make
gcc parser.o lexer.o driver.o guile++.o guile.o exception.o tuple.o  
`guile-config link` -lstdc++ -o guile++
Undefined symbols:
   "_GC_register_finalizer_no_order", referenced from:
       _make_c_exception in exception.o
       _make_exception in exception.o
       _make_tuple in tuple.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [all] Error 1

Re: GIT version: missing linking flag

[Ludovic Courtès]

Hi,

Hans Aberg <haberg-1@telia.com> writes:

> On 20 Jan 2011, at 22:01, Ludovic Courtès wrote:
>
>> Can you post the exact link command line and error message?
>
>
> $ make
> gcc parser.o lexer.o driver.o guile++.o guile.o exception.o tuple.o
> guile-config link` -lstdc++ -o guile++

This line was mangled by your mailer, I think (missing backquote,
newline inserted).

Furthermore, if you’re linking C++ code, then you should link with g++,
not gcc, and omit -lstdc++.

> Undefined symbols:
>   "_GC_register_finalizer_no_order", referenced from:
>       _make_c_exception in exception.o
>       _make_exception in exception.o
>       _make_tuple in tuple.o
> ld: symbol(s) not found

Oooh, I finally got your point about SCM_NEWSMOB.  It introduces a
direct dependency from your app on libgc, which can require -lgc,
depending on the linker.

I’ll look into it.  I think the GC_REGISTER_FINALIZER_NO_ORDER call
should be buried in a function akin to scm_i_new_smob_with_mark_proc.

Thanks,
Ludo’.

Re: GIT version: missing linking flag

[Hans Aberg]

On 21 Jan 2011, at 17:02, Ludovic Courtès wrote:

>>> Can you post the exact link command line and error message?
>>
>>
>> $ make
>> gcc parser.o lexer.o driver.o guile++.o guile.o exception.o tuple.o
>> guile-config link` -lstdc++ -o guile++
>
> This line was mangled by your mailer, I think (missing backquote,
> newline inserted).

By your mailer, I would think: when I send it to myself, it comes out  
right.

> Furthermore, if you’re linking C++ code, then you should link with g+ 
> +,
> not gcc, and omit -lstdc++.

I do not think it matters: the linker typically supplied by the  
platform, is a C linker on UNIX, and gcc mangles the names of C++ into  
it C.

By contrast, g++ compiles also C files as C++.

>> Undefined symbols:
>>  "_GC_register_finalizer_no_order", referenced from:
>>      _make_c_exception in exception.o
>>      _make_exception in exception.o
>>      _make_tuple in tuple.o
>> ld: symbol(s) not found
>
> Oooh, I finally got your point about SCM_NEWSMOB.  It introduces a
> direct dependency from your app on libgc, which can require -lgc,
> depending on the linker.

Right.

> I’ll look into it.  I think the GC_REGISTER_FINALIZER_NO_ORDER call
> should be buried in a function akin to scm_i_new_smob_with_mark_proc.

If it is needed at all, by the comment in gc/gc.h something that it is  
for Java code.

Re: GIT version: missing linking flag

[Andy Wingo]

On Fri 21 Jan 2011 18:59, Hans Aberg <haberg-1@telia.com> writes:

>>> $ make
>>> gcc parser.o lexer.o driver.o guile++.o guile.o exception.o tuple.o
>>> guile-config link` -lstdc++ -o guile++
>>
>> This line was mangled by your mailer, I think (missing backquote,
>> newline inserted).
>
> By your mailer, I would think: when I send it to myself, it comes out
> right.

I also see the mangled text.

Andy
-- 
http://wingolog.org/

Re: GIT version: missing linking flag

[Hans Aberg]

On 26 Jan 2011, at 21:52, Andy Wingo wrote:

>>>> $ make
>>>> gcc parser.o lexer.o driver.o guile++.o guile.o exception.o tuple.o
>>>> guile-config link` -lstdc++ -o guile++
>>>
>>> This line was mangled by your mailer, I think (missing backquote,
>>> newline inserted).
>>
>> By your mailer, I would think: when I send it to myself, it comes out
>> right.
>
> I also see the mangled text.

Perhaps you use the same crappy mail reader, because it came out in  
the archive:
   http://lists.gnu.org/archive/html/bug-guile/2011-01/msg00048.html

It comes out right in the copy that was send back to me from the list,  
as well as the one I sent directly to myself.

Perhaps the lines must be broken due to the mail protocol; the reader  
should then pick them together again.

Re: GIT version: missing linking flag

[Ludovic Courtès]

Hi,

ludo@gnu.org (Ludovic Courtès) writes:

> Hans Aberg <haberg-1@telia.com> writes:

[...]

>> Undefined symbols:
>>   "_GC_register_finalizer_no_order", referenced from:
>>       _make_c_exception in exception.o
>>       _make_exception in exception.o
>>       _make_tuple in tuple.o
>> ld: symbol(s) not found
>
> Oooh, I finally got your point about SCM_NEWSMOB.  It introduces a
> direct dependency from your app on libgc, which can require -lgc,
> depending on the linker.

Should be fixed now.

I ended up modifying guile-2.0.pc since other public macros/inlines use
libgc functions.

Thanks,
Ludo’.

Re: GIT version: missing linking flag

[Hans Aberg]

On 29 Jan 2011, at 22:47, Ludovic Courtès wrote:

>>> Undefined symbols:
>>>  "_GC_register_finalizer_no_order", referenced from:
>>>      _make_c_exception in exception.o
>>>      _make_exception in exception.o
>>>      _make_tuple in tuple.o
>>> ld: symbol(s) not found
>>
>> Oooh, I finally got your point about SCM_NEWSMOB.  It introduces a
>> direct dependency from your app on libgc, which can require -lgc,
>> depending on the linker.
>
> Should be fixed now.
>
> I ended up modifying guile-2.0.pc since other public macros/inlines  
> use
> libgc functions.

Fine. So I might take down a new GIT.

Re: GIT version: missing linking flag

[Andy Wingo]

On Thu 20 Jan 2011 18:03, Hans Aberg <haberg-1@telia.com> writes:

> The file gc.h says that it is only for Java implementations.

Assuming you refer to gc_register_finalizer_no_order, that is not the
case; it implements a finalizer with semantics that were needed when
Java-style finalizers were added to libgc.  It happens to apply to Guile
as well.  I believe there are threads on the BDW-GC mailing list to this
effect.

Andy
-- 
http://wingolog.org/

Re: GIT version: missing linking flag

[Hans Aberg]

On 26 Jan 2011, at 21:55, Andy Wingo wrote:

>> The file gc.h says that it is only for Java implementations.
>
> Assuming you refer to gc_register_finalizer_no_order, that is not the
> case; it implements a finalizer with semantics that were needed when
> Java-style finalizers were added to libgc.  It happens to apply to  
> Guile
> as well.  I believe there are threads on the BDW-GC mailing list to  
> this
> effect.

OK. So then the -lgc flag should probably be there.

Re: GIT version: values writing

[Ludovic Courtès]

Hi Hans,

Hans Aberg <haberg-1@telia.com> writes:

> 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.

> 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.)

Thanks,
Ludo’.

Re: GIT version: values writing

[Hans Aberg]

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.

>> 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

Re: GIT version: values writing

[Ludovic Courtès]

Hi,

Hans Aberg <haberg-1@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’.

Re: GIT version: values writing

[Hans Aberg]

On 20 Jan 2011, at 22:18, 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 view of that it may break code that relies on the old behavior, I  
think it would be better to throw an exception in the case of multiple  
values.

> 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.


It also says:

> With this approach,
>
> > [E]very procedure takes exactly one argument and returns exactly one
> > result.  The argument and the result will always be a sequence.  
> [...]
> > An expression in tail-recursive position returns a one-element
> > sequence.  Continuations accept sequences containing an arbitrary
> > number of elements as results.

This last correspond in infix syntax to combining objects f(x), where  
(x) may be a tuple (x_1, ..., x_k). When f return multiple values, it  
just returns a tuple, so if sent to another function accepting that  
number f arguments, all would work out.

I am implementing this in a syntax on top of Guile, thinking of using  
the old #<values ...> for my tuples.

But as it is not in R5RS, it does not matter. I'm making my own smob.

>> 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.

Yes, I am hitting some of those problems rather quickly.

Values extension

[Hans Aberg]

On 20 Jan 2011, at 22:18, Ludovic Courtès wrote:

>> 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.

It is possible to extend Scheme values as to infix tuples usage:

Think of Scheme (f x_1 ... x_k) as equivalent to f(x_1 ... x_k), and  
add the reduction of tuples singletons (x) = x. Then (f (values  
x_1 ... x_k)) is the same as f((x_1 ... x_k)) = f(x_1 ... x_k), that  
is (f x_1 ... x_k). However, if more than one of the x_i in is a non- 
singleton, it is an iterated tuple which cannot be reduced on its  
topmost level.

In addition, I extended so that if f = (f_1, ..., f_n), then f(x) is  
defined to (f_1(x), ..., f_n(x)). For values, ((values f_1 ... f_n)  
x_1 ... x_k) computes to (values (f_1 x_1 ... x_k) ... (f_n x_1 ...  
x_k)). With this syntax, one can write (atan ((values sin cos) x)).

Also, functions that return no value might just as well return  
(values) instead of an internal unspecified value. It will then be as  
in C/C++.

This syntax is not at all complicated to use.

Re: GIT version: values writing

[Andy Wingo]

On Thu 20 Jan 2011 17:51, Hans Aberg <haberg-1@telia.com> writes:

> However, quietly loosing values is inviting bugs.

True.  Common Lisp does it though, FWIW.  I find it convenient.

Regards,

Andy
-- 
http://wingolog.org/

Re: GIT version: values writing

[Hans Aberg]

On 26 Jan 2011, at 21:57, Andy Wingo wrote:

>> However, quietly loosing values is inviting bugs.
>
> True.  Common Lisp does it though, FWIW.  I find it convenient.

 From what I can see, one can implement a very nice infix notation  
syntax on top of Guile, which function calls f(x_1, ..., x_k). Then a  
reification of (values x_1 ... x_k) correspond to tuples (x_1, ...,  
x_k).