[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)
|
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