[racket-users] Re: Standardizing the threading macro and organizing packages

On Thursday, October 8, 2015 at 5:09:20 AM UTC+2, Alexis King wrote: > While in St. Louis, I had a brief conversation with Jay, Alex, and Jack about > how we all happen to have our own implementation of Clojure’s threading > macro. That macro is called -> in Clojure, but I believe Greg’s

[racket-users] Re: Standardizing the threading macro and organizing packages

> Duplication is an uncomfortably common problem in Lispy circles, but > fragmentation is never a good thing To be fair, there are plenty of good reasons why duplication / fragmentation would exist, many of them ultimately beneficial to the underlying system. Fragmentation is not per se bad.

Re: [racket-users] Re: Standardizing the threading macro and organizing packages

On Wed, 07 Oct 2015 23:02:23 -0500, Jack Firth wrote: > If this isn't going to be added to the core (and I don't think it > should), then there would need to be some work done on exposure and > making sure everyone who wants this functionality knows "look here > first and only roll your own if

[racket-users] Re: Standardizing the threading macro and organizing packages

I definitely like standard packages, but how will we avoid the problem of this becoming just another threading macro package instead of an actual standard? I also feel like something similar would be useful for anonymous functions, what with curly-fn, rackjure, fancy-app, the cut and cute

[racket-users] Re: Standardizing the threading macro and organizing packages

> On Oct 8, 2015, at 12:02 AM, Jack Firth wrote: > As for the actual package, I'm a strong proponent of a non-macro version > that's just the reverse of compose, mostly because it plays very nicely with > anonymous macro functions like fancy-app. I'm a bit biased as