Re: Navigators and lenses

[Michael Sperber]

Jason Felice  writes:

> I'm very curious why most lens libraries don't just use fns with arity 1
> and 2.

Glad you mentioned it.

https://github.com/active-group/active-clojure/commit/51fd8984f2dcebc1af7ee91fc36e3360299c6fed

-- 
Regards,
Mike

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

Re: Navigators and lenses

[Jason Felice]

I'm very curious why most lens libraries don't just use fns with arity 1
and 2.

(I'm going to guess that Specter doesn't because it wants more
introspection into the lenses for optimization purposes.)

On Thu, Mar 9, 2017 at 4:25 PM, Mark Engelberg 
wrote:

> On Mar 9, 2017 9:52 AM, "Brandon Bloom"  wrote:
> >>
> >
> > 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.
>
> My comment wasn't intended as directed specifically at you.  Your list of
> references was interesting and useful.  Thanks for posting them.
>
> --
> 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.

Re: Navigators and lenses

[Mark Engelberg]

On Mar 9, 2017 9:52 AM, "Brandon Bloom"  wrote:
>>
>
> 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.

My comment wasn't intended as directed specifically at you.  Your list of
references was interesting and useful.  Thanks for posting them.

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

Re: Navigators and lenses

[Brandon Bloom]

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

Re: Navigators and lenses

[Didier]

At this point, I feel like dismissing your library outright. But I'd like to 
reconsider and believe that you just fumbled to express your true intents.

Maybe try a do over? I'd like to know... Did you research Specter? Did you 
research Haskell lenses and racket lenses? Did you spend 2 months thinking 
about this? What were your thoughts? What did you see as issues in all of them, 
why is your approach better, or what different kind of trade offs does it make? 
Why should I care about it?

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

Re: Navigators and lenses

[Edwin Watkeys]

Nathan,

I am deeply sorry for offending you. Truly. It was not my intent. My entire 
argument can be boiled down to Specter reminds me of the Common Lisp LOOP 
macro. Is that like saying "I don't like parentheses"? Maybe.

Again, I apologize.

Edwin

On Thursday, March 9, 2017 at 10:15:55 AM UTC-5, Nathan Marz wrote:
>
> Edwin, these personal comments about me are extremely inappropriate. Your 
> claim that I ignore the work of others is just plain wrong, and that you 
> would make such comments out of the blue is truly incomprehensible.
>
> You claim Specter is "deeply un-Clojure-y" without providing a single 
> example. This makes your argument boil down to "I don't like the way 
> Specter makes me feel", which is no different than the complaints 
> non-Lispers make about Lisp's parentheses.
>
> Specter's core is just a simple interface and a high-performance way of 
> composing implementations of that interface together. Everything else in 
> Specter (the navigators) is built on top of that interface. So if you only 
> want to use the "lens-like" functionality, you can literally ignore 
> everything else because it doesn't affect you in any way. Additionally, 
> supporting those other use cases does not make the basic use cases more 
> complex or verbose.
>
> I've found that Clojure programmers find Specter to be very intuitive. 
> What they have trouble grasping is the full scope with which Specter can be 
> applied, because thinking about data structures in terms of navigation is a 
> new mindset. This is exactly the blub paradox as famously written about by 
> Paul Graham back in the day. 
>
> Finally, suggestions that more research and experimentation is needed in 
> this area must be paired with at least one example of how Specter is 
> deficient. Otherwise, it's an empty discussion. 
>
>
> On Thursday, March 9, 2017 at 9:00:37 AM UTC-5, Edwin Watkeys wrote:
>>
>> puzzler,
>>
>> I guess I haven't said this, but I think it's worth saying that I have 
>> nothing against Specter. Godspeed to people who want to use it. And I don't 
>> think it should be judged against some other facility in another language; 
>> human progress would cease if for every Y, Y has to be a better X than X. 
>> Lenses, though, are one way that humans have tried to cope with accessing 
>> and updating nested data structures, and they're worth thinking about. 
>> Rich's hammock driven development talk influenced me powerfully because his 
>> espoused methodology ran so counter to my code-first-think-later instincts, 
>> and so I have the zeal of the converted with respect to the "do some 
>> research" step of HDD.
>>
>> What you point out—the power and expressiveness of Specter—some people 
>> might consider kitchen-sink-y. My interest is in uncovering ways of dealing 
>> with the 90% of situations where something like Specter might be used and 
>> making them as ridiculously simple and Clojure-y as possible. That 90% of 
>> usage maps to, in my experience, maybe 25% of the feature set of Specter. 
>> (YMMV, of course.) I want to facilitate the writing of code that a typical 
>> Clojure developer will intuitively understand.
>>
>> Edwin
>>
>> On Thursday, March 9, 2017 at 3:10:50 AM UTC-5, puzzler wrote:
>>>
>>> Just finished reading through Racket's lens library to compare.  Specter 
>>> can do everything that Racket's lens library can do, but the converse is 
>>> not true.  Specter's navigators can do more than lenses.
>>>
>>> The lens-like navigators are the most obviously useful parts of Specter, 
>>> and maybe for some people that's all they need and they would prefer to 
>>> hide the other functionality.  If so, it looks to me like it would be 
>>> trivial to build a lens library like Racket's out of Specter, and it would 
>>> almost certainly be higher performance than the "obvious" implementation of 
>>> lenses.
>>>
>>> But I don't agree at all with the claim that Specter is some sort of 
>>> offbeat, ill-researched version of lenses.  It is something more advanced.  
>>> If Nathan had constrained his thinking to these other approaches, Specter 
>>> wouldn't have such richness of functionality and pragmatic performance 
>>> considerations.  
>>>
>>>
>>> On Wed, Mar 8, 2017 at 5:35 PM, Brandon Bloom  
>>> wrote:
>>>
 Responsible adults sometimes needs to access and modify deeply nested 
> data structures


 So far, my experience has been that it is almost always better to build 
 a pair of flattening and unflattening transforms on the data. Especially 
 since you frequently want only one flattening, but potentially many 
 un-flattenings. The "unflattened" form (aka "documents") is usually an 
 end-point where data goes to die; assuming it isn't immediately displayed 
 on the screen.

 However, having said that, path-dependent / context-sensitive query is 
 a very rich and interesting space that does have meaningful utility, 
 especially in 

Re: Navigators and lenses

[Nathan Marz]

Edwin, these personal comments about me are extremely inappropriate. Your 
claim that I ignore the work of others is just plain wrong, and that you 
would make such comments out of the blue is truly incomprehensible.

You claim Specter is "deeply un-Clojure-y" without providing a single 
example. This makes your argument boil down to "I don't like the way 
Specter makes me feel", which is no different than the complaints 
non-Lispers make about Lisp's parentheses.

Specter's core is just a simple interface and a high-performance way of 
composing implementations of that interface together. Everything else in 
Specter (the navigators) is built on top of that interface. So if you only 
want to use the "lens-like" functionality, you can literally ignore 
everything else because it doesn't affect you in any way. Additionally, 
supporting those other use cases does not make the basic use cases more 
complex or verbose.

I've found that Clojure programmers find Specter to be very intuitive. What 
they have trouble grasping is the full scope with which Specter can be 
applied, because thinking about data structures in terms of navigation is a 
new mindset. This is exactly the blub paradox as famously written about by 
Paul Graham back in the day. 

Finally, suggestions that more research and experimentation is needed in 
this area must be paired with at least one example of how Specter is 
deficient. Otherwise, it's an empty discussion. 


On Thursday, March 9, 2017 at 9:00:37 AM UTC-5, Edwin Watkeys wrote:
>
> puzzler,
>
> I guess I haven't said this, but I think it's worth saying that I have 
> nothing against Specter. Godspeed to people who want to use it. And I don't 
> think it should be judged against some other facility in another language; 
> human progress would cease if for every Y, Y has to be a better X than X. 
> Lenses, though, are one way that humans have tried to cope with accessing 
> and updating nested data structures, and they're worth thinking about. 
> Rich's hammock driven development talk influenced me powerfully because his 
> espoused methodology ran so counter to my code-first-think-later instincts, 
> and so I have the zeal of the converted with respect to the "do some 
> research" step of HDD.
>
> What you point out—the power and expressiveness of Specter—some people 
> might consider kitchen-sink-y. My interest is in uncovering ways of dealing 
> with the 90% of situations where something like Specter might be used and 
> making them as ridiculously simple and Clojure-y as possible. That 90% of 
> usage maps to, in my experience, maybe 25% of the feature set of Specter. 
> (YMMV, of course.) I want to facilitate the writing of code that a typical 
> Clojure developer will intuitively understand.
>
> Edwin
>
> On Thursday, March 9, 2017 at 3:10:50 AM UTC-5, puzzler wrote:
>>
>> Just finished reading through Racket's lens library to compare.  Specter 
>> can do everything that Racket's lens library can do, but the converse is 
>> not true.  Specter's navigators can do more than lenses.
>>
>> The lens-like navigators are the most obviously useful parts of Specter, 
>> and maybe for some people that's all they need and they would prefer to 
>> hide the other functionality.  If so, it looks to me like it would be 
>> trivial to build a lens library like Racket's out of Specter, and it would 
>> almost certainly be higher performance than the "obvious" implementation of 
>> lenses.
>>
>> But I don't agree at all with the claim that Specter is some sort of 
>> offbeat, ill-researched version of lenses.  It is something more advanced.  
>> If Nathan had constrained his thinking to these other approaches, Specter 
>> wouldn't have such richness of functionality and pragmatic performance 
>> considerations.  
>>
>>
>> On Wed, Mar 8, 2017 at 5:35 PM, Brandon Bloom  
>> wrote:
>>
>>> Responsible adults sometimes needs to access and modify deeply nested 
 data structures
>>>
>>>
>>> So far, my experience has been that it is almost always better to build 
>>> a pair of flattening and unflattening transforms on the data. Especially 
>>> since you frequently want only one flattening, but potentially many 
>>> un-flattenings. The "unflattened" form (aka "documents") is usually an 
>>> end-point where data goes to die; assuming it isn't immediately displayed 
>>> on the screen.
>>>
>>> However, having said that, path-dependent / context-sensitive query is a 
>>> very rich and interesting space that does have meaningful utility, 
>>> especially in the context of graph-like datasets. This is especially true 
>>> when combined with some kind of algebra for unioning/intersecting/etc. I'm 
>>> also interested in this sort of thing for programmable user-interface use 
>>> cases: Think text editors with multiple-cursors.
>>>
>>> I think experimentation is in order

>>>
>>> Agreed. Here's some starting points for pre-hammock reading/viewing 
>>> materials:
>>>
>>> *Tree 

Re: Navigators and lenses

[Edwin Watkeys]

puzzler,

I guess I haven't said this, but I think it's worth saying that I have 
nothing against Specter. Godspeed to people who want to use it. And I don't 
think it should be judged against some other facility in another language; 
human progress would cease if for every Y, Y has to be a better X than X. 
Lenses, though, are one way that humans have tried to cope with accessing 
and updating nested data structures, and they're worth thinking about. 
Rich's hammock driven development talk influenced me powerfully because his 
espoused methodology ran so counter to my code-first-think-later instincts, 
and so I have the zeal of the converted with respect to the "do some 
research" step of HDD.

What you point out—the power and expressiveness of Specter—some people 
might consider kitchen-sink-y. My interest is in uncovering ways of dealing 
with the 90% of situations where something like Specter might be used and 
making them as ridiculously simple and Clojure-y as possible. That 90% of 
usage maps to, in my experience, maybe 25% of the feature set of Specter. 
(YMMV, of course.) I want to facilitate the writing of code that a typical 
Clojure developer will intuitively understand.

Edwin

On Thursday, March 9, 2017 at 3:10:50 AM UTC-5, puzzler wrote:
>
> Just finished reading through Racket's lens library to compare.  Specter 
> can do everything that Racket's lens library can do, but the converse is 
> not true.  Specter's navigators can do more than lenses.
>
> The lens-like navigators are the most obviously useful parts of Specter, 
> and maybe for some people that's all they need and they would prefer to 
> hide the other functionality.  If so, it looks to me like it would be 
> trivial to build a lens library like Racket's out of Specter, and it would 
> almost certainly be higher performance than the "obvious" implementation of 
> lenses.
>
> But I don't agree at all with the claim that Specter is some sort of 
> offbeat, ill-researched version of lenses.  It is something more advanced.  
> If Nathan had constrained his thinking to these other approaches, Specter 
> wouldn't have such richness of functionality and pragmatic performance 
> considerations.  
>
>
> On Wed, Mar 8, 2017 at 5:35 PM, Brandon Bloom  > wrote:
>
>> Responsible adults sometimes needs to access and modify deeply nested 
>>> data structures
>>
>>
>> So far, my experience has been that it is almost always better to build a 
>> pair of flattening and unflattening transforms on the data. Especially 
>> since you frequently want only one flattening, but potentially many 
>> un-flattenings. The "unflattened" form (aka "documents") is usually an 
>> end-point where data goes to die; assuming it isn't immediately displayed 
>> on the screen.
>>
>> However, having said that, path-dependent / context-sensitive query is a 
>> very rich and interesting space that does have meaningful utility, 
>> especially in the context of graph-like datasets. This is especially true 
>> when combined with some kind of algebra for unioning/intersecting/etc. I'm 
>> also interested in this sort of thing for programmable user-interface use 
>> cases: Think text editors with multiple-cursors.
>>
>> I think experimentation is in order
>>>
>>
>> Agreed. Here's some starting points for pre-hammock reading/viewing 
>> materials:
>>
>> *Tree Traversal *
>>
>>- XPath: https://www.w3.org/TR/xpath/
>>- CSS: https://www.w3.org/TR/css3-selectors/
>>
>> *Richer Tree Querying*
>>
>>- XQuery: https://www.w3.org/TR/xquery/
>>- jQuery: https://api.jquery.com
>>
>> *Second-Class "Generalized References" (nee "L-values")*
>>
>>- Common Lisp: 
>>http://www.lispworks.com/documentation/lw50/CLHS/Body/05_a.htm
>>- C/C++: 
>>
>> http://eli.thegreenplace.net/2011/12/15/understanding-lvalues-and-rvalues-in-c-and-c
>>
>> *Lenses in Other Languages*
>>
>>- Haskell: 
>>
>> https://skillsmatter.com/skillscasts/4251-lenses-compositional-data-access-and-manipulation
>>  
>>(great overview of key concepts!)
>>- Racket: https://docs.racket-lang.org/lens/index.html
>>
>> *Graph Querying*
>>
>>- Neo4j Cypher: https://neo4j.com/developer/cypher-query-language/
>>- TinkerPop Gremlin: https://tinkerpop.apache.org/gremlin.html
>>
>> -- 
>> 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 

Re: Navigators and lenses

[Edwin Watkeys]

Alex,

I deeply appreciate the diligent virtue policing, but I don't think calling 
out the Comité de salut public is necessary. There was no attack: I'm much 
more a Nathan than a Rich person. The world needs both kinds of people. For 
me, Clojure would have simply been Yet Another Lisp had Nathan not put 
together Cascalog back in 2010. Yin and Yang.

Given that Rich is the BDFL of Clojure and Clojure is an art project, as 
someone recently wrote, issues of style are far from irrelevant when 
discussing what should be in or out of Clojure proper.

Edwin

On Wednesday, March 8, 2017 at 10:34:10 PM UTC-5, Alex Miller wrote:
>
> Edwin, we can have technical discussions about this topic without 
> comparing Nathan to Rich or making comments about Nathan that may feel like 
> a personal attack.
>
> Thanks
>

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

Re: Navigators and lenses

[Mark Engelberg]

Just finished reading through Racket's lens library to compare.  Specter
can do everything that Racket's lens library can do, but the converse is
not true.  Specter's navigators can do more than lenses.

The lens-like navigators are the most obviously useful parts of Specter,
and maybe for some people that's all they need and they would prefer to
hide the other functionality.  If so, it looks to me like it would be
trivial to build a lens library like Racket's out of Specter, and it would
almost certainly be higher performance than the "obvious" implementation of
lenses.

But I don't agree at all with the claim that Specter is some sort of
offbeat, ill-researched version of lenses.  It is something more advanced.
If Nathan had constrained his thinking to these other approaches, Specter
wouldn't have such richness of functionality and pragmatic performance
considerations.


On Wed, Mar 8, 2017 at 5:35 PM, Brandon Bloom 
wrote:

> Responsible adults sometimes needs to access and modify deeply nested data
>> structures
>
>
> So far, my experience has been that it is almost always better to build a
> pair of flattening and unflattening transforms on the data. Especially
> since you frequently want only one flattening, but potentially many
> un-flattenings. The "unflattened" form (aka "documents") is usually an
> end-point where data goes to die; assuming it isn't immediately displayed
> on the screen.
>
> However, having said that, path-dependent / context-sensitive query is a
> very rich and interesting space that does have meaningful utility,
> especially in the context of graph-like datasets. This is especially true
> when combined with some kind of algebra for unioning/intersecting/etc. I'm
> also interested in this sort of thing for programmable user-interface use
> cases: Think text editors with multiple-cursors.
>
> I think experimentation is in order
>>
>
> Agreed. Here's some starting points for pre-hammock reading/viewing
> materials:
>
> *Tree Traversal *
>
>- XPath: https://www.w3.org/TR/xpath/
>- CSS: https://www.w3.org/TR/css3-selectors/
>
> *Richer Tree Querying*
>
>- XQuery: https://www.w3.org/TR/xquery/
>- jQuery: https://api.jquery.com
>
> *Second-Class "Generalized References" (nee "L-values")*
>
>- Common Lisp: http://www.lispworks.com/documentation/lw50/CLHS/
>Body/05_a.htm
>- C/C++: http://eli.thegreenplace.net/2011/12/15/
>understanding-lvalues-and-rvalues-in-c-and-c
>
> 
>
> *Lenses in Other Languages*
>
>- Haskell: https://skillsmatter.com/skillscasts/4251-lenses-
>compositional-data-access-and-manipulation
>
> 
>(great overview of key concepts!)
>- Racket: https://docs.racket-lang.org/lens/index.html
>
> *Graph Querying*
>
>- Neo4j Cypher: https://neo4j.com/developer/cypher-query-language/
>- TinkerPop Gremlin: https://tinkerpop.apache.org/gremlin.html
>
> --
> 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.

Re: Navigators and lenses

[Brandon Bloom]

A big one I forgot:

RDF's query language SPARQL: https://www.w3.org/TR/rdf-sparql-query/

On Wednesday, March 8, 2017 at 5:35:42 PM UTC-8, Brandon Bloom wrote:
>
> Responsible adults sometimes needs to access and modify deeply nested data 
>> structures
>
>
> So far, my experience has been that it is almost always better to build a 
> pair of flattening and unflattening transforms on the data. Especially 
> since you frequently want only one flattening, but potentially many 
> un-flattenings. The "unflattened" form (aka "documents") is usually an 
> end-point where data goes to die; assuming it isn't immediately displayed 
> on the screen.
>
> However, having said that, path-dependent / context-sensitive query is a 
> very rich and interesting space that does have meaningful utility, 
> especially in the context of graph-like datasets. This is especially true 
> when combined with some kind of algebra for unioning/intersecting/etc. I'm 
> also interested in this sort of thing for programmable user-interface use 
> cases: Think text editors with multiple-cursors.
>
> I think experimentation is in order
>>
>
> Agreed. Here's some starting points for pre-hammock reading/viewing 
> materials:
>
> *Tree Traversal *
>
>- XPath: https://www.w3.org/TR/xpath/
>- CSS: https://www.w3.org/TR/css3-selectors/
>
> *Richer Tree Querying*
>
>- XQuery: https://www.w3.org/TR/xquery/
>- jQuery: https://api.jquery.com
>
> *Second-Class "Generalized References" (nee "L-values")*
>
>- Common Lisp: 
>http://www.lispworks.com/documentation/lw50/CLHS/Body/05_a.htm
>- C/C++: 
>
> http://eli.thegreenplace.net/2011/12/15/understanding-lvalues-and-rvalues-in-c-and-c
>
> *Lenses in Other Languages*
>
>- Haskell: 
>
> https://skillsmatter.com/skillscasts/4251-lenses-compositional-data-access-and-manipulation
>  
>(great overview of key concepts!)
>- Racket: https://docs.racket-lang.org/lens/index.html
>
> *Graph Querying*
>
>- Neo4j Cypher: https://neo4j.com/developer/cypher-query-language/
>- TinkerPop Gremlin: https://tinkerpop.apache.org/gremlin.html
>
>

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

Re: Navigators and lenses

[Gregg Reynolds]

On Mar 8, 2017 5:44 PM, "Edwin Watkeys"  wrote:

Hey,

The recent heat about Specter got me thinking. There's legitimate pain that
Spectre solves: Responsible adults sometimes needs to access and modify
deeply nested data structures, and Clojure's batteries-included facilities
for doing so can be tedious. But Specter is deeply un-Clojure-y, and, more
to the point, I would say Nathan is basically Bizzaro-Rich.*

There has to be some Clojure-idiomatic ways of solving the common problems
we confront, and I believe that one of the things we need to do to help
discover those approaches, I think experimentation is in order. My
contribution, my attempt, my essay to that end is cli-lens, available here:
. Here's the example usage, from the
README:

(require '[clj-lens.core :as lens])

(def m {:a 0, :b 1, :c [41 "Foocar"]})

(lens/get m [:c 1])
;; => "Foocar"


What happens if m is a tree with many :c keys? (fwiw i know almost nothing
of lenses, altho i once tried and failed to grok the concept.)

I totally agree that much more experimentation is in order. Specter is
great, but it's just one of many ways of solving the problem.

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.

Re: Navigators and lenses

[Brandon Bloom]

>
> Responsible adults sometimes needs to access and modify deeply nested data 
> structures


So far, my experience has been that it is almost always better to build a 
pair of flattening and unflattening transforms on the data. Especially 
since you frequently want only one flattening, but potentially many 
un-flattenings. The "unflattened" form (aka "documents") is usually an 
end-point where data goes to die; assuming it isn't immediately displayed 
on the screen.

However, having said that, path-dependent / context-sensitive query is a 
very rich and interesting space that does have meaningful utility, 
especially in the context of graph-like datasets. This is especially true 
when combined with some kind of algebra for unioning/intersecting/etc. I'm 
also interested in this sort of thing for programmable user-interface use 
cases: Think text editors with multiple-cursors.

I think experimentation is in order
>

Agreed. Here's some starting points for pre-hammock reading/viewing 
materials:

*Tree  Traversal  *

   - XPath: https://www.w3.org/TR/xpath/
   - CSS: https://www.w3.org/TR/css3-selectors/

*Richer Tree Querying*

   - XQuery: https://www.w3.org/TR/xquery/
   - jQuery: https://api.jquery.com

*Second-Class "Generalized References" (nee "L-values")*

   - Common Lisp: 
   http://www.lispworks.com/documentation/lw50/CLHS/Body/05_a.htm
   - C/C++: 
   
http://eli.thegreenplace.net/2011/12/15/understanding-lvalues-and-rvalues-in-c-and-c

*Lenses in Other Languages*

   - Haskell: 
   
https://skillsmatter.com/skillscasts/4251-lenses-compositional-data-access-and-manipulation
 
   (great overview of key concepts!)
   - Racket: https://docs.racket-lang.org/lens/index.html

*Graph Querying*

   - Neo4j Cypher: https://neo4j.com/developer/cypher-query-language/
   - TinkerPop Gremlin: https://tinkerpop.apache.org/gremlin.html

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