> > But I don't agree at all with the claim that Specter is some sort of > offbeat, ill-researched version of lenses. >
Since you're responding to me specifically, I'd like to be clear that I never made that claim. I only said we need more experimentation. This is a sufficiently big enough area of ideas to warrant exploration of competing approaches. Specter's navigators can do more than lenses. I can't speak for anybody else, but when I say "lenses", I'm referring to the full range of constructs offered by Edward Kmett's lenses package for Haskell. See the stunningly confusing diagram in the docs: https://hackage.haskell.org/package/lens - This includes "traversals" and "folds" which allow richer transformations than a one-to-one "lens" mapping, like the navigators concept in specter. Specter wouldn't have such richness of functionality and pragmatic > performance considerations > As I've said on Twitter, Nathan has done an absolutely wonderful job with both static (compilation) and dynamic (caching) optimization techniques in Specter. The Haskell lenses library gets a lot of the former from existing GHC wizardry, but the I'm not sure about the latter, since I'm not sophisticated enough with Haskell to tell. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
