[Top][All Lists]

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

Re: [shift and reset, plus] "while"

From: Andy Wingo
Subject: Re: [shift and reset, plus] "while"
Date: Wed, 13 Apr 2011 17:41:37 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

On Wed 13 Apr 2011 16:56, Wolfgang J Moeller <address@hidden> writes:

> On Wed, 13 Apr 2011, Andy Wingo wrote:
>> > I'd like to "improve" (while) as currently provided by ice-9/boot.scm
>> >
>> > (a) to always have a well-defined result
>> This is a good idea; it allows `while' to be an expression, not just a
>> statement.
>> > (b) to allow for (break arg ...)
>> Also a good idea.
>> Tricky, though; your comments indicate that you would want (break) to
>> return #t, instead of zero values.
> Does anyone like to _test_ for zero values? Not me.
> As regards the REPL, you still can (break (if #f #f)).
> Alternative: return zero values on "normal termination",
> instead of #<unspecified>, so the REPL keeps quiet then,
> as it did before. Not as handy, but at least well-defined.
> I don't remember if GUILE V1.6 had the return values of #f and #t,
> or if they were my own invention ... IIRC it did have (break arg)
> with a single argument. Anyway, #t is compatible with V2.0.0 .

>From Guile 1.6:

    (defmacro while (cond . body)
      `(letrec ((continue (lambda () (or (not ,cond) (begin (begin ,@ body) 
                (break (lambda val (apply throw 'break val))))
         (catch 'break
            (lambda () (continue))
            (lambda v (cadr v)))))

It did indeed happen to return #t on a normal termination, and have
(break ARG).  It has lots of other bugs though.  I would prefer (break)
to return zero values, and (while #f 1) as well, but that is
incompatible with 2.0.  Bummer.

> Not exactly tricky - see my code's prompt handler.

I didn't mean in terms of code; I meant in terms of documentation,
interface, expectations, etc...

>> > (d) to correct a buglet that currently transforms the non-operator 
>> > `continue'
>> >     into a function of arbitrarily many (as opposed to zero)
>> >     arguments.

I hadn't seen this one because Mark Weaver fixed it a few weeks ago, in



reply via email to

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