A few thoughts: 1. This is a great idea -- one of the reasons that I think Racket has avoided lots of little dialects despite syntactic flexibility is standardizing the community on one thing. I'm glad you're continuing this.
2. When we've standardized on this sort of thing in the core, the primary way we arranged it is writing things on mailing lists, so I hope that works just as well here. 3. I agree with Jay's point about `data` and such, but I don't think this fits in any existing category. I'm skeptical of a grab-back `util` collection, though, so I think just putting this in it's own collection makes the most sense. If we eventually have more things like this, then we should come up with a category. Sam On Wed, Oct 7, 2015 at 11:09 PM, Alexis King <lexi.lam...@gmail.com> 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 rackjure > library set the Racket standard of calling it ~>, since the arrow is already > used by contracts and types (and the FFI, too, for that matter). I have no > idea how many implementations of this macro exist in the wild, but 5 is > already far too many. > > Duplication is an uncomfortably common problem in Lispy circles, but > fragmentation is never a good thing, so I’m interested in trying to create a > standard implementation. It is my understanding that Racket has mostly > avoided this problem by traditionally absorbing common libraries into the > core, but I also understand there’s been a push to reverse this trend by > spinning these things off into packages. I plan to extract my implementation > of ~> and all its associated friends (I have a lot of them) into their own > package, but I’d also like to ask some questions first. > > First of all, do any people object to this idea in principle? Is this too > trivial of a thing to try and standardize? Assuming that’s not the case, I’ve > been wondering what collection to put these in. Currently, Racket packages > tend to use their own collections, which is even recommended by the > documentation. However, Jay recently brought to my attention that perhaps > this isn’t the best way to organize things: it might be better to extend > existing collections with new modules. For example, he suggested I move my > collections library to data/collection, which would imply that the lens > library should be moved to data/lens. I actually like this idea quite a bit, > especially for packages that are more mature. > > This prompts the question asking where a set of utility macros actually > belong. They don’t belong in data/, certainly, and they don’t belong in > syntax/, since that collection deals with handling syntax objects themselves. > Would it be good to create a util/ collection and place this in > util/threading? Or would these be better in their own, separate collection? > > The danger of departing from the one-to-one correlation with package names, > of course, is the possibility of dramatically increasing the potential for > conflicts. Personally, I think that grouping collections logically might be a > good thing, but maybe it isn’t worth the risk? I’m interested in hearing > people’s thoughts. > > Thanks, > Alexis > > -- > 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. -- 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.
