[Scheme-reports] "unspecified values" Andy Wingo (19 May 2011 15:49 UTC)
Re: [Scheme-reports] "unspecified values" Alaric Snell-Pym (19 May 2011 16:11 UTC)
Re: [Scheme-reports] "unspecified values" Andy Wingo (19 May 2011 17:11 UTC)
Re: [Scheme-reports] "unspecified values" Alex Shinn (21 May 2011 05:04 UTC)
Re: [Scheme-reports] "unspecified values" Andy Wingo (21 May 2011 08:52 UTC)
Re: [Scheme-reports] "unspecified values" Jim Rees (21 May 2011 13:58 UTC)
Re: [Scheme-reports] "unspecified values" Andy Wingo (21 May 2011 15:10 UTC)
Re: [Scheme-reports] "unspecified values" John Cowan (21 May 2011 18:24 UTC)
Re: [Scheme-reports] "unspecified values" Andy Wingo (22 May 2011 13:28 UTC)
Re: [Scheme-reports] "unspecified values" Andre van Tonder (21 May 2011 15:19 UTC)
Re: [Scheme-reports] "unspecified values" Alex Shinn (21 May 2011 18:19 UTC)
Re: [Scheme-reports] "unspecified values" Alaric Snell-Pym (23 May 2011 11:34 UTC)
Re: [Scheme-reports] "unspecified values" John Cowan (23 May 2011 15:57 UTC)
Re: [Scheme-reports] "unspecified values" Alaric Snell-Pym (23 May 2011 11:20 UTC)

Re: [Scheme-reports] "unspecified values" Alaric Snell-Pym 23 May 2011 11:19 UTC

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))
>       res)))
>
> 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
read it?

> 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
arbitrary values.

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...

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports