You don't think
(define-simple-macro (-> var:id expr:expr ...+)
  (let* ([var expr] ...) var))

Is better?

It's more powerful, because it allows placeholders to be arbitrarily nested 
within the expressions.
Also, it allows the user to supply their own identifier to use as a placeholder 
instead of _, so it doesn't run into the problems of substituting an expression 
in a place you didn't want it, for instance if you had another ~> expression 
nested within in.

Because of those two things, it allows pieces of a program to be put together 
easily, without worrying about whether it will do some weird thing like insert 
an ~> expression into another ~> expression and end up with a compile-time 
infinite loop. 

It's also much simpler to keep in your head.

> On Oct 8, 2015, at 1:01 PM, Alexis King <lexi.lam...@gmail.com> wrote:
> 
> I decided to release my threading implementation as the “threading” package. 
> The documentation is here:
> http://pkg-build.racket-lang.org/doc/threading/index.html
> 
> I’m okay with this because I wanted to pull them out of my utils package, 
> anyway, and they’re nice to have, even if we come up with a better solution 
> later. I think thrush and thrush+ from point-free might be nice to have in 
> racket/function, but point-free is a good package for them, otherwise.
> 
>> On Oct 8, 2015, at 5:17 AM, Robby Findler <ro...@eecs.northwestern.edu> 
>> wrote:
>> 
> 
>> In addition to agreeing with you and Sam here Alexis, I would like to
>> point out another thing that has worked well for Racket in design
>> situations such as these: benevolent despotism.
> 
> I appreciate the value of this, certainly, but it doesn’t help much if the 
> “standard” version is just another implementation that nobody agrees on, 
> since that won’t really help the fragmentation much at all.
> 
>> On Oct 8, 2015, at 7:56 AM, Greg Hendershott <greghendersh...@gmail.com> 
>> wrote:
>> 
>> If you do want a Clojure style threading _macro_, rackjure's is the
>> best implementation now AFAIK. I say that with no ego because that's
>> mostly thanks to help from people like Sam and Christoffer Sawicki.
>> Among other things, it's careful to expand using the correct #%app
>> (you can use it w/o using #lang rackjure). It could easily be its own
>> package, now, if that makes more sense.
> 
> I’d be interested to hear what fanciness rackjure’s threading macros provide! 
> It would be nice to incorporate those into my package, since I’m sure there 
> are a few things I’m missing. Expanding to the right #%app is one of those 
> things, to start. My implementation also does some fanciness that Clojure’s 
> does not, such as allowing arbitrary position for the arguments, but it would 
> be nice to combine the best of them both.
> 
> The question about function reader syntax packages is still outstanding. I 
> get the sense that those aren’t terribly commonly used... but then I also get 
> the sense that packages are very reluctant to depend on anything but the 
> core. Does anyone even really use these packages besides their authors?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to