The "language" Specter introduces "specific"ally navigates the "domain" of Clojure data structures. Regexes also provide a DSL that navigate or operate over the string/text domain and that's often considered a large, generic, unstructured domain. What matters is the semantic surface area the library introduces and how idiomatic those semantics are to the language. Core.async is arguably as idiomatic as it can be, but it has a large enough surface area that it hasn't even been folded into clojure.core. And core.async was created by the core team.
I agree though that given the difficulty of editing deeply nested structures in Clojure, Specter does at least make a good _candidate_ for discussing inclusion - Nathan is asking a question that many of us ask when we're introduced to the awesome powers of Specter, "Why can't something like this be in core?" It's a real, ubiquitous problem in Clojure that Specter solves, where not a lot of other solutions yet exist. But given the core team's decision to not include core.async in core, it's hard to imagine them including Specter's idiosyncrasies IMO. But hey, if in a year or two some majority of all new Clojure projects on GitHub are using Specter - and the semantics have become normalized and idiosyncratic - then I think we could argue that maybe Specter is the Right way. Either way, I'll be using Specter when necessary. On Sun, Mar 5, 2017 at 3:19 PM Gregg Reynolds <d...@mobileink.com> wrote: > > > On Mar 5, 2017 2:10 PM, "Gregg Reynolds" <d...@mobileink.com> wrote: > > see the section titled "deftype and defrecord?" at > https://clojure.org/reference/datatypes > > Specter traffics in abstractions, afaik, just like clojure. it does not > depend in any way on application concepts like "bank account", so i think > it's a little unfair to call it x-specific for any x; that makes it sound > less general than clojure itself, which i do not believe is the case. so it > is indeed a good _candidate_ for core. but since i think there are many > unexplored ways to do the same thing, its too soon. Not to mention the > aesthetic question of whether all the UPPER CASE stuff is a good idea. > Personally i find it a little too magical and opaque. > > gregg > > > ps. just as food for thought, what xslt does for xml trees is very similar > to what specter does for clojure structures. if you're familiar with xslt > it's not that hard to imagine sth similar in idiomatic clojure that would > solve the same problems with a very different vocab. > > g > > -- > 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.
