30 minutes ago, Mark H Weaver wrote:
>
> 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.: [...]
Obviously.
> > 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.
IMO, having a good, uniform API is *far* more important than keeping
`eager' a function. Especially in this case, it is most likely going
to be used in places where `delay' would appear, and therefore not
having it be a proper function is unlikely to cause problems.
FWIW, in the N years since we switched our implementation, there has
been no complaint about it.
> 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.
Write a new short srfi which will say "same as srfi-45, except that
`eager' is a macro", then add multiple values. Seriously.
But YMMV, of course.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!