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.
