To answer a few comments/misconceptions on this thread: - Specter is not a DSL. Things like ALL and MAP-VALS are first class objects that implement the underlying navigator interface. Specter's core is a high-performance method of composing implementations of that interface. It makes zero assumptions about what kinds of data it will be used for. I think any DSL for this problem would ultimately either not be generic enough or would be overly complex. - If you want to use a number as a navigator, then extend the ImplicitNav protocol on numbers and return (nthpath this). - Zippers are an advanced form of navigation, and Specter integrates them fully in the com.rpl.specter.zipper namespace. However, zippers add significant overhead and indirection, and 99.9% of the time you don't need them (but they do have the occasional use). - I wrote at length about why I think Specter fills a major hole in Clojure: http://nathanmarz.com/blog/clojures-missing-piece.html
On Saturday, March 4, 2017 at 9:55:49 PM UTC-5, Herwig Hochleitner wrote: > > 2017-03-05 0:25 GMT+01:00 Didier <did...@gmail.com <javascript:>>: > > I'm not too sure what the contribs are. Are they simply packages > maintained > > by the Clojure team itself, or are they actually part of the standard > > library? > > As I understand it, they aren't any more sanctioned than any > third-party library, but the goal is to provide a stock of clojure > libraries under the same license as clojure itself. Also they provide > a common CI and path into maven central. > > 2017-03-04 22:52 GMT+01:00 Gregg Reynolds <d...@mobileink.com > <javascript:>>: > > it's easy to imagine a more xsl-like (or even css-like) syntax with the > same > > functionality > > I don't know how it squares up against specter in terms of > performance, but I've always been fond of the selector-engine in > enlive, from an engineering elegance POV, as an interface for tree > query and update. > It utilizes zippers, but only ever does a single pass (save for some > weird selectors). Can specter substantially improve on zippers for > this workload? > Is there an underlying abstraction, that could sit next to clojure.zip > or clojure.data.zip? > -- 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.
