‘when’ and ‘unless’ are unimplementable

[Daphne Preston-Kendal]

The R7RS small specifications of ‘when’ and ‘unless’ say:

> The result of the when expression is unspecified.
> The result of the unless expression is unspecified.

From section 3.5 we also learn that the expressions in when and unless are a tail sequence, so the final expression has to be a tail call.

(Can you see where this is going?)

Section 1.3:

> If the value of an expression is said to be “unspecified,” then the expression must evaluate to some object without signaling an error, but the value depends on the implementation; this report explicitly does not say what value is returned.

By the common interpretation of this sentence, it is not allowed for expressions whose result is unspecified in R7RS small to return zero values or more than one value. (N.B. ‘result of an expression’ and ‘value(s) of an expression’ are used pretty interchangeably throughout R7RS small.)

An implementation which returns values 1 and 2 from this expression is non-conforming:

(when #t
(values 1 2))

but it is also not possible for an implementation to implement when and unless as tail expressions if they replace the result of a successful ‘when’ or ‘unless’ with a single value, since that would mean the final expression would no longer be in tail position.


Daphne

[Alex Shinn]

Thanks for the report Daphne!

I guess what this amounts to is that the derived syntax definitions of when and unless are not portable on implementations which _signal an error_ if the wrong number of values are passed to a call site.

So it works fine for those that follow CL semantics (e.g. Chicken, Guile) taking only the first value, or for those that reify multiple values into a single object (e.g. Chibi, MIT).

Implementations that would signal an error here either need to wrap the definition in a TCO-preserving guard form, or otherwise have some compiler support for the definition of when/unless.

--

Alex

--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg1" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/scheme-reports-wg1/1B485BCB-EDC5-4200-8CDC-98C558E5F4EE%40nonceword.org.

[John Cowan]

I think the Right Thing is to remove `when` and `unless` from the list of tail-recursive expressions.

To view this discussion visit https://groups.google.com/d/msgid/scheme-reports-wg1/CAMMPzYPE2%2BPs6ctpz9fjiaLQk1tjrwSYq5SDkpYN1Txz4M%3DF%2Bg%40mail.gmail.com.

[Aaron Hsu]

I may be out of touch, but don't people strongly expect to be able to use WHEN and UNLESS in tail position with tail-recursion? 

-- 

Aaron W. Hsu | arc...@sacrideo.us | http://www.sacrideo.us

To view this discussion visit https://groups.google.com/d/msgid/scheme-reports-wg1/CAD2gp_QHD6znojnwM_FWhbArHdW%2BtTcKN7B4aorhn32RRW_dnQ%40mail.gmail.com.

[Arthur A. Gleckler]

On Fri, Feb 21, 2025, 5:10 PM Aaron Hsu <arc...@sacrideo.us> wrote:

I may be out of touch, but don't people strongly expect to be able to use WHEN and UNLESS in tail position with tail-recursion?

I've always viewed them as purely imperative constructs with no return value — as the version of if that one uses when there's only the consequent and no return value.

[Alex Shinn]

You can use them for side-effecting behavior, e.g. I believe I've used them in I/O loops.

I don't see that we need to change anything though.

These forms are obviously not "unimplementable" as suggested, since many implementations exist.

It's just that in some implementations (examples?), they may require extra implementation effort.

--

Alex

--

You received this message because you are subscribed to the Google Groups "scheme-reports-wg1" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/scheme-reports-wg1/CALnw4LKqBYL5wbR55sYjGO1yHJ_KK9p_ccZQsy%2BuivhHogzy%3Dg%40mail.gmail.com.

[Daphne Preston-Kendal]

On 21 Feb 2025, at 23:32, Alex Shinn <alex...@gmail.com> wrote:

> I don't see that we need to change anything though.
> These forms are obviously not "unimplementable" as suggested, since many implementations exist.

Just because many implementations exist which are incorrect according to the specification does not mean that the specification is correct.

Your proposed solution – that all implementations have to coerce multiple values down to one value – is a real stretch, given it contradicts the places in the R7RS report which state that the effect of passing wrong numbers of values is an error. Moreover, the problematic specification of ‘when’ is observable in this case:

(call-with-values
(lambda ()
(when (some-condition)
(values 1 2)))
(case-lambda
((a) 'one-value)
((a b) 'two-values)))

The requirement that ‘when’ only ever return one value means this expression is only ever allowed to evaluate to the symbol one-value, regardless of the value of (some-condition). The requirement that the ‘when’ expressions are a tail sequence implies that this expression must be allowed to evaluate to the symbol two-values if (some-condition) is true. This contradiction applies no matter what an implementation does when returning multiple values to a single-value continuation (as per your allusion to CL semantics), and regardless of whether multiple values are represented internally as a single value (like in Chibi).

If you think it’s possible to use ‘guard’ to coerce multiple values into one value here without spoiling the tail context guarantee (and ideally without any other pointless performance overhead), I’d appreciate a demo of how that would work.


For what it’s worth, the historical cause here is the combination of two arbitrary changes from R6RS which appear to have been motivated more by the squaloid fantasies of certain WG1 members than by solid engineering considerations:

1. In R6RS, the return value of ‘when’ and ‘unless’ is specified in the case where the expressions are evaluated. (I.e. if the condition is true for ‘when’, and if it’s false for ‘unless’.) Namely, as you’d expect, you get the values of the last expression. The return value is unspecified only in the case where the expressions are not evaluated. This means the semantics of the trivial and obvious transformations of ‘when’ and ‘unless’ to an ‘if’ with no alternate expression – an implementation strategy which, as far as I know, there is absolutely no reason to deviate from – are the defined semantics of ‘when’ and ‘unless’ themselves.

2. In R6RS, a form whose return value is unspecified can return any number of unspecified values and not only one.

Reverting either one of these changes by erratum would fix the problem. (Heck, it would do just to say, as an exception to the usual rule that ‘unspecified result’ means only one value, that ‘when’ and ‘unless’ can return multiple unspecified values.)

For what it’s worth, in the absence of any erratum notification from WG1, for R7RS large I intend to draft the initial specification of ‘when’ and ‘unless’ reverting the first change back to the R6RS state of affairs. (WG2 might object to this, of course, in which case we’ll have to consider it more deeply.)


Daphne

[Aaron Hsu]

Looking at this a bit more, the thing that actually surprises me is the idea that the results of (when ...) and (unless ...) are unspecified in the cases where the sub-expressions evaluate to a value. The interpretation here seems to be that even if we have something like (when #t 1), that this expression would still evaluate to an unspecified value. That strikes me as wrong.

Do we have any historical documentation on the intent at the time that this verbiage was added? It seems more likely to me that the intent was that the expressions should take the value of the final sub-expression (in tail position), but unspecified if there is no expression or the sub-expressions are not evaluated at all (failing the test condition).

It seems unlikely to me, looking back, that the intent was ever to say that the value of these expressions could never be known if the final sub-expression actually evaluated to a value(s)? If that was the case, then I agree that it appears that the "single-valuedness" implied by the definition of unspecified values could appear to present some challenges.

--
Aaron W. Hsu | arc...@sacrideo.us | http://www.sacrideo.us

> --
> You received this message because you are subscribed to the Google
> Groups "scheme-reports-wg1" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scheme-reports-...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/scheme-reports-wg1/BC181609-0948-4E4C-ADC0-A72545FE5052%40nonceword.org.

[Aaron Hsu]

I tried to find some discussion about the phrasing for WHEN and UNLESS but was unable to find it. I did find that we had a vote and discussion on the unspecified value(s) question, though.

Given that I can't find discussion on WHEN/UNLESS, but I can find discussion and a vote on the unspecified value question, it seems in poor taste to try to "fix" by erratum the unspecified values question that was explicitly argued and voted for in the standard (though I was on the losing side of the eventual vote). However, an argument could potentially be made that the lack of clarification on WHEN/UNLESS is an oversight and maybe an erratum is warranted here?

--
Aaron W. Hsu | arc...@sacrideo.us | http://www.sacrideo.us

> https://groups.google.com/d/msgid/scheme-reports-wg1/7e94e2bc-c5d2-4ce9-95b2-6b85910a6a4f%40app.fastmail.com.

[Alex Shinn]

On Sat, Feb 22, 2025 at 7:49 PM Daphne Preston-Kendal <d...@nonceword.org> wrote:

On 21 Feb 2025, at 23:32, Alex Shinn <alex...@gmail.com> wrote:

> I don't see that we need to change anything though.
> These forms are obviously not "unimplementable" as suggested, since many implementations exist.

Just because many implementations exist which are incorrect according to the specification does not mean that the specification is correct.

Your proposed solution – that all implementations have to coerce multiple values down to one value – is a real stretch, given it contradicts the places in the R7RS report which state that the effect of passing wrong numbers of values is an error.

Firstly, the implementations are not incorrect.  The phrase "is an error" means that the implementation is free to do what it wants (including signal an error if it so chooses).  For this particular case there are two common extensions, and off hand I'm not aware of an R7RS (or R5RS) implementation which signals an error here (though no doubt there is one).  Further, and more importantly, this phrase is key to the entire motivation and philosophy of the small language.  We deliberately leave room for extension to encourage experimentation.  If I came off too strong in my rejection of the 2nd edition idea it was because of this.  A WG without a vested interest in the WG1 charter shouldn't be making changes to WG1.

WG2 for its part is free to specify anything left undefined.  As you've noted it's the places where WG1 arguably over-specified that are problematic.

Secondly, I did not give _one_ proposed solution but 3 plus a general class of solutions.  I admit one of the solutions (the guard wrapper) was handy-wavy and in retrospect impossible because the exception is signaled outside the lexical context of the when form.

The general class of solutions was "having some compiler support" for when/unless.  For example, one can consider the special form

(first-value expr)

which evaluates expr in a tail call but returns only the first value (or undef for zero values).  This can be done trivially in a CPS implementation, for example, by wrapping the continuation with one that extracts the first value.

Note I didn't say this was a good or easy solution.  If nothing else it's a huge wart if when and unless don't have a fully portable implementation.  But it's not internally inconsistent, so it's difficult to argue that an errata is required.  If both John and Arthur think an errata is appropriate, and the remaining WG1 members paying attention could agree as to what the errata should be, I could consider it.

Regarding our options in that case:

Aaron Hsu wrote:

Looking at this a bit more, the thing that actually surprises me is the idea that the results of (when ...) and (unless ...) are unspecified in the cases where the sub-expressions evaluate to a value. The interpretation here seems to be that even if we have something like (when #t 1), that this expression would still evaluate to an unspecified value. That strikes me as wrong.

Actually, I believe the R6RS semantics is the most broken I've seen.  Consider:

(when (some-condition) (+ 2 2))

This could return 4, but it could also return 5, or any arbitrary result.  Attempting to use the result of the R6RS when is basically always a bug.  I don't recall exactly but I believe it was largely because of this that we chose to emphasize the imperative nature of these forms and make the results unspecified.

There seem to be 2 reasonable specifications of when/unless.  The first is the CL semantics, which return #f if the condition fails, i.e. (when test body ...) is shorthand for (and test (begin body ...)).

The second is that when/unless always return an unspecified number of unspecified values, i.e. R7RS but loosening to allow other than 1 value.

Personally, given this mess I'd just as soon remove when/unless from the small language, but that's not a realistic option.  Another option is to state "it's an error to return multiple values as the last form in when/unless," because indeed that never makes sense, but it's an ugly and fragile restriction.  I don't like any of the options.

Now if you'll excuse me, I need to go back to mourning the death of democracy in America.

--

Alex

[Gerald Jay Sussman]

I rarely use UNLESS or WHEN, but when I do I agree with Arthur's view.


> Date: Fri, 21 Feb 2025 17:14:57 -0500
> From: "Arthur A. Gleckler" <a...@speechcode.com>

>
> On Fri, Feb 21, 2025, 5:10 PM Aaron Hsu <arc...@sacrideo.us> wrote:
>
> > I may be out of touch, but don't people strongly expect to be able to use
> > WHEN and UNLESS in tail position with tail-recursion?
> >
>
> I've always viewed them as purely imperative constructs with no return

> value — as the version of if that one uses when there's only the consequent
> and no return value.
>
> >
>

> --
> You received this message because you are subscribed to the Google Groups
> "scheme-reports-wg1" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> scheme-reports-...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/scheme-reports-wg1/CALnw4LKqBYL5wbR55sYjGO1yHJ_KK9p_ccZQsy%2BuivhHogzy%3Dg%40mail.gmail.com.

[Alex Shinn]

Perhaps we can see if we can get consensus on the best approach first before deciding if an errata is appropriate.

There are a few options proposed by various people:

1. Change the specification of when/unless to return the value(s) of the last expression if the test succeeds.

As noted, this "partially undefined" behavior was identified as a mis-design in R6RS and fixed in R7RS, so

I personally wouldn't support this as either an errata or in a future standard.

2. Change the specification of an undefined result to allow any number of unspecified values.

I think this is too large a semantic change on something which was deliberately chosen for R5RS

compatibility to consider as an errata.  There would likely be breakage in real-world R7RS programs.

It's reasonable to consider this change for future standards though.

3. Change the specification of _just_ when/unless to return an unspecified number of unspecified values.

This could also potentially break existing programs but the odds seem much less likely.

(Alternatively change when/unless to CL semantics.)

4. Remove when/unless from the list of TCO forms (and add a dummy return value to the derived syntax defs).

This doesn't break anything outright but can risk blowing the stack in some rare cases

(e.g. https://github.com/ashinn/chibi-scheme/blob/72ec53ca262b827efaa3c53e8f8daed117efde72/lib/chibi/crypto/sha2-native.scm#L9-L12).

However, in practice all existing implementations guarantee TCO anyway.

Thoughts?

--

Alex

To view this discussion visit https://groups.google.com/d/msgid/scheme-reports-wg1/E1tlrx3-00028g-A3%40gjs-x5.

[Daphne Preston-Kendal]

On 22/02/2025 15:09, Alex Shinn wrote:

Firstly, the implementations are not incorrect. The phrase "is an
> error" means that the implementation is free to do what it wants
> (including signal an error if it so chooses).

This was exactly my point. Your original interpretation constrains
implementations to do something very specific in an 'error' case, which
is not in the spirit of the 'it is an error' language.

Furthermore, the contradiction is still made very visible by any use of
call-with-values over case-lambda with a when/unless in tail position of
the producer form.

> Aaron Hsu wrote:
>
> Looking at this a bit more, the thing that actually surprises me is
> the idea that the results of (when ...) and (unless ...) are
> unspecified in the cases where the sub-expressions evaluate to a
> value. The interpretation here seems to be that even if we have
> something like (when #t 1), that this expression would still
> evaluate to an unspecified value. That strikes me as wrong.
>
> Actually, I believe the R6RS semantics is the most broken I've seen.

> [long explanation snipped]

On second thoughts, I agree with you.

If WG1 fails to productively resolve this inconsistency, I will instead
draft the initial version of the relevant part of R7-large so that forms
whose return values are unspecified may return any number of values
rather than only one, and leave the return values from 'when' and
'unless' unspecified in both cases. I.e. I would revert the *other*
broken change made by R7-small compared to R6 that led to this situation.

(As before, though, it would depend on WG2 to agree to this proposed
change.)



Daphne

[P.S. Apologies to Alex for sending two copies of this mail to him.]

[Aaron Hsu]

Given these sentiments, it strikes me as unlikely that there is anything real that we can do to solve this issue. 

It seems that all of these potential fixes run afoul of one issue or another and wouldn't get sufficient buy-in. It seems that there might be a solution that WG2 could try to mitigate this, though, as per recent messages. 

-- 

Aaron W. Hsu | arc...@sacrideo.us | http://www.sacrideo.us

To view this discussion visit https://groups.google.com/d/msgid/scheme-reports-wg1/CAMMPzYPosW7%2BRHM6%3D1EDt1s2iPCyptfye4_5Sn%2BL3kHRNaJzjw%40mail.gmail.com.

[Aaron Hsu]

I suppose that this doesn't seem precise enough to me. I mean that it seems like we can't do #2 that Alex has proposed, because of the vote, and #1 has strong opposition, while #3 and #4 both seem...ad hoc and ugly. Therefore, if WG2 can simply do something akin to #2, that would potentially address it in a "simple" way, but I don't see how WG1 could reasonably make such a change. 

-- 

Aaron W. Hsu | arc...@sacrideo.us | http://www.sacrideo.us

To view this discussion visit https://groups.google.com/d/msgid/scheme-reports-wg1/a8cd5c6c-69a3-4cf2-a347-2ee4b34d4bd0%40app.fastmail.com.

[Emmanuel Medernach]

Hello,

From a practical point of view could we review existing code using 'when' ?

From what I could read from existing Scheme code base, 'when' is mostly
used to:

- reporting an error:

  (when failure? (error ...))

- mutating variable(s)

  (when timed? (saved-time-set! saved (current-time 'time-thread)))

- calling for side effects:

  (when (file-exists? f) (rm f))

  (when (and (eof-object? x)
             (not (string=? prompt "")))
    (newline (console-output-port))
    (flush-output-port (console-output-port)))

Based on such usages, IMO the most reasonable choice is to make 'when'
imperative only, letting its returning value as unspecified. Using the
return value of a 'when' expression must be an error for standard Scheme
code.

Best regards,

Emmanuel Medernach

>>> <mailto:scheme-reports-wg1%2Bunsu...@googlegroups.com>.

>>> > To view this discussion visit
>>> >
>>> https://groups.google.com/d/msgid/scheme-reports-wg1/CALnw4LKqBYL5wbR55sYjGO1yHJ_KK9p_ccZQsy%2BuivhHogzy%3Dg%40mail.gmail.com.
>>>
>>> --
>>> You received this message because you are subscribed to the
>>> Google Groups "scheme-reports-wg1" group.
>>> To unsubscribe from this group and stop receiving emails from
>>> it, send an email to
>>> scheme-reports-...@googlegroups.com

>>> <mailto:scheme-reports-wg1%2Bunsu...@googlegroups.com>.

>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/scheme-reports-wg1/E1tlrx3-00028g-A3%40gjs-x5.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "scheme-reports-wg1" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to scheme-reports-...@googlegroups.com.
>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/scheme-reports-wg1/CAMMPzYPosW7%2BRHM6%3D1EDt1s2iPCyptfye4_5Sn%2BL3kHRNaJzjw%40mail.gmail.com

>>> <https://groups.google.com/d/msgid/scheme-reports-wg1/CAMMPzYPosW7%2BRHM6%3D1EDt1s2iPCyptfye4_5Sn%2BL3kHRNaJzjw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "scheme-reports-wg1" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to scheme-reports-...@googlegroups.com.
>> To view this discussion visit

>> https://groups.google.com/d/msgid/scheme-reports-wg1/a8cd5c6c-69a3-4cf2-a347-2ee4b34d4bd0%40app.fastmail.com
>> <https://groups.google.com/d/msgid/scheme-reports-wg1/a8cd5c6c-69a3-4cf2-a347-2ee4b34d4bd0%40app.fastmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "scheme-reports-wg1" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scheme-reports-...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/scheme-reports-wg1/c2470f02-1f56-4494-a8c7-619e894ef8eb%40app.fastmail.com
> <https://groups.google.com/d/msgid/scheme-reports-wg1/c2470f02-1f56-4494-a8c7-619e894ef8eb%40app.fastmail.com?utm_medium=email&utm_source=footer>.

[Alex Shinn]

On Thu, Mar 20, 2025 at 4:34 PM Daphne Preston-Kendal <d...@nonceword.org> wrote:

On 22/02/2025 15:09, Alex Shinn wrote:

  Firstly, the implementations are not incorrect.  The phrase "is an
 > error" means that the implementation is free to do what it wants
 > (including signal an error if it so chooses).

This was exactly my point. Your original interpretation constrains
implementations to do something very specific in an 'error' case, which
is not in the spirit of the 'it is an error' language.

Sorry, maybe I'm not understanding your point, but I think this is important to clarify.

The problem is that the standard requires `when/unless` to both return a

single value and do so with TCO, which can't be implemented portably.

We've added other non-portable new forms such as `raise`, but that is

unavoidable.  Having `when/unless` as special forms is at _best_ a wart.

If we feel that beyond being unportable this poses an unrealistic burden

on implementations due to complexity, then I believe an errata is appropriate.

That's why it's worth discussing the various implementation strategies.

I've mentioned several strategies, but it's important to keep in mind that

these are implementation details.  Nobody has ever claimed that any of

the strategies are somehow required - indeed, some of them are mutually

incompatible - so there is no single specific constraint as you suggest.

However, as it stands _some_ strategy must be chosen.

Existing implementations have already voted with their feet on two of

the strategies.  I'd like to see evidence of an existing or intended

implementation for which _none_ of the strategies are realistic.

--

Alex

[Alex Shinn]

On Fri, Mar 21, 2025 at 10:55 AM Alex Shinn <alex...@gmail.com> wrote:

[...]

Existing implementations have already voted with their feet on two of

the strategies.  I'd like to see evidence of an existing or intended

implementation for which _none_ of the strategies are realistic.

My efforts to get someone else to do the legwork failed :)

I checked and Racket does throw an exception here, and I've found threads suggesting they have zero interest in changing this or providing a workaround.

I can't rule out some user-space workaround in Racket but can't find one either.

Requiring such a mature implementation to make compiler changes for this seems like an unrealistic burden, so I think an errata is appropriate.

I think just omitting when/unless from the list of guaranteed TCO forms is the easiest and only realistic option.

Any objections?

--

Alex

[Jeff Read]

On Wed, May 7, 2025 at 10:37 PM Alex Shinn <alex...@gmail.com> wrote:

> My efforts to get someone else to do the legwork failed :)
>
> I checked and Racket does throw an exception here, and I've found threads suggesting they have zero interest in changing this or providing a workaround.
> I can't rule out some user-space workaround in Racket but can't find one either.
> Requiring such a mature implementation to make compiler changes for this seems like an unrealistic burden, so I think an errata is appropriate.

Daphne is right. An errata is really the only option; implementing the
spec as written is impossible.

> I think just omitting when/unless from the list of guaranteed TCO forms is the easiest and only realistic option.
>

That would mess with the expected behavior of the obvious
implementations of when and unless:

(define-syntax when
(syntax-rules ()
((when condition body ...)
(if condition (begin body ...)))))

(define-syntax unless
(syntax-rules ()
((unless condition body ...)
(if (not condition) (begin body ...))

which, afaict, _are_ guaranteed TCO provided the last expression in the body is.

--Jeff

[Jeff Read]

Sorry,

(define-syntax unless
(syntax-rules ()
((unless condition body ...)

(if (not condition) (begin body ...)))))

[Alex Shinn]

These implementations are invalid because they can return more than one value, which contradicts the spec.

Please refer to my earlier more detailed list of the possible errata from March 18th.

--

Alex

--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg1" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/scheme-reports-wg1/CAL6nvpVA1fru6Tk3O%3DZ1DM372H-mP_5RjPs8vt_cBAP9uaH5Ug%40mail.gmail.com.

[Jeff Read]

On Wed, May 7, 2025 at 11:30 PM Alex Shinn <alex...@gmail.com> wrote:
>
> These implementations are invalid because they can return more than one value, which contradicts the spec.
> Please refer to my earlier more detailed list of the possible errata from March 18th.
>

True, and hence why I believe the errata should choose option 1, 2, or
3 (my current preference) of your proposed options; what you suggested
today was option 4.

--Jeff

[Emmanuel Medernach]

I agree. I would let 'when' return value as unspecified, as specified in
the R7RS report.  Using the return value of a 'when' expression I think
is an error situation in standard Scheme code as I view 'when' as
imperative only, some kind of one-armed 'if' used only for side effects.
I would like to drop TCO requirement.

Emmanuel


> --
> Alex

>
> --
> You received this message because you are subscribed to the Google
> Groups "scheme-reports-wg1" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to scheme-reports-...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/scheme-reports-wg1/CAMMPzYPywRdsvjdz3xmSmjCwPVHSZ-cTthonh2Q9RW0tf%2BR5wA%40mail.gmail.com
> <https://groups.google.com/d/msgid/scheme-reports-wg1/CAMMPzYPywRdsvjdz3xmSmjCwPVHSZ-cTthonh2Q9RW0tf%2BR5wA%40mail.gmail.com?utm_medium=email&utm_source=footer>.