BTW, I like such changes, but there's also the issue of making it
symmetric. Even if there are no uses of `future' at all, I prefer
that it will be like `thread' and `with-output-to-file' (and
`dynamic-wind', with some better name) -- and changing all of these is
obviously impractical. I also don't see some naming convention that
can work nicely.
BTW, the only forms that do this are `delay' and friends -- especially
after I extended them so instead of (delay E) you have (delay E ...).
But `future' seems closer to the above than to this.
Yesterday, Shriram Krishnamurthi wrote:
> Before futures get too embedded in code...
>
> This is probably a silly question, but why does the future construct
> require an extra thunk? The common case is going to be (future
> <expr>); Racket is not Scheme, so it does not need to be afraid of
> adding new syntax. Is it particularly useful to have future be
> available as a proc? It seems to make more sense to have
>
> (future E ...) ==> (future/fun (lambda () E ...))
>
> and provide both future and future/fun, so in the common case, code
> stays that little bit more readable (and that little bit less
> indented).
>
> (I believe Clojure already breaks with tradition in this way.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
