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

Re: Compatible support for multiple values in SRFI-45



Hi Eli,

Eli Barzilay <eli@xxxxxxxxxxxx> writes:
> An hour and a half ago, Mark H Weaver wrote:
>> Here's another approach to supporting multiple values in SRFI-45, which
>> will most likely be deployed in Guile 2.0.8.  In this approach, 'eager'
>> remains a procedure, but one that accepts any number of arguments.  It
>> is therefore used in the same way as 'values'.
>
> Note that in our implementation the body of `delay', etc, can have
> multiple expressions with an implicit begin.  While this is not in the
> srfi, you're effectively closing off this as a future extension.

My proposal also supports multiple expressions with an implicit begin in
'delay'.  It's true that we're closing off that possibility for 'eager',
but it would be trivial to define a nicer macro in terms of our 'eager',
e.g.:

  (define-syntax eager*
    (syntax-rules ()
      ((_ e0 e ...)
       (call-with-values
           (lambda () e0 e ...)
         eager))))

> More than that, if you go with the above, then you should probably
> consider also making your `delay' and the rest work in the same way
> with multiple subforms = multiple values,

In my experience, 'delay' is used *far* more often than 'eager', and I
consider it more important for 'delay' to accept multi-valued
expressions.

Since 'delay' is necessarily a macro, if it took multiple values in the
form of multiple operands, there'd be no way to use 'delay' with an
expression without knowing how many values it returns.

(call-with-values (lambda () expr) delay) obviously won't work.  You'd
have to do (lazy (call-with-values (lambda () expr) eager)) instead.
That's intolerably awkward.

> to maintain a uniform interface where `eager' and `delay' have the
> same interface.

I agree that it's unfortunate to destroy the symmetry between 'eager'
and 'delay', but I see no way to support multiple values without either
destroying that symmetry or breaking compatibility with SRFI-45.

I also agree that 'eager' should have been a macro, and it's too bad
this wasn't proposed before SRFI-45 was finalized, but it's too late for
that now.

If you can suggest a better way to add support for multiple values that
is compatible with SRFI-45, I'd be glad to hear it.

    Regards,
      Mark