Contribute Specter to Clojure core?

[Nathan Marz]

One of the most common questions I get about Specter is whether it will ever become part of Clojure core. I think it's an interesting proposal and would like to see what the community and core team thinks.

The primary reason for contributing would be that Specter makes Clojure a stronger language. For a language that embraces simplicity, I've always viewed the complexity of dealing with nested data structures a glaring weakness of Clojure. The existing stuff in Clojure, like clojure.walk, zippers, update-in, etc., just doesn't cut it. This problem is very common, and Specter completely solves it with near-optimal performance.

The main thing that makes me hesitate to suggest this is getting bottlenecked on Clojure's dev process. However, Specter is very well developed at this point so it doesn't need to move fast anymore.

Please share your thoughts.

[Rangel Spasov]

Nathan - Specter has been an indispensable part of any Clojure/ClojureScript that I've started in the recent 1+ years. From my experience with it so far (and I'm definitely not using it to its full potential) it has had one killer feature and that is modifying a nested 3+ levels deep data structure that randomly contains vectors, maps, set, et al. For that use case it is a KILLER library - it's outright amazing (and I don't use that word lightly!). From that perspective, that would be two thumbs up for including it in Clojure proper (if it was up to me).

Here comes the BUT :). The more I've used Specter, the more I've come to the opinion that the less you need Specter, the simpler your data structure "architecture" (I generally dislike that word hence the quotes lol) tends to be. In a bad case scenario, Specter might encourage someone to come up with a very deeply nested data structure when a much shallower would do the job. Now, I definitely know and generally agree with "100 functions on 1 data structure is better than 10 functions on 10 data structures" recommendation. But from my 4+ years experience with Clojure, over-nesting your data structures tends to become a little bit like OOP inheritance where you overspecialize the data and the details about your data. Especially in the domain of UI programming/React/ReactNative but also for general backend data-processing and transformation I've found it easier AND simpler to rely more on data "composition" rather than data "inheritance". In other words, keeping your data structures generally shallow, 2 or maximum 3 levels deep.

All that being said, there's many, many cases where the data you're presented with is set in stone either by the problem domain or another person before you (or your past self :) ). In those cases, Specter is ESSENTIAL. Places where I use it to great effect are random/unknown data structure processing for scraping/parsing HTML and processing various API responses where the data shape and structure is not under your control.

Thank you once again for developing this great library - I'm looking forward to everyone's responses in this thread!

[Timothy Baldridge]

While I've looked at Specter several times, I have yet to use it in a project for many of the same reasons that Rangel mentioned. Either my data is shallow enough that clojure.core functions work just fine, or my data is complex enough that I need cross-entity joins, and arbitrary clojure logic. In short: I don't often need a path-based transformer, I need a query engine for Clojure data. 

Timothy

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+unsubscribe@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+unsubscribe@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)

[Herwig Hochleitner]

How about making specter into a contrib library?​

[Mark Engelberg]

I like Specter and would love to have it readily available in any project, so that aspect is appealing.  However, there are a handful of subtle ways that Specter doesn't feel like it was designed by the same people who wrote core.  For example, Clojure's built-in transformation functions on data structures put the data structure first, so that they can be easily applied to data structures sitting inside reference types.  For similar reasons of convenience, Clojure's update-in can take extra parameters for the transformation function.  Specter puts the navigator first and transform doesn't take optional additional args to pass to the transformation function.

So I think these subtle differences might cause confusion if it were in core.  Newcomers already struggle with the fact that sequence transformation functions (map, take, reduce) are an exception to the rule that data structures tend to come first.

[Alex Miller]

I don't think Rich would be interested in including Specter in core. Making it a contrib doesn't really seem like it would have many advantages to me over its current status.

[Beau Fabry]

> The main thing that makes me hesitate to suggest this is getting bottlenecked on Clojure's dev process.

Imo this is a big deal. I like the way specter has the ability to add new generally useful navigators and paths with new versions as people "discover" them, I don't think that's a great fit for the overhead of a language release process.

[Nathan Marz]

Alex – care to elaborate? When I get this question it would be nice to be able to tell people why the core team isn't interested.

Beau – new navigators can easily be provided in external libraries. The core of Specter (navigator composition and inline compilation/caching) is very stable at this point so I don't anticipate it needing much change.

[Matching Socks]

One must recognize Clojure as an art project.  It follows, that the choice of curated libraries is an aspect of the artistic expression.  Look at them -- what else could it be?

clojure.xml was unorthodox.  clojure.zip is anti-gravity.  clojure.core.logic is inside-out.  clojure.core.typed is audacious.

One thing those libraries are not, is everything you need.  The art's meaning leads elsewhere.  Do not feel limited. 

All in all, I would prefer that you keep Specter independent.  I am glad Ring is not in core.  I am glad Schema is not in core.  Works of pragmatism don't need to be there.  Greatness is not a one-dimensional space.

[Alex Miller]

On Wednesday, February 15, 2017 at 3:41:36 PM UTC-6, Nathan Marz wrote:

Alex – care to elaborate? When I get this question it would be nice to be able to tell people why the core team isn't interested.

The default answer to all such questions is no. Clojure has a small library and Rich wants it to remain that way. 

[John Newman]

I think the path navigator DSL feels slightly un-Clojurey. But other than that, I think Specter is pure magic and Nathan is right that editing deeply nested data structures in Clojure is a point of deficiency, especially for people coming from mutable languages/data structures. To that extent, I think Specter does a yeoman's job of filling that "missing piece" of Clojure. Again, it's only the navigator DSL that feels a little un-Clojurey to me. 

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.

[Mars0i]

I've never used Specter, but my needs are modest compared to some Clojure programmers'.  (Great introductory blog post, Nathan, btw.)  Intuitively, it feels to me like Specter is too big of a monster to be in core.  I am not surprised that that's not going to be an option. 

The idea of making it a contrib library seems reasonable, though.  Perhaps this would involve some revision of the syntax.  Alex said that there's no advantage to making it a contrib library, but maybe there is a bit of an advantage.

Contrib libraries are easy to discover--they're listed in a prominent place at clojure.org--and they are easier to trust.  There are good non-contrib libraries, and always will be, but one has to investigate an external library to figure out how robust it is, what stage of development it's at, whether it's currently supported, whether it will be supported in the future, whether there are competing libraries that should be evaluated, etc.  I gather that Specter passes those tests well, but anyone new to it might not know that.  With an official release of a contrib library, even if it's 0.x version, being an official contrib library is a stamp of approval that gives one a reason to trust it, until proven otherwise.  Further, although I don't think Specter belongs in core, it does feel like something that might be appropriate as a contrib library.  I can see how useful it could be, and what it does is no more complicated than some other contrib libraries.

[Asim Jalis]

What might be a Clojurey syntax for doing path navigation? In other words how could get-in be extended so that it could parse nested vectors like it parses nested maps? Thinking out aloud, an integer in the path when the data structure at that level is a vector should treat the integer as an index. 

What about ALL? What would be Clojurey way of doing ALL? How about asterisk *? Or maybe underscore _? Or nil?

Thoughts?

On Fri, Mar 3, 2017 at 7:27 PM, John Newman <joh...@gmail.com> wrote:

I think the path navigator DSL feels slightly un-Clojurey. But other than that, I think Specter is pure magic and Nathan is right that editing deeply nested data structures in Clojure is a point of deficiency, especially for people coming from mutable languages/data structures. To that extent, I think Specter does a yeoman's job of filling that "missing piece" of Clojure. Again, it's only the navigator DSL that feels a little un-Clojurey to me. 

On Wed, Feb 15, 2017 at 10:05 PM Alex Miller <al...@puredanger.com> wrote:

On Wednesday, February 15, 2017 at 3:41:36 PM UTC-6, Nathan Marz wrote:

Alex – care to elaborate? When I get this question it would be nice to be able to tell people why the core team isn't interested.

The default answer to all such questions is no. Clojure has a small library and Rich wants it to remain that way. 

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+unsubscribe@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+unsubscribe@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 clo...@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+unsubscribe@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+unsubscribe@googlegroups.com.

[Erik Assum]

My thoughts on this were spurred by this tweet from Nikita Prokopov 

https://twitter.com/nikitonsky/status/837049980053516310

I generally don't have the need to alter stuff deep down in data structures, but when I do, I don't mind writing the functions to do so. 

The two things that worries me about Specter are

1) One more path-DSL to learn for both my team and I. 

2) If Clojure were an OO-language, wouldn't I be violating the law of Demeter https://en.m.wikipedia.org/wiki/Law_of_Demeter when using specter?

I realize that these are not arguments for or against Specter going into Clojure, more my thoughts on why I'm not using it. 

Erik. 

-- 

i farta

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.

[Mark Engelberg]

The first time I watched Nathan talk about Specter, I had the exact same thoughts -- "My data structures aren't that complex, I can't relate to these examples, I don't need Specter, I'm fine with Clojure's get-in, update-in, assoc-in."

But then, I challenged myself for one day to use Specter's select, transform, set-val with navigators as an alternative to Clojure's built-ins, just to get a feel for how they worked.

Once the library was already required there at the top of my namespace, and once I became accustomed to the navigators, suddenly, by the end of that day I was seeing all kinds of places where I could use Specter in non-obvious ways in my code to make it dramatically leaner and more elegant.

Note that this was code where I was getting along just fine without Specter.  Yes, I could get along without it, but Specter made the code better.  And, oh yeah, faster as well.

There seems to be a kind of thinking expressed here that Specter somehow corrupts your programming style and makes you more likely to create unnecessarily deep data structures.  But your data structures don't actually have to be all that deep to derive benefit from Specter.  My data structures weren't all that deep before Specter, and they aren't any deeper now -- I just have richer tools to work with.

So take this as one data point:  my assessment of Specter before I actually tried it turned out to be wrong, and its utility greatly exceeded my expectations.  Try it for a day or two, and maybe you too will "see the light".

--Mark

On Sat, Mar 4, 2017 at 1:22 AM, Erik Assum <er...@assum.net> wrote:

My thoughts on this were spurred by this tweet from Nikita Prokopov 

https://twitter.com/nikitonsky/status/837049980053516310

I generally don't have the need to alter stuff deep down in data structures, but when I do, I don't mind writing the functions to do so. 

The two things that worries me about Specter are

1) One more path-DSL to learn for both my team and I. 

2) If Clojure were an OO-language, wouldn't I be violating the law of Demeter https://en.m.wikipedia.org/wiki/Law_of_Demeter when using specter?

I realize that these are not arguments for or against Specter going into Clojure, more my thoughts on why I'm not using it. 

Erik. 

-- 

i farta

Den 16. feb. 2017 kl. 04.05 skrev Alex Miller <al...@puredanger.com>:

On Wednesday, February 15, 2017 at 3:41:36 PM UTC-6, Nathan Marz wrote:

Alex – care to elaborate? When I get this question it would be nice to be able to tell people why the core team isn't interested.

The default answer to all such questions is no. Clojure has a small library and Rich wants it to remain that way. 

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+unsubscribe@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+unsubscribe@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 clo...@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+unsubscribe@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+unsubscribe@googlegroups.com.

[Moe Aboulkheir]

On Sat, Mar 4, 2017 at 6:35 AM, Asim Jalis <asim...@gmail.com> wrote:

What might be a Clojurey syntax for doing path navigation? In other words how could get-in be extended so that it could parse nested vectors like it parses nested maps? Thinking out aloud, an integer in the path when the data structure at that level is a vector should treat the integer as an index. 

If I'm reading you correctly, that is Clojure's current behaviour - (get-in {:a [{:b "X"}]}  [:a 0 :b]) => "X"

Take care,

Moe

[Gregg Reynolds]

On Mar 3, 2017 6:27 PM, "John Newman" <joh...@gmail.com> wrote:

I think the path navigator DSL feels slightly un-Clojurey. But other than that, I think Specter is pure magic and Nathan is right that editing deeply nested data structures in Clojure is a point of deficiency, especially for people coming from mutable languages/data structures. To that extent, I think Specter does a yeoman's job of filling that "missing piece" of Clojure. Again, it's only the navigator DSL that feels a little un-Clojurey to me.

+1.  the functionality is great, but the api imho is not just a little unclojurish, it's massively unclojurish.  MAP-VALS? END?  No way, for me at least.

Specter is a specific solution to a general problem.  all such solutions will probably boil down to more or less the same thing, implementation-wise.  but the interface makes all the diff.  for example, it's easy to imagine a more xsl-like (or even css-like) syntax with the same functionality.

so fwiw i would oppose making specter part of core, but i would enthusiatically support making the functionality of specter part of core, in some form yet to be determined.

-g

[Gregg Reynolds]

On Mar 4, 2017 3:52 PM, "Gregg Reynolds" <d...@mobileink.com> wrote:

On Mar 3, 2017 6:27 PM, "John Newman" <joh...@gmail.com> wrote:

I think the path navigator DSL feels slightly un-Clojurey. But other than that, I think Specter is pure magic and Nathan is right that editing deeply nested data structures in Clojure is a point of deficiency, especially for people coming from mutable languages/data structures. To that extent, I think Specter does a yeoman's job of filling that "missing piece" of Clojure. Again, it's only the navigator DSL that feels a little un-Clojurey to me.

+1.  the functionality is great, but the api imho is not just a little unclojurish, it's massively unclojurish.  MAP-VALS? END?  No way, for me at least.

Specter is a specific solution to a general problem.  all such solutions will probably boil down to more or less the same thing, implementation-wise.  but the interface makes all the diff.  for example, it's easy to imagine a more xsl-like (or even css-like) syntax with the same functionality.

more to the point, imho everything specter is doing could be expressed in a more naturally clojure idiom.

for example, let's take the first example at ,https://github.com/nathanmarz/specter/blob/master/README.md, which amounts to "apply f to every value in a map structure, at every level". this would be a good thing to have. essentially, update-in with wildcards.  sth like (update-in-v* m even? inc) would do quite nicely, i think. update-in-v means map values (as opposed to update-in-k) the * makes it recursive, even? is the predicate that selects values, inc is the fn to apply.

[John Newman]

Gregg, agreed. But as an aside, as an external library, like core.async, Specter is a shining example of why Clojure (and lisp) is such an awesome platform. The fact that Nathan was able to even implement this functionality, in some places even more performant than core idioms, imho proves that Clojure has power well beyond what the core team can or will provide to users. That's a good sell for both Clojure as a platform and for Specter as a library.

[Gregg Reynolds]

On Mar 4, 2017 5:08 PM, "John Newman" <joh...@gmail.com> wrote:

Gregg, agreed. But as an aside, as an external library, like core.async, Specter is a shining example of why Clojure (and lisp) is such an awesome platform.

+1001.  to be clear, i am _not_ saying specter is anthing less than awesome. just talking ui.

The fact that Nathan was able to even implement this functionality, in some places even more performant than core idioms, imho proves that Clojure has power well beyond what the core team can or will provide to users. That's a good sell for both Clojure as a platform and for Specter as a library.

yepper.

-g

[Didier]

This got me thinking, what is Clojure?

As I see it, Clojure is a combination of syntax and semantics combined with a standard library of functions and macros. Given the Clojure syntax, and the Clojure special forms, and Clojure core, I have myself Clojure.

Given that, we should be careful when adding things into core, since that makes the burden of writing a Clojure compiler heavier, as anyone who would like to port Clojure to another platform would need to re-implement the full standard library.

With this in mind, I don't think Specter is essential. In fact, I think the things we'd want into Core are everything that handles IO, and the basic operations that allows the Clojure language features and semantics.

If we add Specter to core, we make it a first class semantic. Its DSL becomes part of the syntax of Clojure.

Now, adding it to contribs could be fine, but 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?

Either way, the beauty of Clojure is that libraries are unconstrained, so Specter would gain nothing from being added to core or part of contrib except for better publicity. So I'd vote for no.

[Herwig Hochleitner]

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?

[Nathan Marz]

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

[Timothy Baldridge]

>>  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. 

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 

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+unsubscribe@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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Gregg Reynolds]

On Mar 5, 2017 1:04 PM, "Timothy Baldridge" <tbald...@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

[John Newman]

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?

clojure+u...@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+u...@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 clo...@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+u...@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+u...@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 clo...@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+u...@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+u...@googlegroups.com.

[Gregg Reynolds]

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

[Gregg Reynolds]

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

[John Newman]

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.

--

[Asim Jalis]

Moe: Good point. The specific use case I had was that I wanted to be able to extract all the values that were on a path—in other words the ability to use a wildcard in get-in. For example, this returns "X1". I would like to use get-in to return ["X1" "X2"]. In other words use a wildcard for :b1.

(get-in {:a [{:b1 "X1"} {:b2 "X2"}]} [:a 0 :b1]) 

--

[Gregg Reynolds]

On Mar 4, 2017 12:35 AM, "Asim Jalis" <asim...@gmail.com> wrote:

What might be a Clojurey syntax for doing path navigation? In other words how could get-in be extended so that it could parse nested vectors like it parses nested maps? Thinking out aloud, an integer in the path when the data structure at that level is a vector should treat the integer as an index. 

What about ALL? What would be Clojurey way of doing ALL? How about asterisk *? Or maybe underscore _? Or nil?

looks like identity to me.

i'm still not very deep into specter, but it looks a lot like xslt, just with a different syntax and processing strategy.

gregg

[Joe Python]

I rarely program in Clojure. At work I have to deal with a lot of deeply nested data structures. Specter helps me to navigate those nested data pretty easily.
The navigators does looks unlispy for the newcomer. But if you bother to learn it , you don't have to invent your own.
Above all, the code is very readable which is unusual from someone like me :)
I recommend Specter to be a part Clojure contrib.
Thank you,  Nathan Marz.
- Joe Python

[Mars0i]

A few thoughts about Specter from someone new to it but who's already found it incredibly useful.  I'm happy to be corrected on any points that I've misunderstood.

Clojure functions follow something like the Unix "do one thing and do it well" ideal.  There are exceptions, but a lot of what's great about Clojure is how sensibly Clojure functions "do one thing well" in an integrated, flexible way.

Specter doesn't do one thing, and do it well.  It does a slew of things extremely well--using a bunch of "does one thing well" functions and macros.

Not everything that's great and useful does just one thing, well.  In Unix, you know, there's this command called 'bash'.  It does a slew of things.  On my system, I have another command 'lein repl', that doesn't just do one thing, either.  Both of these allow one to do a slew of things using a bunch of "does one thing well" operators.

So ... I think it's correct to say that Specter is a language.  Not a fully general language, but a general-purpose language for Clojure data structure querying and manipulation.  It's a language in at least the sense that SQL is a language.  (Doesn't matter whether we call called it a DSL, a DGL ("domain general"), a CSV, or what.)

I can't know why RH and the core team don't think Specter should be a part of core, but the fact that something is an entire language--something that's complex on its own and does more than a couple of things well, is a reason that someone might reasonably feel uncomfortable about adding it to clojure.core, or even about making it an official contrib library.  It's a reason that someone might feel that Specter isn't Clojure-ey--because most Clojure functions don't do a slew of things, and we love that about it.  I get it.

I'm not expressing an opinion about whether Specter should be in Clojure.core or contrib.  I'm trying to clarify why I think it's reasonable to feel it shoudn't (because it does a slew of things), and why I think it's reasonable to feel that it should (because of the slew of things that it does well and more easily and efficiently).

(As for people not liking Specter's syntax: I don't think it's unreasonable to simply "feel" that something's syntax isn't sufficiently Clojurey.  Call it "aesthetic judgement" if you want, but some things that are important for users can be difficult to spell out.  However, discomfort with syntax doesn't seem like a good reason not to consider incorporating something into the core or the contrib system. Syntax can be revised, if that's what's needed, without harm to the underlying system.  Someone who loves Specter's functionality but dislikes its syntax could even start their own project to give it a new "skin".  Of course syntactic revisions shouldn't make the system harder to use overall.)