Re: Generalizing -> and ->> forms

On Fri, Aug 28, 2015 at 11:51 PM, Alan Thompson wrote: > I have become very partial to a simple adaptation of as-> from the Tupelo > Core library. I almost always like > to be explicit about the location the previous value, since either -> or > ->> can someti

Re: Generalizing -> and ->> forms

The parameter order of as-> makes it convenient to use *inside *-> so you can name the threaded parameter only where it needs naming: (-> "UFOT" (reverse) (->> (apply str)) (string/lower-case) (as-> x (string/replace "slip on a tofu" x "banana peel"))) On Friday, August 28,

Re: Generalizing -> and ->> forms

I have become very partial to a simple adaptation of as-> from the Tupelo Core library. I almost always like to be explicit about the location the previous value, since either -> or ->> can sometimes be difficult if the threading forms don't always want the arg

Re: Generalizing -> and ->> forms

​Good one! On Fri, Aug 28, 2015 at 6:34 PM, Moe Aboulkheir wrote: > The function is actually shorter without cond->: (conj (if first? args > (vec args)) x) -- Akhil Wali # https://github.com/darth10 # https://darth10.github.io -- You received this message because you are subscribed to t

Re: Generalizing -> and ->> forms

The function is actually shorter without cond->: (conj (if first? args (vec args)) x) Take care, Moe On Fri, Aug 28, 2015 at 1:59 PM, Akhil Wali wrote: > That's pretty neat! > But then -> will be implemented using cond->, which is slightly off. > > On Friday, August 28, 2015 at 6:07:46 PM UTC+5

Re: Generalizing -> and ->> forms

That's pretty neat! But then -> will be implemented using cond->, which is slightly off. On Friday, August 28, 2015 at 6:07:46 PM UTC+5:30, Moe Aboulkheir wrote: > > On Fri, Aug 28, 2015 at 12:37 PM, Akhil Wali > wrote: > >> >> This does work, but it's a bit of whammy. >> Anyone with suggestions

Re: Generalizing -> and ->> forms

On Fri, Aug 28, 2015 at 12:37 PM, Akhil Wali wrote: > > This does work, but it's a bit of whammy. > Anyone with suggestions for improvement? > I went over this quickly, though it seems to work OK: (defn threading [x first? forms] (reduce (fn [x form] (if (seq? form) (let [[op &

Re: Generalizing -> and ->> forms

> > It doesn't appear to work for simple cases (where the expressions > aren't function calls w/ additional arguments), e.g. (-> 1 inc) Thanks for that one. How silly of me :P Here's a better version of threading. (defmacro threading [a b x forms] (loop [x x forms forms] (if fo

Re: Generalizing -> and ->> forms

​On Fri, Aug 28, 2015 at 5:33 PM, Atamert Ölçgen wrote: > Also, you know about as->, don't you? ​Well, I'm aware of all other threading forms like some->, as->, etc. This is just something I'm trying ​with -> and ->>, and thought I'd discuss. Perhaps the definition of as-> can be used as a be

Re: Generalizing -> and ->> forms

Hi, threading doesn't need to be a macro. In fact it would be easier to test if it's just a function. Also, you know about as->, don't you? On Fri, Aug 28, 2015 at 2:37 PM, Akhil Wali wrote: > I've been trying to refactor the -> and ->> forms to use a common macro > form. > Ended up with this

Re: Generalizing -> and ->> forms

On Fri, Aug 28, 2015 at 12:37 PM, Akhil Wali wrote: > This does work, but it's a bit of whammy. > Anyone with suggestions for improvement? It doesn't appear to work for simple cases (where the expressions aren't function calls w/ additional arguments), e.g. (-> 1 inc) Take care, Moe -- You re

Generalizing -> and ->> forms

I've been trying to refactor the -> and ->> forms to use a common macro form. Ended up with this. (defmacro threading [a b x forms] (loop [x x forms forms] (if forms (let [form (first forms) f (first form) r (rest form) threaded (if (seq? f