Okay, let's call it a Context Specific Vocabulary (CSV) ;) Every function is at least a mini DSL, IMO. And as promising as Spec sounds, I still haven't trained up on it because of the size of the new vocabulary (or DSL or whatever you want to call it) it introduces. Adding semantics is expensive for users.
Just wondering here, but would it be impossible for a Specter like system to piggyback on Specs operators for it's navigator vocabulary? Or are the semantics between the operators and navigators too different? On Sun, Mar 5, 2017, 2:16 PM Gregg Reynolds <d...@mobileink.com> wrote: > > > On Mar 5, 2017 1:04 PM, "Timothy Baldridge" <tbaldri...@gmail.com> wrote: > > >> Specter is not a DSL. > > Specter implements a set of terms (navigators) specific to the library > that are interpreted by the library (the transform function) to accomplish > some task for a specific domain (manipulating data structures). In the same > way, `update-in` is a DSL. Both Specter and `update-in` support certain > operators and have certain behaviors under difference occasions. Specter > may compile down to composed functions, or Clojure code, while `update-in` > is always interpreted, but the net effect is still the same. They both are > languages specific to a certain domain. > > > sure, but so is + and every other operator; every op is specific to a > computational domain (e.g. arithmetic). to me DSL means specific to an > application domain. since Specter is not tied to any such domain, i think > it's fair for Nathan to claim it is not a DSL. on the other hand, its > vocabulary is quite idiosyncratic, imo. > > gregg > > > There's noting inherently wrong with using a DSL, they have their places. > The value of the DSL will different for each project and programmer. In > some cases the added cognitive overhead of learning the caveats of a new > DSL may be worth it when compared to the simplification the DSL offers. > Other times not so much, depends on the context. > > Timothy > > On Sun, Mar 5, 2017 at 7:14 AM, Nathan Marz <nathan.m...@gmail.com> wrote: > > 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>: > > 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>: > > 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. > > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > > -- > 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. > > > -- > 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. > -- 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.
