15 minutes ago, Shriram Krishnamurthi wrote:
> Perhaps go the other way?
>
> (future/e <e> ...) ==> (future (lambda () <e> ...))
> (thread/e <e> ...) ==> (thread (lambda () <e> ...))
> (delay/e <e> ...) ==> (delay (lambda () <e> ...))
>
> and so on? That is, accept defeat on the primary names, but occupy
> the /e namespace for the macro versions, and whatever the suffix is,
> keep it really short. There is precedent for offering
> macro/function pairs in let/cc and call/cc.
That seems kind of fine, except for the "/" which makes it read much
more verbosely than something like the overly abused `future*'. I'd
suggest `future:' but that convention is taken too... Maybe `future.'
or `future/'. (Or maybe I lost the feeling of what would look fine.)
There's also the semi-popular syntax extension change, like {E ...}
expanding to (λ () E ...), but that looks very confusing with
something like (thread {(printf "foo\n")}) -- so maybe do that with
the outer form: {thread (printf "foo\n")}. Or maybe do that with a
macro instead: (e thread (printf "foo\n")), which will probably go the
way of `nested'.
(Yeah, I should definitely disqualify myself from further opinionage
here.)
> (Yes, a programmer could do it themselves, but it's annoying to have
> to write these over and over, and code is more readable if everyone
> can agree on names -- my future/e may be your future-e may be
> someone else's future/w/expr.)
+1.
--
((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
