Re: [Scheme-reports] multiple values module Eli Barzilay (20 May 2011 07:08 UTC)
Re: [Scheme-reports] multiple values module John Cowan (20 May 2011 16:02 UTC)
Re: [Scheme-reports] multiple values module Andy Wingo (20 May 2011 16:04 UTC)
Re: [Scheme-reports] multiple values module John Cowan (20 May 2011 19:48 UTC)
Re: [Scheme-reports] multiple values module Eli Barzilay (20 May 2011 19:50 UTC)
Re: [Scheme-reports] multiple values module Emmanuel Medernach (21 May 2011 06:43 UTC)
Re: [Scheme-reports] multiple values module Andy Wingo (21 May 2011 08:49 UTC)
Re: [Scheme-reports] multiple values module John Cowan (21 May 2011 17:50 UTC)
Re: [Scheme-reports] multiple values module Andy Wingo (22 May 2011 14:05 UTC)
Re: [Scheme-reports] multiple values module Emmanuel Medernach (24 May 2011 07:06 UTC)
Re: [Scheme-reports] multiple values module John Cowan (24 May 2011 16:08 UTC)
Re: [Scheme-reports] multiple values module Emmanuel Medernach (24 May 2011 17:06 UTC)
Re: [Scheme-reports] multiple values module Aaron W. Hsu (24 May 2011 18:54 UTC)
Re: [Scheme-reports] multiple values module Per Bothner (24 May 2011 23:26 UTC)
Re: [Scheme-reports] multiple values module John Cowan (24 May 2011 21:20 UTC)
Re: [Scheme-reports] multiple values module Eli Barzilay (24 May 2011 21:26 UTC)
Re: [Scheme-reports] multiple values module John Cowan (24 May 2011 21:37 UTC)
Re: [Scheme-reports] multiple values module Eli Barzilay (24 May 2011 21:41 UTC)
Re: [Scheme-reports] multiple values module Aaron W. Hsu (25 May 2011 03:41 UTC)
Re: [Scheme-reports] multiple values module Eli Barzilay (25 May 2011 06:42 UTC)
Re: [Scheme-reports] multiple values module Andy Wingo (21 May 2011 08:42 UTC)
Re: [Scheme-reports] multiple values module Aaron W. Hsu (20 May 2011 16:27 UTC)
Re: [Scheme-reports] multiple values module Alex Shinn (20 May 2011 16:54 UTC)
Re: [Scheme-reports] multiple values module Andy Wingo (20 May 2011 16:57 UTC)
Re: [Scheme-reports] multiple values module Eli Barzilay (20 May 2011 17:47 UTC)
Re: [Scheme-reports] multiple values module John Cowan (20 May 2011 20:38 UTC)
Re: [Scheme-reports] multiple values module Eli Barzilay (21 May 2011 02:03 UTC)
Re: [Scheme-reports] multiple values module John Cowan (21 May 2011 05:11 UTC)
Re: [Scheme-reports] multiple values module Eli Barzilay (21 May 2011 05:04 UTC)
Re: [Scheme-reports] multiple values module John Cowan (21 May 2011 18:43 UTC)
Re: [Scheme-reports] multiple values module Andre van Tonder (21 May 2011 19:49 UTC)
Re: [Scheme-reports] multiple values module John Cowan (21 May 2011 20:49 UTC)

Re: [Scheme-reports] multiple values module Aaron W. Hsu 20 May 2011 16:26 UTC

On Fri, 20 May 2011 11:58:59 -0400, John Cowan <cowan@mercury.ccil.org>
wrote:

> Ultimately, if you want R6RS, you know where to find it.

This kind of statement is exactly what we don't want. We're talking about
core semantics, which is well within the purview of WG1, and is absolutely
relevant to anyone who is moving from R6RS to the next standard.

>> > Chibi actually implements multiple purely in Scheme by returning a
>> > list with a unique CAR, which prints as "(value)".
>>
>> Ugh.  If the above is broken, then this is a train wreck.
>
> Remember that Chibi is intended to be small in code size and storage
> space, but not necessarily fast.  Here's the total implementation:
>
> (define *values-tag* (list 'values))
>
> (define (values . ls)
>   (if (and (pair? ls) (null? (cdr ls)))
>       (car ls)
>       (cons *values-tag* ls)))
>
> (define (call-with-values producer consumer)
>   (let ((res (producer)))
>     (if (and (pair? res) (eq? *values-tag* (car res)))
>         (apply consumer (cdr res))
>         (consumer res))))
>
> Completely conformant.  If you use multiple values anywhere else, you'll
> get the implementation showing through, of course.  So it goes.
>
>> I'm sure that there are reasons for implementing things this way, but
>> making an argument out of it sounds insane.  (Or a camouflaged attemt
>> to make multiple values so useless that it's as if they're not in...)
>
> On the contrary.  It is an argument that multiple values belong in
> the core, because even the tiniest conformant implementation *can*
> provide them.

I can't help but feel that the above implementation is woefully broken. Is
it conformant? Maybe you could make an argument for that, since the
standards (R5RS and R6RS) don't say anything about what happens when
(list? (values 1 2)) is evaluated. On the other hand, I hardly think that
we should be looking to this as a good example of anything. A tiny
implementation like Chibi could still be compliant without this mess (and
I do think it is a mess). It could still be *easily* compliant without
this mess. It's one thing to take liberties from the intentioned norms for
good reasons, but I fail to see good reasons for doing the above.

At the very least, we ought to be able to expect that (list? (values 1 2))
should not return #t, whatever else it does. The flexibility in the
standards is not, I believe, an implicit approval of such gaping holes in
abstraction.

	Aaron W. Hsu

--
Programming is just another word for the lost art of thinking.

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports