On Wednesday, October 7, 2015 at 11:18:41 PM UTC-4, Sam Tobin-Hochstadt wrote: > 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
Was any consensus reached on this? I've been working through some exercises in Racket that a friend is implementing in Elixir, and I just came across a "method chaining" situation. I ended up simply writing a wrapper function, but using a version of ~> would've been nice. The commit is here: https://github.com/lojic/exercism-racket/commit/5d2d24c240d7157204c473ea98d2e4990bb9e4ca Lines 29-34 on the left compared to using a wrapper function in lines 35-39 on the right. > 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.
