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