Re: [Scheme-reports] multiple values module Andy Wingo (25 May 2011 08:20 UTC)
Re: [Scheme-reports] multiple values module Eli Barzilay (25 May 2011 09:04 UTC)
Re: [Scheme-reports] multiple values module Andy Wingo (25 May 2011 10:09 UTC)
Re: [Scheme-reports] multiple values module Eli Barzilay (25 May 2011 10:34 UTC)
Re: [Scheme-reports] multiple values module Eli Barzilay (25 May 2011 12:02 UTC)
Re: [Scheme-reports] multiple values module Alex Shinn (25 May 2011 14:51 UTC)
Re: [Scheme-reports] multiple values module Eli Barzilay (25 May 2011 15:08 UTC)
Re: [Scheme-reports] multiple values module Aaron W. Hsu (25 May 2011 19:58 UTC)
Re: [Scheme-reports] multiple values module Eli Barzilay (26 May 2011 02:48 UTC)
Re: [Scheme-reports] multiple values module Eli Barzilay (26 May 2011 02:55 UTC)
Re: [Scheme-reports] multiple values module Aaron W. Hsu (26 May 2011 21:34 UTC)

Re: [Scheme-reports] multiple values module Aaron W. Hsu 25 May 2011 19:56 UTC

On Wed, 25 May 2011 11:07:25 -0400, Eli Barzilay <eli@barzilay.org> wrote:

> 15 minutes ago, Alex Shinn wrote:
>>
>> It was known behavior, left in place mostly because I didn't
>> actually care  Any Scheme that behaves like Chibi in this case can
>> be fixed with: [...]  The actual fix in Chibi was just one line,
>> [...]

> The question is still open, AFAICT: is the pre-fix problem something
> that is fine to have in an r5/7rs?  According to John, your bug fix
> was not needed.

 From my reading of the R5RS, I concur with John that the original behavior
of Chibi was not breaking compliance with the standard. That is, R5RS and
R6RS both allow implementations to do *whatever* they want if a
continuation expecting a single value receives more than one value. I also
agree that the approach taken by Chibi to use a tagged list to reify the
values into a single value is broken, but not because the standard says
so. I would like the standard to make it clear that this behavior is a
bug, or is broken, according to the standard.

There are currently three tickets related to cleaning up multiple values.
One relates to using the R6RS' wording for non-tail contexts for
continuations. The second, if approved, would explicitly disallow
reification of multiple values to anything other than a disjoint "multiple
values" record or container of some sort. The other is a ticket for trying
to approach this problem from another angle.

See tickets #174, #194, and #193 for more.

If #194 ticket is approved (given the contention on this issue, I have my
doubts), then Chibi's reification of the values into a type that can be
confused with others, thus allowing something like (list? (values 1 2 3))
to return #t, would be disallowed, but internal reification into something
that doesn't expose itself or explicit expose reification into a disjoint
type would be allowed. This would basically allow all the major
implementation strategies currently in use right now except for Chibi's,
which reifies them to lists.

	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