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.
That is, the person in charge of the design is expected to fully and deeply understand what they have designed and to seriously consider others suggestions but ultimately not get bogged down in directions that would prevent having something that works well on a reasonable time-scale. Robby On Wed, Oct 7, 2015 at 10:18 PM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> 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 > > 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. -- 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.
