Re: Nesting semantics for the thread last operator

[Arun Sharma]

On Monday, March 21, 2016 at 5:33:36 PM UTC-7, James Reeves wrote:
>
>  
>
>> The question I was asking is: does anyone rely on the current behavior? 
>> For people adapting this syntax for a query language, it's appealing to 
>> write:
>>
>> a->b()->c()
>>->union(d->e()->f())
>>
>> and get (union (c (b a) (f (e d)))
>>
>
> That's what:
>
> (-> a b c (union (-> d e f)))
>
> expands to.
>
> - James
>

Thanks. That works great for union and intersection, although I prefer 
threadLast over threadFirst for other reasons.

The thing that motivated this line of thought is that we have some 
primitives that read from right to left and unlike union/intersection are 
order sensitive.

(apply q2 q1)

means for each result of q1, run q2 and return the results.

For q1 = a->b()->c() and q2 = d->e()->f(), I'm trying to find an 
acceptable/natural thread last syntax.

user=> (clojure.walk/macroexpand-all '(->> a b c (->> d e f (apply

(c (b a) (apply (f (e d

Is there a way we could end up with

(apply (f (e d)) (c (b a)))

 -Arun

-- 
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: Nesting semantics for the thread last operator

[James Reeves]

On 21 March 2016 at 23:47, Arun Sharma  wrote:

> On Saturday, March 19, 2016 at 5:35:02 PM UTC-7, red...@gmail.com wrote:
>>
>> ->> is a mechanical transformation taking a form (->> x (a ... w))
>> turning it into (a ... w x), and this same mechanical transformation is
>> in place when nested. You example expands in steps like:
>> [..]
>>
>> you can see each step in the expansion results come from applying the
>> exact same transformation (this transformation is exactly the ->>
>> macro). this is the natural result of a recursive style of definition.
>> While it is technically possible to change the behavior to what you are
>> suggesting, but it would require special casing ->> and any derivative
>> of ->>.
>>
>
> Isn't it a function of how the recursive step is written?
>

No, it's a result of how macros are evaluated. Consider:

user=> (macroexpand-1 '(->> a b c (x d e f)))
(x d e f (c (b a)))

If that makes sense, then just replace "x" with "->>":

user=> (macroexpand-1 '(->> a b c (->> d e f)))
(->> d e f (c (b a)))
user=> (macroexpand-1 '(->> d e f (c (b a
(c (b a) (f (e d)))



> The question I was asking is: does anyone rely on the current behavior?
> For people adapting this syntax for a query language, it's appealing to
> write:
>
> a->b()->c()
>->union(d->e()->f())
>
> and get (union (c (b a) (f (e d)))
>

That's what:

(-> a b c (union (-> d e f)))

expands to.

- James

-- 
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: Nesting semantics for the thread last operator

[Arun Sharma]

On Saturday, March 19, 2016 at 5:35:02 PM UTC-7, red...@gmail.com wrote:
>
> They are a logical consequence of the machine. 
>
> ->> is a mechanical transformation taking a form (->> x (a ... w)) 
> turning it into (a ... w x), and this same mechanical transformation is 
> in place when nested. You example expands in steps like: 
> [..]
>
> you can see each step in the expansion results come from applying the 
> exact same transformation (this transformation is exactly the ->> 
> macro). this is the natural result of a recursive style of definition. 
> While it is technically possible to change the behavior to what you are 
> suggesting, but it would require special casing ->> and any derivative 
> of ->>. 
>

Isn't it a function of how the recursive step is written?
 

> So we could have something that always works the same uniform way, or we 
> could have am ever growing list of special cases. 
>

The question I was asking is: does anyone rely on the current behavior? For 
people adapting this syntax for a query language, it's appealing to write:

a->b()->c()
   ->union(d->e()->f())

and get (union (c (b a) (f (e d)))

I was hoping to achieve something similar via:

(->> a b c (->> d e f union))

We could have one uniform way without special casing if no one is relying 
on the current nesting semantics.

 -Arun

-- 
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: Nesting semantics for the thread last operator

[Kevin Downey]

They are a logical consequence of the machine.

->> is a mechanical transformation taking a form (->> x (a ... w))
turning it into (a ... w x), and this same mechanical transformation is
in place when nested. You example expands in steps like:

(->> a b c (->> d e f))
(->> (b a) c (->> d e f))
(->> (c (b a)) (->> d e f))
(->> d e f (c (b a)))
(->> (e d) f (c (b a)))
(->> (f (e d)) (c (b a)))
(c (b a) (f (e d)))

you can see each step in the expansion results come from applying the
exact same transformation (this transformation is exactly the ->>
macro). this is the natural result of a recursive style of definition.
While it is technically possible to change the behavior to what you are
suggesting, but it would require special casing ->> and any derivative
of ->>.

So we could have something that always works the same uniform way, or we
could have am ever growing list of special cases.

On 03/19/2016 04:57 PM, Arun Sharma wrote:
> => (clojure.walk/macroexpand-all '(->> a b c (->> d e f)))
> (c (b a) (f (e d)))
> 
> I was hoping that it would return
> 
> (f (e d) (c (b a)))
> 
> Can someone here explain the rationale for the current semantics?
> 
> Context: some of the queries towards the end of this post.
> 
> https://code.facebook.com/posts/1737605303120405/dragon-a-distributed-graph-query-engine/
> 
>  -Arun
> 
> -- 
> 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.


-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

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