[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] "unspecified values"
- To: Andy Wingo <wingo@x>
- Subject: Re: [Scheme-reports] "unspecified values"
- From: Alex Shinn <alexshinn@x>
- Date: Fri, 20 May 2011 21:59:51 -0700
- Cc: scheme-reports@x
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org> <4DD540F3.email@example.com> <firstname.lastname@example.org>
On Thu, May 19, 2011 at 10:10 AM, Andy Wingo <wingo@x> wrote:
> I do not agree with the note that permitting any number of values to be
> returned from `set!' et al is incompatible. It is not incompatible with
> implementations, as it widens the scope of what they may do. It is not
> incompatible with existing programs, as I do not expect existing
> implementations to switch -- most will do what they have been doing.
Yes, it is incompatible with existing programs. One common example is:
(let* ((start (current-time))
(report-time 'expr start (current-time))
This will work fine for arbitrary expressions, including
*set! and I/O operations, so long as they return a single
value as they do in R5RS. I've written quite a lot of
code like this myself, and seen it in many other
Another idiom is:
(let* ((foo (bar))
(_ (print "foo: " foo))
(baz (qux foo))
I actually do this quite often when debugging, because
it's easy to remove the print later. Permanent uses are
more likely to result from macro expansions.
Now, you may dislike these idioms, and argue in
particular that the first doesn't work if expr returns
multiple values, but it works fine for users who were
not previously using MV in that context, or perhaps
in any of their code. And using MV at all is still a
contentious issue for some people. There's a
difference between providing a feature, forcing
people to use that feature in new code, and forcing
them to rewrite their old code to support the feature.
We debated this and voted strongly in favor of not
breaking existing code.
Scheme-reports mailing list