[racket] future

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!