Nesting semantics for the thread last operator

2016-03-19 Thread Arun Sharma
=> (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/1737

Re: Nesting semantics for the thread last operator

2016-03-19 Thread 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)) (->>

Re: Nesting semantics for the thread last operator

2016-03-21 Thread 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

Re: Nesting semantics for the thread last operator

2016-03-21 Thread 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

Re: Nesting semantics for the thread last operator

2016-03-30 Thread 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 (un