Email list hosting service & mailing list manager

Re: New draft (#2) and last call for comments on SRFI 229: Tagged Procedures Per Bothner (15 Nov 2021 15:03 UTC)

Re: New draft (#2) and last call for comments on SRFI 229: Tagged Procedures Per Bothner 15 Nov 2021 15:02 UTC

[About Kawa returning zero values for set! and other syntax/procedures.]

Am Sa., 13. Nov. 2021 um 19:47 Uhr schrieb John Cowan <xxxxxx@ccil.org <mailto:xxxxxx@ccil.org>>:
>     Thanks!  I partially retract my second claim, though I note that Kawa doesn't claim R6RS compliance, and this provision makes Kawa not R[57]RS-compliant either.  Just saying.

Kawa does have --r6rs and --r7rs flags that aim to "Provide better compatibility with the specified
Scheme standards" and "disable Kawa extensions that conflict with [for example] R6RS".
As far as I can recall, these flags don't currently change void-returning functions
to return a single value, but it would be reasonable fix.  If anybody cares enough.

On 11/13/21 11:28, Marc Nieper-Wißkirchen wrote:> If continuations that accept one value in Kawa silently accept multiple values, R7RS-compliance will actually be maintained.
>
> (I don't know what is actually be true for Kawa, but this is how Chibi works, for example.)

This would be the Common Lisp approach, I believe.

> In any case, breaking R7RS-compliance here would actually be a very good idea IMO. A program that would break under this incompatibility would most likely include a logical error anyway.

Yep.  Of course this error-detecting benefit would be lost if using the Chibi solution
(continuations that accept one value silently accept multiple values).

> And in the unlikely case that it wouldn't, it could be easily fixed.

This is similar to how I feel about SRFI 140 (immutable strings): Sometimes
a minor easily-fixable incompatibility is worth it.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/