[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIT-Scheme-devel] R7RS and values.

From: Matt Birkholz
Subject: Re: [MIT-Scheme-devel] R7RS and values.
Date: Thu, 3 Nov 2016 18:00:17 -0700

> From: Taylor R Campbell <address@hidden>
> Date: Thu, 3 Nov 2016 20:26:22 +0000
> [...]
>    I was pleased to find only a couple spots needing patching to "pass
>    along multiple values".  The team did good.  The lusers may still get
>    sore, but our canon offered a good example.
> How do you know you got them all?

I don't.  I was afraid I'd be tripping over many, surprised at so few
(so far as getting through the build).

> That excerpt is about (begin (values 1 2 3) ...).  [repeat of 1st excerpt]
> [second excerpt]
> That excerpt is about (list (values 1 2 3)), which I strongly advise
> that we report noisily.

Is there a way for VALUES to distinguish them?

> [...]
> your change would cause the semantics of the code to silently change
> from passing on all values to passing on only the first value.

Yes, the "extension" I mentioned earlier:
> I might be breaking things (again!).  While I've removed our
> restriction on VALUES (that it and only it return to CALL-WITH-
> VALUES), I have also removed an "extension" that allowed e.g. cleanup-
> noop-nodes to pass along multiple values as if they were one.  It was
> not a documented extension, yet losing it will break unwary code.
> Perhaps just a mention in the release notes?

I thought it was a bug, not a feature.  Is fixing the bug now a bug,
not a feature?

> Right now in your branch, it seems that (list (values 1 2 3)) gives
> the list (1) rather than an error.

Yes.  Right now the VALUES primitive in that branch cannot distinguish
between (list (values...)) and (begin (values...)) as far as I know.
If it does not require major changes to the compiler, I'd be happy to
code VALUES for the distinction.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]