[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] "unspecified values"
- To: Alex Shinn <alexshinn@x>
- Subject: Re: [Scheme-reports] "unspecified values"
- From: Alaric Snell-Pym <alaric@x>
- Date: Mon, 23 May 2011 12:19:36 +0100
- Cc: scheme-reports@x
- In-reply-to: <BANLkTin5W6w+RLHjvM=o8Rz2+8u4YJWWOw@mail.gmail.com>
- References: <email@example.com> <4DD540F3.firstname.lastname@example.org> <email@example.com> <BANLkTin5W6w+RLHjvM=o8Rz2+8u4YJWWOw@mail.gmail.com>
On 05/21/11 05:59, Alex Shinn wrote:
> Yes, it is incompatible with existing programs. One common example is:
> (define-syntax time
> ((time expr)
> (let* ((start (current-time))
> (res expr))
> (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
> people's code.
Ah, but even under R5RS, the expr may not return exactly one expression.
Arbitrary library code is welcome to return (values) or even multiple
useful values. In the former case, the above would have an undefined
consequence, and in the latter case, it'd trim off all but one, as I
> 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.
As a manual debugging idiom it'd be a pain to write (begin (print ...)
#f), but as a macro expansion, that'd be worth it for the generality.
> 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.
Well, the former case is already broken, as arbitrary code may return
And the latter case is a useful, if ugly, hack. In similar situations,
I've thrown together a debugging function that can be put anywhere in an
expression, which just prints and then returns its argument. And yes,
I've written this to only handle a single value, but it's my debugging
hack and I'd notice if I used it somewhere I shouldn't ;-)
> We debated this and voted strongly in favor of not
> breaking existing code.
Voted strongly, perhaps - but most of the rationales were against it...
Scheme-reports mailing list