Re: macro help

[Colin Yates]

I’m kicking myself as I have exactly that book but it got lost in the ‘TODO’ 
pile.

> On 2 Oct 2015, at 13:31, Jason Stewart  wrote:
> 
> "Mastering Clojure Macros" by Colin Jones gets my vote as the go to book for 
> writing clojure macros.
> 
> 
> On Fri, Oct 2, 2015 at 8:24 AM, Colin Yates  > wrote:
> Thanks for your comments - very helpful!
> 
> The reference to destructuring might be irrelevant now. Previously I noticed 
> that the _map construction_ was emitted from the macro rather than the symbol 
> bound to the map. For example, some variation of quoting meant (defmacro a 
> [m] (println m)) called with (a {:1 1}) emitted (println {:1 1}) rather than 
> (println m). Now I think about it is because an earlier iteration of the 
> macro used ~m - I’m not at the desk so I can’t confirm.
> 
> Any pointers a decent Clojure macro book? I found lots of blogs around from 
> google but not a single one of them mentioned the (let [m-state (gensym)] 
> `(let [~m-state ~state])) ‘trick’.
> 
> Thanks again.
> 
>> On 2 Oct 2015, at 10:50, gianluca torta > > wrote:
>> 
>> Hi Colin,
>> 
>> as far as I can tell, your solution looks fine... here are a couple of 
>> comments on your step-by-step analysis
>> 
>> cheers,
>> Gianluca
>> 
>> 
>> 1(defmacro form [state & elements]
>> 2  (let [m-state (gensym)]
>> 3`(let [~m-state ~state]
>> 4   [:div.form.horizontal
>> 5~@(map (fn [[f m & rest]]
>> 6 `[~f (assoc ~m
>> 7 :value (get @(:values ~m-state) (:id ~m))
>> 8 :on-change #(swap! (:values ~m-state) assoc 
>> (:id ~m) "UPDATED"))
>> 9   ~@rest])
>> 10   elements)])))
>> 
>> 0 - ` means "emit, don't evaluate", ~@ means "splice, e.g. remove the outer 
>> sequence so [a ~@[1 2]] becomes [a 1 2] and ' means 'the symbol of rather 
>> than the value of'.
>> ~@ means "evaluate and splice", i.e., it overrides the "don't evaluate" of ` 
>> and splices the result in the outer sequence
>> ~ means just "evaluate" without the splicing
>>  
>> 2 - declare m-state, which is lexically scoped to the macro and is bound to 
>> a random identifier created by gensym
>> 3 - the back-tick (syntax-quote) returns the form rather than evaluating the 
>> form, so the macro will return (let* [m-8_324230_ ]) The [~m-state 
>> ~state] is just bewildering though.
>> 3 - in addition, the 'state' argument appears to be destructured, but only 
>> to one level so if the state contains an atom it is the var of the atom
>> 'state' is evaluated due to ~, not sure what you mean by 'destructured, but 
>> only to one level'
>>  
>> 4 - literal text emitted in-line
>> 5 - splice the results of the map (i.e. rather than [:div.form.horizontal 
>> [child1 child2]] return [:div.form.horizontal child1 child2])
>> 5 - also destructure each element assuming [f m(ap) and 0 or more other args]
>> yes, the destructuring is just a normal destructuring of the args passed to 
>> the fn by map
>>  
>> 6 - emit [ where  is the first symbol, 'f' l in each element. Also 
>> prevent this being evaluated in the macro with the syntax-quote as (5) has 
>> introduced some new scope because of the ~@ - not sure.
>> as said above, rather than introducing a new scope, ~@ just overrides the 
>> "don't evaluate" of back-tick
>>  
>> 6 - also associate onto the symbol m (which is assumed to be associative, 
>> e.g. a map)...
>> 7/8 - extract data out of the 'run-time' (e.g. not macro-time) value of the 
>> provided state (magically captured under ~m-state)
>> 9 - splice in the rest of the arguments, if any, that were part of the 
>> element
>> 10 - and do that magic for each element
>>  
>> 
>> -- 
>> 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 
> 

Re: macro help

[Thomas Heller]

Well, if you don't like that 'form' you could use a binding.

(binding [form/*state*
  {:editing? true
:values form-values
:validation validation-report
:on-change handle-form-change}]
  (form/tag 
(form/text :name)
(form/number :age)))

Anyways, I would not recommend using the binding but doesn't mean you can't.

I can't quite imagine what your future plans look like but you probably 
won't need a macro. ;)

cheers,
/thomas

On Friday, October 2, 2015 at 3:34:48 PM UTC+2, Colin Yates wrote:
>
> Hi Thomas - yes, you are right. The example I provided is all pain/no-gain 
> in terms of macros. However, future plans will require manipulating the 
> invocation of (for example form/text and form/number) before they are 
> evaluated.
>
> Having said all of that, that repeated ‘form’ does bug me a bit :-). I do 
> absolutely agree that the cognitive overhead of the macro isn’t justified 
> here.
>
> On 2 Oct 2015, at 14:29, Thomas Heller  
> wrote:
>
> Have you tried NOT using a macro at all? This code does not need to be a 
> macro at all if you ask me.
>
> Just a little sketch but things could look just about the same without any 
> macros at all:
>
> (let [form {:editing? true
> :values form-values
> :validation validation-report
> :on-change handle-form-change}]
>   (form/tag form
> (form/text form :name)
> (form/number form :age)))
>
>
> ;; in-ns 'form
>
> (defn text [form field]
>   [text-component {:id field
>:value (get-in form [:values field])
>...}])
>
> (defn tag
>   [{:keys [editing?] :as form} & children]
>   (into [:div.form.horizontal
>  {:class (if editing? "editing" "editable")}]
> children))
>
>
> Use macros very sparingly, most of the time data and functions are just 
> better.
>
> Just my 2 cents,
> /thomas
>
> On Wednesday, September 30, 2015 at 10:29:30 PM UTC+2, Colin Yates wrote:
>>
>> Hi all,
>>
>> I am banging my head against the wall - I think it is obvious but I have 
>> started too long:
>>
>> The use-case is that I want a form which takes a set of children. The 
>> form also takes in some form-wide state, like the form-wide validation, the 
>> values for each item etc. I want the macro, for each child, to decorate 
>> that child by extracting the validation errors and value from the form-wide 
>> state.
>>
>> So, assuming:
>>  - validation looks like {:name "Duplicate name" :age "You must be at 
>> least 0"}
>>  - form-values looks like {:name "a-duplicate-user" :age -1}
>>
>> then my form might look like:
>>
>> (form {:editing? true :values form-values :validation validation-report 
>> :on-change handle-form-change}
>>   [form/text {:id :name}]
>>   [form/number {:id :age}])
>>
>> After the macro I want the following code:
>>
>> [:div.form.horizontal
>>   {:class "editing"}
>>   [form/text {:id :name :value "a-duplicate-user" :errors "Duplicate 
>> name" :on-click (fn [e] (handle-form-change :name (-> e .target .value])]
>>   [form/number {:id :age :value "-1" :errors "You must be at least 0" 
>> :on-click (fn [e] (handle-form-change :age (-> e .target .value))]]
>>
>> However, ideally the macro would _not_ emit the contents of the input as 
>> literals but would emit code that inspects the provided parameters at 
>> run-time (i.e. rather than :value "a-duplicate-user" I would much prefer 
>> :value (-> state values :name) as that will allow me to pass in an atom for 
>> example.
>>
>> I have tried so many variations and evaluating the state (e.g. (:editing? 
>> state)) works fine as the emitted code has the destructured values, but 
>> that doesn't work for an atom.
>>
>> Here is my attempt at trying to emit code that interrogates the provided 
>> parameter.
>>
>> (defmacro form [state & elements]
>>   (let [state# state]
>> `[:div.form.horizontal
>>   {:class (if (:editing? state#) "editing" "editable")}
>>   ~@(map (fn [[_ {:keys [id]} :as child]]
>>(update child 1 assoc
>>:editing? (:editing? state#)
>>:value `(-> (:values state#) 'deref (get ~id))
>>:on-change `(fn [e#]
>>  (js/console.log "E: " 
>> (cljs.core/clj->js e#))
>>  ((:on-change state#) ~id (-> e# 
>> .-target .-value)
>>  elements)]))
>>
>> The error I am getting is that there is such var as the gen-sym's state# 
>> in the namespace.
>>
>> The generic thing I am trying to do is remove the boilerplate from each 
>> of the items in the form.
>>
>> Any and all suggestions are welcome. 
>>
>> Thanks!
>>
>
> -- 
> 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 

Re: macro help

[Colin Yates]

Hi Thomas, binding - really? :-). Apart from the general negative reaction they 
seem to have, I don’t want the individual elements (e.g. text and number) to 
assume rely on the binding as they can be called individually as well and the 
binding would just get in the way.

My understanding is that if I want to change a call to a function _before_ that 
call happens then my only option is to use a macro?

(I also realise this use-case will never need a macro as hiccup very sensibly 
uses data so the thing passed to (form) is simply a vector.)

I am saying, the discussion of whether _this example_ justifies a macro is mute 
- I agree it doesn’t.

> On 2 Oct 2015, at 15:01, Thomas Heller  wrote:
> 
> Well, if you don't like that 'form' you could use a binding.
> 
> (binding [form/*state*
>   {:editing? true
> :values form-values
> :validation validation-report
> :on-change handle-form-change}]
>   (form/tag 
> (form/text :name)
> (form/number :age)))
> 
> Anyways, I would not recommend using the binding but doesn't mean you can't.
> 
> I can't quite imagine what your future plans look like but you probably won't 
> need a macro. ;)
> 
> cheers,
> /thomas
> 
> On Friday, October 2, 2015 at 3:34:48 PM UTC+2, Colin Yates wrote:
> Hi Thomas - yes, you are right. The example I provided is all pain/no-gain in 
> terms of macros. However, future plans will require manipulating the 
> invocation of (for example form/text and form/number) before they are 
> evaluated.
> 
> Having said all of that, that repeated ‘form’ does bug me a bit :-). I do 
> absolutely agree that the cognitive overhead of the macro isn’t justified 
> here.
> 
>> On 2 Oct 2015, at 14:29, Thomas Heller gmail.com 
>> > wrote:
>> 
>> Have you tried NOT using a macro at all? This code does not need to be a 
>> macro at all if you ask me.
>> 
>> Just a little sketch but things could look just about the same without any 
>> macros at all:
>> 
>> (let [form {:editing? true
>> :values form-values
>> :validation validation-report
>> :on-change handle-form-change}]
>>   (form/tag form
>> (form/text form :name)
>> (form/number form :age)))
>> 
>> 
>> ;; in-ns 'form
>> 
>> (defn text [form field]
>>   [text-component {:id field
>>:value (get-in form [:values field])
>>...}])
>> 
>> (defn tag
>>   [{:keys [editing?] :as form} & children]
>>   (into [:div.form.horizontal
>>  {:class (if editing? "editing" "editable")}]
>> children))
>> 
>> 
>> Use macros very sparingly, most of the time data and functions are just 
>> better.
>> 
>> Just my 2 cents,
>> /thomas
>> 
>> On Wednesday, September 30, 2015 at 10:29:30 PM UTC+2, Colin Yates wrote:
>> Hi all,
>> 
>> I am banging my head against the wall - I think it is obvious but I have 
>> started too long:
>> 
>> The use-case is that I want a form which takes a set of children. The form 
>> also takes in some form-wide state, like the form-wide validation, the 
>> values for each item etc. I want the macro, for each child, to decorate that 
>> child by extracting the validation errors and value from the form-wide state.
>> 
>> So, assuming:
>>  - validation looks like {:name "Duplicate name" :age "You must be at least 
>> 0"}
>>  - form-values looks like {:name "a-duplicate-user" :age -1}
>> 
>> then my form might look like:
>> 
>> (form {:editing? true :values form-values :validation validation-report 
>> :on-change handle-form-change}
>>   [form/text {:id :name}]
>>   [form/number {:id :age}])
>> 
>> After the macro I want the following code:
>> 
>> [:div.form.horizontal
>>   {:class "editing"}
>>   [form/text {:id :name :value "a-duplicate-user" :errors "Duplicate name" 
>> :on-click (fn [e] (handle-form-change :name (-> e .target .value])]
>>   [form/number {:id :age :value "-1" :errors "You must be at least 0" 
>> :on-click (fn [e] (handle-form-change :age (-> e .target .value))]]
>> 
>> However, ideally the macro would _not_ emit the contents of the input as 
>> literals but would emit code that inspects the provided parameters at 
>> run-time (i.e. rather than :value "a-duplicate-user" I would much prefer 
>> :value (-> state values :name) as that will allow me to pass in an atom for 
>> example.
>> 
>> I have tried so many variations and evaluating the state (e.g. (:editing? 
>> state)) works fine as the emitted code has the destructured values, but that 
>> doesn't work for an atom.
>> 
>> Here is my attempt at trying to emit code that interrogates the provided 
>> parameter.
>> 
>> (defmacro form [state & elements]
>>   (let [state# state]
>> `[:div.form.horizontal
>>   {:class (if (:editing? state#) "editing" "editable")}
>>   ~@(map (fn [[_ {:keys [id]} :as child]]
>>(update child 1 assoc
>>:editing? (:editing? state#)
>>:value 

Re: macro help

[Colin Yates]

Hi Thomas - yes, you are right. The example I provided is all pain/no-gain in 
terms of macros. However, future plans will require manipulating the invocation 
of (for example form/text and form/number) before they are evaluated.

Having said all of that, that repeated ‘form’ does bug me a bit :-). I do 
absolutely agree that the cognitive overhead of the macro isn’t justified here.

> On 2 Oct 2015, at 14:29, Thomas Heller  wrote:
> 
> Have you tried NOT using a macro at all? This code does not need to be a 
> macro at all if you ask me.
> 
> Just a little sketch but things could look just about the same without any 
> macros at all:
> 
> (let [form {:editing? true
> :values form-values
> :validation validation-report
> :on-change handle-form-change}]
>   (form/tag form
> (form/text form :name)
> (form/number form :age)))
> 
> 
> ;; in-ns 'form
> 
> (defn text [form field]
>   [text-component {:id field
>:value (get-in form [:values field])
>...}])
> 
> (defn tag
>   [{:keys [editing?] :as form} & children]
>   (into [:div.form.horizontal
>  {:class (if editing? "editing" "editable")}]
> children))
> 
> 
> Use macros very sparingly, most of the time data and functions are just 
> better.
> 
> Just my 2 cents,
> /thomas
> 
> On Wednesday, September 30, 2015 at 10:29:30 PM UTC+2, Colin Yates wrote:
> Hi all,
> 
> I am banging my head against the wall - I think it is obvious but I have 
> started too long:
> 
> The use-case is that I want a form which takes a set of children. The form 
> also takes in some form-wide state, like the form-wide validation, the values 
> for each item etc. I want the macro, for each child, to decorate that child 
> by extracting the validation errors and value from the form-wide state.
> 
> So, assuming:
>  - validation looks like {:name "Duplicate name" :age "You must be at least 
> 0"}
>  - form-values looks like {:name "a-duplicate-user" :age -1}
> 
> then my form might look like:
> 
> (form {:editing? true :values form-values :validation validation-report 
> :on-change handle-form-change}
>   [form/text {:id :name}]
>   [form/number {:id :age}])
> 
> After the macro I want the following code:
> 
> [:div.form.horizontal
>   {:class "editing"}
>   [form/text {:id :name :value "a-duplicate-user" :errors "Duplicate name" 
> :on-click (fn [e] (handle-form-change :name (-> e .target .value])]
>   [form/number {:id :age :value "-1" :errors "You must be at least 0" 
> :on-click (fn [e] (handle-form-change :age (-> e .target .value))]]
> 
> However, ideally the macro would _not_ emit the contents of the input as 
> literals but would emit code that inspects the provided parameters at 
> run-time (i.e. rather than :value "a-duplicate-user" I would much prefer 
> :value (-> state values :name) as that will allow me to pass in an atom for 
> example.
> 
> I have tried so many variations and evaluating the state (e.g. (:editing? 
> state)) works fine as the emitted code has the destructured values, but that 
> doesn't work for an atom.
> 
> Here is my attempt at trying to emit code that interrogates the provided 
> parameter.
> 
> (defmacro form [state & elements]
>   (let [state# state]
> `[:div.form.horizontal
>   {:class (if (:editing? state#) "editing" "editable")}
>   ~@(map (fn [[_ {:keys [id]} :as child]]
>(update child 1 assoc
>:editing? (:editing? state#)
>:value `(-> (:values state#) 'deref (get ~id))
>:on-change `(fn [e#]
>  (js/console.log "E: " (cljs.core/clj->js 
> e#))
>  ((:on-change state#) ~id (-> e# .-target 
> .-value)
>  elements)]))
> 
> The error I am getting is that there is such var as the gen-sym's state# in 
> the namespace.
> 
> The generic thing I am trying to do is remove the boilerplate from each of 
> the items in the form.
> 
> Any and all suggestions are welcome. 
> 
> 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 
> .

-- 
You received this 

Re: clojure.repl/doc - change request - print vs return-value

[Alex Miller]

What would you do with doc-fn?

I think this is a reasonable enhancement request but backing it up with a 
use case would help a lot (presuming you wanted to file a jira).

On Thursday, October 1, 2015 at 5:58:26 AM UTC-4, Terje Dahl wrote:
>
> Would it be possible to "break out" the functionality of the function 
> "doc" into a second function named i.e. "doc-fn" - much as has been done 
> with dir vs dir-fn?
>
> doc prints to *out* just like dir does.
> But dir-fn allows me to parse the output and use it as I need.
> I would like the same for doc(-fn)
>
> Right now I have simply duplicated special-doc-map, special-doc, and doc 
> into my own code, and simply replaced "print-doc" with "identity".
>
>

-- 
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: No recent activity for core.async?

[Alex Miller]

I talked to Rich yesterday and we expect to remove the alpha in the next 
version, fyi.


On Wednesday, September 30, 2015 at 10:39:17 PM UTC-4, Rangel Spasov wrote:
>
> We've been using the library very actively from both Clojure and 
> ClojureScript and have no problems with it - no reasons to worry about the 
> alpha label I think :).
>
>
> On Saturday, September 26, 2015 at 2:49:22 AM UTC-7, Rafik NACCACHE wrote:
>>
>> core.async didn't move since more than a year.
>>
>> Is any new release coming soon? I actually use this library intensively, 
>> and the fact it is staying alpha for more than a year starts giving me some 
>> shivers :)
>>
>> Thank you for any updates !!
>>
>

-- 
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: Towards Greater Code Reuse

[Frank Castellucci]

Reuse is a matter of perspective.

During the OO marketing blitz of the 90's, promise of re-use (C++, etc etc) 
convinced many to jump in the pool. So today there is a tremendous amount 
of abstract and deep hierarchies build with the notions that: "Someday this 
may be useful to specialize from this Class thereby enabling 're-use'" ... 
*BS 
There is much more code that does NOTHING in the hierarchy other than 
putting a drag on the timeliness of delivery.*

True reuse emerged at the macro level (i.e.Module orientation, 
Re-provisionable services, Web Services, etc.) while the micro level 
adventure leaving bloated unmaintainable artifacts in  it's wake.

The fundamental essence of functional approach has done more for reuse at 
the micro level then all OO languages combined. IMHO.

Off peanut gallery soap-box
Frank 

On Thursday, October 1, 2015 at 9:14:34 AM UTC-4, William la Forge wrote:
>
> Code reuse is for me the holy grail of software. It is something we lost 
> in large measure with the adoption of top-down development. And OO has only 
> complicated the matter. For some time now I have advocated the use of 
> factories and interfaces as a means of decoupling, but writing reusable 
> code has continued to be a bit of a lost art. But then, I was a Java 
> developer.
>
>
> Having been exposed to Clojure, I've come to realize that a function is 
> the smallest unit of reusable code, not a class. Simply moving logic from 
> methods to functions (or to static methods, if you are still using Java) 
> opens up a lot of possibilities. Mind, I still advocate the use of 
> interfaces for method polymorphism, but limit method bodies to be little 
> more than a call to a function or a property accessor.
>
>
> Doing this allows us to avoid class extensions and mind-numbing class 
> hierarchies. The code becomes much clearer, defining new classes becomes 
> much easier, and the need to refactor the code is greatly diminished. And 
> writing reusable functions is much easier than writing reusable classes.
>
>
> from https://github.com/laforge49/aatree/wiki/Towards-Greater-Code-Reuse
>

-- 
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: macro help

[Thomas Heller]

Have you tried NOT using a macro at all? This code does not need to be a 
macro at all if you ask me.

Just a little sketch but things could look just about the same without any 
macros at all:

(let [form {:editing? true
:values form-values
:validation validation-report
:on-change handle-form-change}]
  (form/tag form
(form/text form :name)
(form/number form :age)))


;; in-ns 'form

(defn text [form field]
  [text-component {:id field
   :value (get-in form [:values field])
   ...}])

(defn tag
  [{:keys [editing?] :as form} & children]
  (into [:div.form.horizontal
 {:class (if editing? "editing" "editable")}]
children))


Use macros very sparingly, most of the time data and functions are just 
better.

Just my 2 cents,
/thomas

On Wednesday, September 30, 2015 at 10:29:30 PM UTC+2, Colin Yates wrote:
>
> Hi all,
>
> I am banging my head against the wall - I think it is obvious but I have 
> started too long:
>
> The use-case is that I want a form which takes a set of children. The form 
> also takes in some form-wide state, like the form-wide validation, the 
> values for each item etc. I want the macro, for each child, to decorate 
> that child by extracting the validation errors and value from the form-wide 
> state.
>
> So, assuming:
>  - validation looks like {:name "Duplicate name" :age "You must be at 
> least 0"}
>  - form-values looks like {:name "a-duplicate-user" :age -1}
>
> then my form might look like:
>
> (form {:editing? true :values form-values :validation validation-report 
> :on-change handle-form-change}
>   [form/text {:id :name}]
>   [form/number {:id :age}])
>
> After the macro I want the following code:
>
> [:div.form.horizontal
>   {:class "editing"}
>   [form/text {:id :name :value "a-duplicate-user" :errors "Duplicate name" 
> :on-click (fn [e] (handle-form-change :name (-> e .target .value])]
>   [form/number {:id :age :value "-1" :errors "You must be at least 0" 
> :on-click (fn [e] (handle-form-change :age (-> e .target .value))]]
>
> However, ideally the macro would _not_ emit the contents of the input as 
> literals but would emit code that inspects the provided parameters at 
> run-time (i.e. rather than :value "a-duplicate-user" I would much prefer 
> :value (-> state values :name) as that will allow me to pass in an atom for 
> example.
>
> I have tried so many variations and evaluating the state (e.g. (:editing? 
> state)) works fine as the emitted code has the destructured values, but 
> that doesn't work for an atom.
>
> Here is my attempt at trying to emit code that interrogates the provided 
> parameter.
>
> (defmacro form [state & elements]
>   (let [state# state]
> `[:div.form.horizontal
>   {:class (if (:editing? state#) "editing" "editable")}
>   ~@(map (fn [[_ {:keys [id]} :as child]]
>(update child 1 assoc
>:editing? (:editing? state#)
>:value `(-> (:values state#) 'deref (get ~id))
>:on-change `(fn [e#]
>  (js/console.log "E: " 
> (cljs.core/clj->js e#))
>  ((:on-change state#) ~id (-> e# 
> .-target .-value)
>  elements)]))
>
> The error I am getting is that there is such var as the gen-sym's state# 
> in the namespace.
>
> The generic thing I am trying to do is remove the boilerplate from each of 
> the items in the form.
>
> Any and all suggestions are welcome. 
>
> 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: clojure 1.8 java.lang.VerifyError method: invokeStatic signature: Can only throw Throwable objects

[Alex Miller]

This should be fixed in the next alpha or beta.

On Thursday, October 1, 2015 at 7:04:58 AM UTC-4, Lars Rune Nøstdal wrote:
>
>
>
> On Thursday, October 1, 2015 at 12:59:39 PM UTC+2, Nicola Mometto wrote:
>>
>>
>> http://dev.clojure.org/jira/browse/CLJ-1809 
>>
>
> Awesome; thank you.
>

-- 
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: Towards Greater Code Reuse

[Colin Yates]

My 1.5 cents:
 - code re-use is easier in FP because of the common abstractions - sequences 
etc.
 - code re-use is easier in FP because of the separation of state and functions
 - knowledge learned from creating a piece of code is far more likely to be 
re-used than the code itself
 - refactoring for code re-use is often _the_ definition of early optimisation
 - code re-use will never take off because we are all hard-wired to build our 
own solution
 - service re-use - yep

 My soap-box just collapsed under the weight of my unfounded assertions so I’m 
out.

> On 2 Oct 2015, at 14:53, Frank Castellucci  wrote:
> 
> Reuse is a matter of perspective.
> 
> During the OO marketing blitz of the 90's, promise of re-use (C++, etc etc) 
> convinced many to jump in the pool. So today there is a tremendous amount of 
> abstract and deep hierarchies build with the notions that: "Someday this may 
> be useful to specialize from this Class thereby enabling 're-use'" ... BS 
> There is much more code that does NOTHING in the hierarchy other than putting 
> a drag on the timeliness of delivery.
> 
> True reuse emerged at the macro level (i.e.Module orientation, 
> Re-provisionable services, Web Services, etc.) while the micro level 
> adventure leaving bloated unmaintainable artifacts in  it's wake.
> 
> The fundamental essence of functional approach has done more for reuse at the 
> micro level then all OO languages combined. IMHO.
> 
> Off peanut gallery soap-box
> Frank 
> 
> On Thursday, October 1, 2015 at 9:14:34 AM UTC-4, William la Forge wrote:
> Code reuse is for me the holy grail of software. It is something we lost in 
> large measure with the adoption of top-down development. And OO has only 
> complicated the matter. For some time now I have advocated the use of 
> factories and interfaces as a means of decoupling, but writing reusable code 
> has continued to be a bit of a lost art. But then, I was a Java developer.
> 
> 
> 
> Having been exposed to Clojure, I've come to realize that a function is the 
> smallest unit of reusable code, not a class. Simply moving logic from methods 
> to functions (or to static methods, if you are still using Java) opens up a 
> lot of possibilities. Mind, I still advocate the use of interfaces for method 
> polymorphism, but limit method bodies to be little more than a call to a 
> function or a property accessor.
> 
> 
> 
> Doing this allows us to avoid class extensions and mind-numbing class 
> hierarchies. The code becomes much clearer, defining new classes becomes much 
> easier, and the need to refactor the code is greatly diminished. And writing 
> reusable functions is much easier than writing reusable classes.
> 
> 
> 
> from https://github.com/laforge49/aatree/wiki/Towards-Greater-Code-Reuse 
> 
> 
> -- 
> 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: prettier stacktraces?

[Daniel Kersten]

https://github.com/venantius/ultra is also worth a look (its basically a
wrapper plugin that uses aviso/pretty and others under the hood)

On Thu, 1 Oct 2015 at 21:52 Howard Lewis Ship  wrote:

> Without the plugin, I typically added the call to
> io.aviso.repl/install-pretty-exceptions in my user.clj, or in some other
> early-loading namespace.
>
> On Mon, Jun 1, 2015 at 11:57 AM, John Gabriele  wrote:
>
>> On Monday, June 1, 2015 at 2:31:46 PM UTC-4, nikolay.k...@gmail.com
>> wrote:
>>>
>>> I think this  is what you're
>>> looking for.
>>>
>>>
>> Intriguing.
>>
>> How can I get this to work automatically? I've got a project created via
>> `lein new app my-app`, and I want to see the pretty stacktrace when I run
>> the app via `lein run` and things blow up.
>>
>> I tried just adding `[io.aviso/pretty "0.1.18"]` to my project.clj's
>> :dependencies, but that doesn't change the stack trace output in my
>> terminal.
>>
>> 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.
>>
>
> --
> Howard M. Lewis Ship
>
> Starting with WalMart Labs on Sep 28th!
>
> Creator of Apache Tapestry
>
> (971) 678-5210
> http://howardlewisship.com
> @hlship
>
> --
> 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: macro help

[Colin Yates]

Thanks for your comments - very helpful!

The reference to destructuring might be irrelevant now. Previously I noticed 
that the _map construction_ was emitted from the macro rather than the symbol 
bound to the map. For example, some variation of quoting meant (defmacro a [m] 
(println m)) called with (a {:1 1}) emitted (println {:1 1}) rather than 
(println m). Now I think about it is because an earlier iteration of the macro 
used ~m - I’m not at the desk so I can’t confirm.

Any pointers a decent Clojure macro book? I found lots of blogs around from 
google but not a single one of them mentioned the (let [m-state (gensym)] `(let 
[~m-state ~state])) ‘trick’.

Thanks again.

> On 2 Oct 2015, at 10:50, gianluca torta  wrote:
> 
> Hi Colin,
> 
> as far as I can tell, your solution looks fine... here are a couple of 
> comments on your step-by-step analysis
> 
> cheers,
> Gianluca
> 
> 
> 1(defmacro form [state & elements]
> 2  (let [m-state (gensym)]
> 3`(let [~m-state ~state]
> 4   [:div.form.horizontal
> 5~@(map (fn [[f m & rest]]
> 6 `[~f (assoc ~m
> 7 :value (get @(:values ~m-state) (:id ~m))
> 8 :on-change #(swap! (:values ~m-state) assoc 
> (:id ~m) "UPDATED"))
> 9   ~@rest])
> 10   elements)])))
> 
> 0 - ` means "emit, don't evaluate", ~@ means "splice, e.g. remove the outer 
> sequence so [a ~@[1 2]] becomes [a 1 2] and ' means 'the symbol of rather 
> than the value of'.
> ~@ means "evaluate and splice", i.e., it overrides the "don't evaluate" of ` 
> and splices the result in the outer sequence
> ~ means just "evaluate" without the splicing
>  
> 2 - declare m-state, which is lexically scoped to the macro and is bound to a 
> random identifier created by gensym
> 3 - the back-tick (syntax-quote) returns the form rather than evaluating the 
> form, so the macro will return (let* [m-8_324230_ ]) The [~m-state 
> ~state] is just bewildering though.
> 3 - in addition, the 'state' argument appears to be destructured, but only to 
> one level so if the state contains an atom it is the var of the atom
> 'state' is evaluated due to ~, not sure what you mean by 'destructured, but 
> only to one level'
>  
> 4 - literal text emitted in-line
> 5 - splice the results of the map (i.e. rather than [:div.form.horizontal 
> [child1 child2]] return [:div.form.horizontal child1 child2])
> 5 - also destructure each element assuming [f m(ap) and 0 or more other args]
> yes, the destructuring is just a normal destructuring of the args passed to 
> the fn by map
>  
> 6 - emit [ where  is the first symbol, 'f' l in each element. Also 
> prevent this being evaluated in the macro with the syntax-quote as (5) has 
> introduced some new scope because of the ~@ - not sure.
> as said above, rather than introducing a new scope, ~@ just overrides the 
> "don't evaluate" of back-tick
>  
> 6 - also associate onto the symbol m (which is assumed to be associative, 
> e.g. a map)...
> 7/8 - extract data out of the 'run-time' (e.g. not macro-time) value of the 
> provided state (magically captured under ~m-state)
> 9 - splice in the rest of the arguments, if any, that were part of the element
> 10 - and do that magic for each element
>  
> 
> -- 
> 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: macro help

[gianluca torta]

Hi Colin,

as far as I can tell, your solution looks fine... here are a couple of 
comments on your step-by-step analysis

cheers,
Gianluca


1(defmacro form [state & elements]
> 2  (let [m-state (gensym)]
> 3`(let [~m-state ~state]
> 4   [:div.form.horizontal
> 5~@(map (fn [[f m & rest]]
> 6 `[~f (assoc ~m
> 7 :value (get @(:values ~m-state) (:id ~m))
> 8 :on-change #(swap! (:values ~m-state) assoc 
> (:id ~m) "UPDATED"))
> 9   ~@rest])
> 10   elements)])))
>
> 0 - ` means "emit, don't evaluate", ~@ means "splice, e.g. remove the 
> outer sequence so [a ~@[1 2]] becomes [a 1 2] and ' means 'the symbol of 
> rather than the value of'.
>
~@ means "evaluate and splice", i.e., it overrides the "don't evaluate" of 
` and splices the result in the outer sequence
~ means just "evaluate" without the splicing
 

> 2 - declare m-state, which is lexically scoped to the macro and is bound 
> to a random identifier created by gensym
> 3 - the back-tick (syntax-quote) returns the form rather than evaluating 
> the form, so the macro will return (let* [m-8_324230_ ]) The [~m-state 
> ~state] is just bewildering though.
> 3 - in addition, the 'state' argument appears to be destructured, but only 
> to one level so if the state contains an atom it is the var of the atom
>
'state' is evaluated due to ~, not sure what you mean by 'destructured, but 
only to one level'
 

> 4 - literal text emitted in-line
> 5 - splice the results of the map (i.e. rather than [:div.form.horizontal 
> [child1 child2]] return [:div.form.horizontal child1 child2])
> 5 - also destructure each element assuming [f m(ap) and 0 or more other 
> args]
>
yes, the destructuring is just a normal destructuring of the args passed to 
the fn by map
 

> 6 - emit [ where  is the first symbol, 'f' l in each element. Also 
> prevent this being evaluated in the macro with the syntax-quote as (5) has 
> introduced some new scope because of the ~@ - not sure.
>
as said above, rather than introducing a new scope, ~@ just overrides the 
"don't evaluate" of back-tick
 

> 6 - also associate onto the symbol m (which is assumed to be associative, 
> e.g. a map)...
> 7/8 - extract data out of the 'run-time' (e.g. not macro-time) value of 
> the provided state (magically captured under ~m-state)
> 9 - splice in the rest of the arguments, if any, that were part of the 
> element
> 10 - and do that magic for each element
>
 

-- 
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: 'seq' performance for 'empty?' compared to 'count'. And where's !=?

[Dave Tenny]

Re: where I got this from:

user> (doc empty?)
>
> -
>
> clojure.core/empty?
>
> ([coll])
>
>   Returns true if coll has no items - same as (not (seq coll)).
>
>   Please use the idiom (seq x) rather than (not (empty? x))
>
>
Note that 'empty?' just calls 'seq'.



On Thu, Oct 1, 2015 at 6:40 PM, Nathan Davis <
nda...@positronic-solutions.com> wrote:

> On Thursday, October 1, 2015 at 2:31:46 PM UTC-5, Dave Tenny wrote:
>>
>> So I understand that 'seq' is the idiomatic way to see if a
>> collection/sequence is empty.
>>
>>
> I'm not sure where you got this from.  I personally use empty? to check
> whether a collection is empty.  It is true that (not (empty c)) is not
> encouraged.  I believe the main rationale for this this is that (empty c)
> is (not (seq c)), so (not (empty c)) is (not (not (seq c)).
>
>
>> Logically I'm looking for an O(1) predicate with which I can determine if
>> a seq/collection is empty, and a well behaved
>> one that is idempotent and side effect free (for general performance
>> reasons).
>>
>
> I believe all the implementations of seq in Clojure core are O(1),
> although some (most?) allocate objects.  I'm not sure if it's explicitly
> spelled out anywhere, but I would consider it a bug it was anything other
> than O(1) (or perhaps O(log n) at most).
>
> In what ways is the current implementation of empty not well behaved and
> idempotent?
>
> With regards to side effects, if you can find a completely generic,
> side-effect-free way of determining whether a lazy sequence is empty
> without potentially realizing its head, please let the Clojure community
> know!
>
> I'm not saying having an explicit 'empty' method is a bad idea, but I'm
> not sure the current situation is as bad as you think.
>
> Nathan Davis
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/fUygeQMPqyI/unsubscribe.
> To unsubscribe from this group and all its topics, 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: macro help

[Jason Stewart]

"Mastering Clojure Macros" by Colin Jones gets my vote as the go to book
for writing clojure macros.


On Fri, Oct 2, 2015 at 8:24 AM, Colin Yates  wrote:

> Thanks for your comments - very helpful!
>
> The reference to destructuring might be irrelevant now. Previously I
> noticed that the _map construction_ was emitted from the macro rather than
> the symbol bound to the map. For example, some variation of quoting meant
> (defmacro a [m] (println m)) called with (a {:1 1}) emitted (println {:1
> 1}) rather than (println m). Now I think about it is because an earlier
> iteration of the macro used ~m - I’m not at the desk so I can’t confirm.
>
> Any pointers a decent Clojure macro book? I found lots of blogs around
> from google but not a single one of them mentioned the (let [m-state
> (gensym)] `(let [~m-state ~state])) ‘trick’.
>
> Thanks again.
>
> On 2 Oct 2015, at 10:50, gianluca torta  wrote:
>
> Hi Colin,
>
> as far as I can tell, your solution looks fine... here are a couple of
> comments on your step-by-step analysis
>
> cheers,
> Gianluca
>
>
> 1(defmacro form [state & elements]
>> 2  (let [m-state (gensym)]
>> 3`(let [~m-state ~state]
>> 4   [:div.form.horizontal
>> 5~@(map (fn [[f m & rest]]
>> 6 `[~f (assoc ~m
>> 7 :value (get @(:values ~m-state) (:id ~m))
>> 8 :on-change #(swap! (:values ~m-state) assoc
>> (:id ~m) "UPDATED"))
>> 9   ~@rest])
>> 10   elements)])))
>>
>> 0 - ` means "emit, don't evaluate", ~@ means "splice, e.g. remove the
>> outer sequence so [a ~@[1 2]] becomes [a 1 2] and ' means 'the symbol of
>> rather than the value of'.
>>
> ~@ means "evaluate and splice", i.e., it overrides the "don't evaluate" of
> ` and splices the result in the outer sequence
> ~ means just "evaluate" without the splicing
>
>
>> 2 - declare m-state, which is lexically scoped to the macro and is bound
>> to a random identifier created by gensym
>> 3 - the back-tick (syntax-quote) returns the form rather than evaluating
>> the form, so the macro will return (let* [m-8_324230_ ]) The [~m-state
>> ~state] is just bewildering though.
>> 3 - in addition, the 'state' argument appears to be destructured, but
>> only to one level so if the state contains an atom it is the var of the atom
>>
> 'state' is evaluated due to ~, not sure what you mean by 'destructured,
> but only to one level'
>
>
>> 4 - literal text emitted in-line
>> 5 - splice the results of the map (i.e. rather than [:div.form.horizontal
>> [child1 child2]] return [:div.form.horizontal child1 child2])
>> 5 - also destructure each element assuming [f m(ap) and 0 or more other
>> args]
>>
> yes, the destructuring is just a normal destructuring of the args passed
> to the fn by map
>
>
>> 6 - emit [ where  is the first symbol, 'f' l in each element. Also
>> prevent this being evaluated in the macro with the syntax-quote as (5) has
>> introduced some new scope because of the ~@ - not sure.
>>
> as said above, rather than introducing a new scope, ~@ just overrides the
> "don't evaluate" of back-tick
>
>
>> 6 - also associate onto the symbol m (which is assumed to be associative,
>> e.g. a map)...
>> 7/8 - extract data out of the 'run-time' (e.g. not macro-time) value of
>> the provided state (magically captured under ~m-state)
>> 9 - splice in the rest of the arguments, if any, that were part of the
>> element
>> 10 - and do that magic for each element
>>
>
>
> --
> 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.
>

-- 
You 

Re: Towards Greater Code Reuse

[Colin Yates]

+1 to pipe-lines of immutable data transformations. That was the biggest 
paradigm shift for me coming to FP and made the world a much better place.

> On 2 Oct 2015, at 16:41, Gary Trakhman  wrote:
> 
> There are a lot of strategies to deal with the coupling of reuse.  I find 
> that using pure functions makes it easy to split off responsibilities after 
> the fact and add multiple entry points (the hard thing becomes naming those 
> functions).  Eventually a new 'essence' of the abstraction will show itself 
> and inspire a larger refactor.  That's something I really miss when doing 
> java.  
> 
> Also, I feel that the reusable clojure code is always doing more work than 
> corresponding java code, so my frustration in refactoring is much greater 
> with java and its IDEs.  The refactorings are always superficial compared to 
> what I'm trying to express, and in clojure I can work with data contracts 
> easily.  I often end up writing a new version of the reusable abstraction, 
> writing adapters (just data transformations) from the old to the new, then 
> gutting the old implementation, then hopefully gutting the adapters over 
> time.  Clojure's data focus makes this easy.
> 
> On Fri, Oct 2, 2015 at 11:31 AM Colin Yates  > wrote:
> It might just be me, but I also find the cost of the explicit coupling that 
> is re-use is often far more expensive than any saving offered by re-use of a 
> bunch of text. I also find this _more_ expensive in Clojure than Java as 
> refactoring in Java was pretty robust (IntelliJ is incredibly powerful for 
> this). 
> 
>> On 2 Oct 2015, at 16:25, William la Forge > > wrote:
>> 
>> Refactoring for reuse is a kind of early optimization? Agreed! Generally for 
>> me it waits until the second or third rewrite, as by then I have a bit of an 
>> idea about where I am headed with the code.
>> 
>> OTOH, I finally realized that when I don't know where I am going with 
>> something, keeping the logic in functions instead of methods is probably 
>> safest. I'm thinking now that methods should mostly just be used for their 
>> polymorphism as just a very thin layer over a set of interfaces.
>> 
>> I was so impressed with the advantages of Java over C++ when I started using 
>> it 20 years ago. But now that I've been exposed to Clojure, I'm inclined to 
>> minimize my use of OO and use objects mostly as what I used before OO: 
>> dispatch tables!
>> 
>> 
>> -- 
>> 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 
> .
> 
> -- 
> 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 

Re: macro help

[Thomas Heller]

Well, yeah .. don't use binding. Sometimes they are a good solution though, 
so don't forget about it.

Again I do not know your future plans. I would always recommend writing 
everything with data+functions first. If you find that you have written the 
same thing over and over again it might be time to introduce a new function 
OR actually a macro if that doesn't work.

Macros sure are extremely powerful, so figuring out exactly when to use 
them is quite hard. I know that it took me quite some time to get rid of 
the "hey, just use a macro" urge.

Anyways, glad we agree that your initial macro does not need to exist. ;)

cheer,
/thomas

On Friday, October 2, 2015 at 4:15:47 PM UTC+2, Colin Yates wrote:
>
> Hi Thomas, binding - really? :-). Apart from the general negative reaction 
> they seem to have, I don’t want the individual elements (e.g. text and 
> number) to assume rely on the binding as they can be called individually as 
> well and the binding would just get in the way.
>
> My understanding is that if I want to change a call to a function _before_ 
> that call happens then my only option is to use a macro?
>
> (I also realise this use-case will never need a macro as hiccup very 
> sensibly uses data so the thing passed to (form) is simply a vector.)
>
> I am saying, the discussion of whether _this example_ justifies a macro is 
> mute - I agree it doesn’t.
>
> On 2 Oct 2015, at 15:01, Thomas Heller  
> wrote:
>
> Well, if you don't like that 'form' you could use a binding.
>
> (binding [form/*state*
>   {:editing? true
> :values form-values
> :validation validation-report
> :on-change handle-form-change}]
>   (form/tag 
> (form/text :name)
> (form/number :age)))
>
> Anyways, I would not recommend using the binding but doesn't mean you 
> can't.
>
> I can't quite imagine what your future plans look like but you probably 
> won't need a macro. ;)
>
> cheers,
> /thomas
>
> On Friday, October 2, 2015 at 3:34:48 PM UTC+2, Colin Yates wrote:
>>
>> Hi Thomas - yes, you are right. The example I provided is all 
>> pain/no-gain in terms of macros. However, future plans will require 
>> manipulating the invocation of (for example form/text and form/number) 
>> before they are evaluated.
>>
>> Having said all of that, that repeated ‘form’ does bug me a bit :-). I do 
>> absolutely agree that the cognitive overhead of the macro isn’t justified 
>> here.
>>
>> On 2 Oct 2015, at 14:29, Thomas Heller  wrote:
>>
>> Have you tried NOT using a macro at all? This code does not need to be a 
>> macro at all if you ask me.
>>
>> Just a little sketch but things could look just about the same without 
>> any macros at all:
>>
>> (let [form {:editing? true
>> :values form-values
>> :validation validation-report
>> :on-change handle-form-change}]
>>   (form/tag form
>> (form/text form :name)
>> (form/number form :age)))
>>
>>
>> ;; in-ns 'form
>>
>> (defn text [form field]
>>   [text-component {:id field
>>:value (get-in form [:values field])
>>...}])
>>
>> (defn tag
>>   [{:keys [editing?] :as form} & children]
>>   (into [:div.form.horizontal
>>  {:class (if editing? "editing" "editable")}]
>> children))
>>
>>
>> Use macros very sparingly, most of the time data and functions are just 
>> better.
>>
>> Just my 2 cents,
>> /thomas
>>
>> On Wednesday, September 30, 2015 at 10:29:30 PM UTC+2, Colin Yates wrote:
>>>
>>> Hi all,
>>>
>>> I am banging my head against the wall - I think it is obvious but I have 
>>> started too long:
>>>
>>> The use-case is that I want a form which takes a set of children. The 
>>> form also takes in some form-wide state, like the form-wide validation, the 
>>> values for each item etc. I want the macro, for each child, to decorate 
>>> that child by extracting the validation errors and value from the form-wide 
>>> state.
>>>
>>> So, assuming:
>>>  - validation looks like {:name "Duplicate name" :age "You must be at 
>>> least 0"}
>>>  - form-values looks like {:name "a-duplicate-user" :age -1}
>>>
>>> then my form might look like:
>>>
>>> (form {:editing? true :values form-values :validation validation-report 
>>> :on-change handle-form-change}
>>>   [form/text {:id :name}]
>>>   [form/number {:id :age}])
>>>
>>> After the macro I want the following code:
>>>
>>> [:div.form.horizontal
>>>   {:class "editing"}
>>>   [form/text {:id :name :value "a-duplicate-user" :errors "Duplicate 
>>> name" :on-click (fn [e] (handle-form-change :name (-> e .target .value])]
>>>   [form/number {:id :age :value "-1" :errors "You must be at least 0" 
>>> :on-click (fn [e] (handle-form-change :age (-> e .target .value))]]
>>>
>>> However, ideally the macro would _not_ emit the contents of the input as 
>>> literals but would emit code that inspects the provided parameters at 
>>> run-time (i.e. rather than :value 

Re: cond->: Using of threading expression in tests?

[ru]

Thank you, Colin.

This works:

user=> (as-> {:x 5} x1 (if (> (get x1 :x) 3) (assoc x1 :y 6) x1) (if (<= 
(get x1 :x) 3) (assoc x1 :y 12) x1))
{:y 6, :x 5}

But without cond-> at all :( :)

пятница, 2 октября 2015 г., 17:49:28 UTC+3 пользователь ru написал:
>
> Hi,
>
> Can I use in tests threading expression of cond->, and how?
>
> Thanx in advance,
>   Ru
>

-- 
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: cond->: Using of threading expression in tests?

[ru]

Hi, Colin

For example, (cond-> {:x 5} (> (get ??? :x) 3) (assoc :y 6))

пятница, 2 октября 2015 г., 17:49:28 UTC+3 пользователь ru написал:
>
> Hi,
>
> Can I use in tests threading expression of cond->, and how?
>
> Thanx in advance,
>   Ru
>

-- 
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: cond->: Using of threading expression in tests?

[Colin Yates]

Alternatively you can do (cond-> {:x 1} (fn [x] (= (:x x) 1)) (assoc :x 2))

> On 2 Oct 2015, at 16:33, ru  wrote:
> 
> Thank you, Colin.
> 
> This works:
> 
> user=> (as-> {:x 5} x1 (if (> (get x1 :x) 3) (assoc x1 :y 6) x1) (if (<= (get 
> x1 :x) 3) (assoc x1 :y 12) x1))
> {:y 6, :x 5}
> 
> But without cond-> at all :( :)
> 
> пятница, 2 октября 2015 г., 17:49:28 UTC+3 пользователь ru написал:
> Hi,
> 
> Can I use in tests threading expression of cond->, and how?
> 
> Thanx in advance,
>   Ru
> 
> -- 
> 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: Towards Greater Code Reuse

[Gary Trakhman]

There are a lot of strategies to deal with the coupling of reuse.  I find
that using pure functions makes it easy to split off responsibilities after
the fact and add multiple entry points (the hard thing becomes naming those
functions).  Eventually a new 'essence' of the abstraction will show itself
and inspire a larger refactor.  That's something I really miss when doing
java.

Also, I feel that the reusable clojure code is always doing more work than
corresponding java code, so my frustration in refactoring is much greater
with java and its IDEs.  The refactorings are always superficial compared
to what I'm trying to express, and in clojure I can work with data
contracts easily.  I often end up writing a new version of the reusable
abstraction, writing adapters (just data transformations) from the old to
the new, then gutting the old implementation, then hopefully gutting the
adapters over time.  Clojure's data focus makes this easy.

On Fri, Oct 2, 2015 at 11:31 AM Colin Yates  wrote:

> It might just be me, but I also find the cost of the explicit coupling
> that is re-use is often far more expensive than any saving offered by
> re-use of a bunch of text. I also find this _more_ expensive in Clojure
> than Java as refactoring in Java was pretty robust (IntelliJ is incredibly
> powerful for this).
>
> On 2 Oct 2015, at 16:25, William la Forge  wrote:
>
> Refactoring for reuse is a kind of early optimization? Agreed! Generally
> for me it waits until the second or third rewrite, as by then I have a bit
> of an idea about where I am headed with the code.
>
> OTOH, I finally realized that when I don't know where I am going with
> something, keeping the logic in functions instead of methods is probably
> safest. I'm thinking now that methods should mostly just be used for their
> polymorphism as just a very thin layer over a set of interfaces.
>
> I was so impressed with the advantages of Java over C++ when I started
> using it 20 years ago. But now that I've been exposed to Clojure, I'm
> inclined to minimize my use of OO and use objects mostly as what I used
> before OO: dispatch tables!
>
>
> --
> 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.
>

-- 
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: Towards Greater Code Reuse

[William la Forge]

It is obvious to me now that I am still very much a newbie to Clojure!

On Fri, Oct 2, 2015 at 11:51 AM, Colin Yates  wrote:

> +1 to pipe-lines of immutable data transformations. That was the biggest
> paradigm shift for me coming to FP and made the world a much better place.
>
> On 2 Oct 2015, at 16:41, Gary Trakhman  wrote:
>
> There are a lot of strategies to deal with the coupling of reuse.  I find
> that using pure functions makes it easy to split off responsibilities after
> the fact and add multiple entry points (the hard thing becomes naming those
> functions).  Eventually a new 'essence' of the abstraction will show itself
> and inspire a larger refactor.  That's something I really miss when doing
> java.
>
> Also, I feel that the reusable clojure code is always doing more work than
> corresponding java code, so my frustration in refactoring is much greater
> with java and its IDEs.  The refactorings are always superficial compared
> to what I'm trying to express, and in clojure I can work with data
> contracts easily.  I often end up writing a new version of the reusable
> abstraction, writing adapters (just data transformations) from the old to
> the new, then gutting the old implementation, then hopefully gutting the
> adapters over time.  Clojure's data focus makes this easy.
>
> On Fri, Oct 2, 2015 at 11:31 AM Colin Yates  wrote:
>
>> It might just be me, but I also find the cost of the explicit coupling
>> that is re-use is often far more expensive than any saving offered by
>> re-use of a bunch of text. I also find this _more_ expensive in Clojure
>> than Java as refactoring in Java was pretty robust (IntelliJ is incredibly
>> powerful for this).
>>
>> On 2 Oct 2015, at 16:25, William la Forge  wrote:
>>
>> Refactoring for reuse is a kind of early optimization? Agreed! Generally
>> for me it waits until the second or third rewrite, as by then I have a bit
>> of an idea about where I am headed with the code.
>>
>> OTOH, I finally realized that when I don't know where I am going with
>> something, keeping the logic in functions instead of methods is probably
>> safest. I'm thinking now that methods should mostly just be used for their
>> polymorphism as just a very thin layer over a set of interfaces.
>>
>> I was so impressed with the advantages of Java over C++ when I started
>> using it 20 years ago. But now that I've been exposed to Clojure, I'm
>> inclined to minimize my use of OO and use objects mostly as what I used
>> before OO: dispatch tables!
>>
>>
>> --
>> 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.
>>
>
> --
> 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 

Re: cond->: Using of threading expression in tests?

[ru]

This is remarkable improvement and it shows that test is a function of the 
threading expression.

user=> (cond-> {:x 1} #(= (:x %) 1) (assoc :y 2))
{:y 2, :x 1}

also works.

Thanks a lot

пятница, 2 октября 2015 г., 17:49:28 UTC+3 пользователь ru написал:
>
> Hi,
>
> Can I use in tests threading expression of cond->, and how?
>
> Thanx in advance,
>   Ru
>

-- 
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: safety and reusability of clojure.lang.RT, Compiler and co. in multi-classloader environment

[Toby Crawley]

Thanks, I've updated the README with more notes about threads in
general, and core.async specifically.

- Toby

On Fri, Oct 2, 2015 at 3:32 AM, Georgi Danov  wrote:
> Toby, you might want to add one more thread leak —
> clojure.core.async.impl.timers/timeout-daemon, even though this is not
> official core lib
>
>
> On Tuesday, September 29, 2015 at 4:14:48 AM UTC+2, Toby Crawley wrote:
>>
>> Note that that post is out of date - the runtime isolation pieces of
>> Immutant 1.x have been extracted into
>> https://github.com/projectodd/shimdandy (which Stephen mentioned).
>> Note that with shimdandy, shims *can't* share Clojure classes - each
>> shim will have its own copy. This is required if you want them to be
>> isolated from each other, or you want them to have different effective
>> classpaths. If you do give shimdandy a try, let me know if you have
>> any problems/questions.
>>
>> - Toby
>>
>> On Mon, Sep 28, 2015 at 6:57 PM, Gary Trakhman 
>> wrote:
>> > Here is another interesting read about how they solved it in immutant:
>> > http://immutant.org/news/2012/05/18/runtime-isolation/
>> >
>> > On Mon, Sep 28, 2015 at 6:54 PM Stephen Gilardi  wrote:
>> >>
>> >> I haven’t seen discussion of isolating some of the RT data structures
>> >> while sharing others and the executable parts.
>> >>
>> >> In case you haven’t seen these, here are some references about isolated
>> >> Clojure runtimes that may be helpful:
>> >>
>> >> https://github.com/boot-clj/boot and its “pods” facility:
>> >> https://github.com/boot-clj/boot/tree/master/boot/pod which uses
>> >> https://github.com/projectodd/shimdandy .
>> >>
>> >> More on pods: https://github.com/boot-clj/boot/wiki/Pods
>> >>
>> >> A presentation about boot (including pods):
>> >> https://www.youtube.com/watch?v=TcnzB2tB-8Q .
>> >>
>> >> —Steve
>> >>
>> >> https://github.com/projectodd/shimdandy
>> >>
>> >> On Sep 28, 2015, at 6:08 PM, Georgi Danov  wrote:
>> >>
>> >> Hi,
>> >>  I am integrating clojure into java micro container. It has
>> >> hierarchical
>> >> classloaders and can restart modules on the fly. It's almost REPL for
>> >> Java
>> >> :).
>> >>
>> >>  I have clojure running inside it, but even after reading some of the
>> >> RT
>> >> and Compiler classes source code I don't understand well enough how
>> >> much
>> >> state is accumulated where (theadLocals, static class fields/Vars,
>> >> classloader, so on). Given that I don't want to have each module run
>> >> different clojure version, I would prefer to have the basic things
>> >> loaded
>> >> once and shared.
>> >>
>> >>  I am also not sure what is shareable — I see the RT class has some
>> >> static
>> >> init functionality that appears to be safe for sharing the same
>> >> clojure.jar
>> >> classloader with all modules, but can't be sure.
>> >>
>> >>  Would be glad if there is article I have missed that outlines this.
>> >>
>> >> Thanks,
>> >> Georgi
>> >>
>> >> --
>> >> 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.
>> >> 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
>> > 

Re: cond->: Using of threading expression in tests?

[Colin Yates]

Hi Ru - I am not sure I understand the question - can you expand on the 
use-case a bit please.
> On 2 Oct 2015, at 15:49, ru  wrote:
> 
> Hi,
> 
> Can I use in tests threading expression of cond->, and how?
> 
> Thanx in advance,
>   Ru
> 
> -- 
> 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: Towards Greater Code Reuse

[Colin Yates]

It might just be me, but I also find the cost of the explicit coupling that is 
re-use is often far more expensive than any saving offered by re-use of a bunch 
of text. I also find this _more_ expensive in Clojure than Java as refactoring 
in Java was pretty robust (IntelliJ is incredibly powerful for this). 

> On 2 Oct 2015, at 16:25, William la Forge  wrote:
> 
> Refactoring for reuse is a kind of early optimization? Agreed! Generally for 
> me it waits until the second or third rewrite, as by then I have a bit of an 
> idea about where I am headed with the code.
> 
> OTOH, I finally realized that when I don't know where I am going with 
> something, keeping the logic in functions instead of methods is probably 
> safest. I'm thinking now that methods should mostly just be used for their 
> polymorphism as just a very thin layer over a set of interfaces.
> 
> I was so impressed with the advantages of Java over C++ when I started using 
> it 20 years ago. But now that I've been exposed to Clojure, I'm inclined to 
> minimize my use of OO and use objects mostly as what I used before OO: 
> dispatch tables!
> 
> 
> -- 
> 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.

cond->: Using of threading expression in tests?

[ru]

Hi,

Can I use in tests threading expression of cond->, and how?

Thanx in advance,
  Ru

-- 
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: macro help

[Colin Yates]

This is my first venture into macros since starting with Clojure a bunch of 
years ago - no urge here. I also use binding for a use-case I haven’t seen any 
other solution for; an implementation of a protocol which doesn’t take a tx as 
a parameter but wants to participate in a tx. Binding is a perfect fit for that.

I think we agree entirely and I think I maybe misled with the use-case I was 
apparently proposing using a macro for :-). My question was more about _how_ do 
I get this to work rather than _should_ I do it this way.

Thanks again Thomas.

> On 2 Oct 2015, at 15:48, Thomas Heller  wrote:
> 
> Well, yeah .. don't use binding. Sometimes they are a good solution though, 
> so don't forget about it.
> 
> Again I do not know your future plans. I would always recommend writing 
> everything with data+functions first. If you find that you have written the 
> same thing over and over again it might be time to introduce a new function 
> OR actually a macro if that doesn't work.
> 
> Macros sure are extremely powerful, so figuring out exactly when to use them 
> is quite hard. I know that it took me quite some time to get rid of the "hey, 
> just use a macro" urge.
> 
> Anyways, glad we agree that your initial macro does not need to exist. ;)
> 
> cheer,
> /thomas
> 
> On Friday, October 2, 2015 at 4:15:47 PM UTC+2, Colin Yates wrote:
> Hi Thomas, binding - really? :-). Apart from the general negative reaction 
> they seem to have, I don’t want the individual elements (e.g. text and 
> number) to assume rely on the binding as they can be called individually as 
> well and the binding would just get in the way.
> 
> My understanding is that if I want to change a call to a function _before_ 
> that call happens then my only option is to use a macro?
> 
> (I also realise this use-case will never need a macro as hiccup very sensibly 
> uses data so the thing passed to (form) is simply a vector.)
> 
> I am saying, the discussion of whether _this example_ justifies a macro is 
> mute - I agree it doesn’t.
> 
>> On 2 Oct 2015, at 15:01, Thomas Heller  
>> wrote:
>> 
>> Well, if you don't like that 'form' you could use a binding.
>> 
>> (binding [form/*state*
>>   {:editing? true
>> :values form-values
>> :validation validation-report
>> :on-change handle-form-change}]
>>   (form/tag 
>> (form/text :name)
>> (form/number :age)))
>> 
>> Anyways, I would not recommend using the binding but doesn't mean you can't.
>> 
>> I can't quite imagine what your future plans look like but you probably 
>> won't need a macro. ;)
>> 
>> cheers,
>> /thomas
>> 
>> On Friday, October 2, 2015 at 3:34:48 PM UTC+2, Colin Yates wrote:
>> Hi Thomas - yes, you are right. The example I provided is all pain/no-gain 
>> in terms of macros. However, future plans will require manipulating the 
>> invocation of (for example form/text and form/number) before they are 
>> evaluated.
>> 
>> Having said all of that, that repeated ‘form’ does bug me a bit :-). I do 
>> absolutely agree that the cognitive overhead of the macro isn’t justified 
>> here.
>> 
>>> On 2 Oct 2015, at 14:29, Thomas Heller gmail.com 
>>> > wrote:
>>> 
>>> Have you tried NOT using a macro at all? This code does not need to be a 
>>> macro at all if you ask me.
>>> 
>>> Just a little sketch but things could look just about the same without any 
>>> macros at all:
>>> 
>>> (let [form {:editing? true
>>> :values form-values
>>> :validation validation-report
>>> :on-change handle-form-change}]
>>>   (form/tag form
>>> (form/text form :name)
>>> (form/number form :age)))
>>> 
>>> 
>>> ;; in-ns 'form
>>> 
>>> (defn text [form field]
>>>   [text-component {:id field
>>>:value (get-in form [:values field])
>>>...}])
>>> 
>>> (defn tag
>>>   [{:keys [editing?] :as form} & children]
>>>   (into [:div.form.horizontal
>>>  {:class (if editing? "editing" "editable")}]
>>> children))
>>> 
>>> 
>>> Use macros very sparingly, most of the time data and functions are just 
>>> better.
>>> 
>>> Just my 2 cents,
>>> /thomas
>>> 
>>> On Wednesday, September 30, 2015 at 10:29:30 PM UTC+2, Colin Yates wrote:
>>> Hi all,
>>> 
>>> I am banging my head against the wall - I think it is obvious but I have 
>>> started too long:
>>> 
>>> The use-case is that I want a form which takes a set of children. The form 
>>> also takes in some form-wide state, like the form-wide validation, the 
>>> values for each item etc. I want the macro, for each child, to decorate 
>>> that child by extracting the validation errors and value from the form-wide 
>>> state.
>>> 
>>> So, assuming:
>>>  - validation looks like {:name "Duplicate name" :age "You must be at least 
>>> 0"}
>>>  - form-values looks like {:name "a-duplicate-user" :age -1}
>>> 
>>> then my form might look like:
>>> 
>>> (form 

Re: cond->: Using of threading expression in tests?

[Colin Yates]

Ah I see - maybe https://clojuredocs.org/clojure.core/as-%3E 
 will help (untried):

  (cond-> {:x 5} (as-> x1 (> (get x1 :x) 3)…)


> On 2 Oct 2015, at 16:07, ru  wrote:
> 
> Hi, Colin
> 
> For example, (cond-> {:x 5} (> (get ??? :x) 3) (assoc :y 6))
> 
> пятница, 2 октября 2015 г., 17:49:28 UTC+3 пользователь ru написал:
> Hi,
> 
> Can I use in tests threading expression of cond->, and how?
> 
> Thanx in advance,
>   Ru
> 
> -- 
> 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: Towards Greater Code Reuse

[William la Forge]

Refactoring for reuse is a kind of early optimization? Agreed! Generally
for me it waits until the second or third rewrite, as by then I have a bit
of an idea about where I am headed with the code.

OTOH, I finally realized that when I don't know where I am going with
something, keeping the logic in functions instead of methods is probably
safest. I'm thinking now that methods should mostly just be used for their
polymorphism as just a very thin layer over a set of interfaces.

I was so impressed with the advantages of Java over C++ when I started
using it 20 years ago. But now that I've been exposed to Clojure, I'm
inclined to minimize my use of OO and use objects mostly as what I used
before OO: dispatch tables!

-- 
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: cond->: Using of threading expression in tests?

[Sean Corfield]

We needed this functionality too and ended up writing our own utility macro:

(defmacro condp->
  "Takes an expression and a set of predicate/form pairs. Threads expr (via ->)
  through each form for which the corresponding predicate is true of expr.
  Note that, unlike cond branching, condp-> threading does not short circuit
  after the first true test expression."
  [expr & clauses]
  (assert (even? (count clauses)))
  (let [g (gensym)
pstep (fn [[pred step]] `(if (~pred ~g) (-> ~g ~step) ~g))]
`(let [~g ~expr
   ~@(interleave (repeat g) (map pstep (partition 2 clauses)))]
   ~g)))

So (condp-> {:x 1} #(= (:x %) 1) (assoc :x 2)) produces {:x 2} as desired.

We have a condp->> version as well.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood






From:   on behalf of Jason Felice
Reply-To:  
Date:  Friday, October 2, 2015 at 10:23 AM
To:  
Subject:  Re: cond->: Using of threading expression in tests?


>This doesn't work, as (fn [x] (= (:x x) 1)) is never evaluated and the 
>function itself is always truthy.  (Same for the #(= (:x %) 1) version).
>
>On Fri, Oct 2, 2015 at 9:00 AM, Colin Yates  wrote:
>
>Alternatively you can do (cond-> {:x 1} (fn [x] (= (:x x) 1)) (assoc :x 2))
>
>On 2 Oct 2015, at 16:33, ru  wrote:
>
>Thank you, Colin.
>This works:
>
>user=> (as-> {:x 5} x1 (if (> (get x1 :x) 3) (assoc x1 :y 6) x1) (if (<= (get 
>x1 :x) 3) (assoc x1 :y 12) x1))
>{:y 6, :x 5}
>
>
>But without cond-> at all :( :)
>
>пятница, 2 октября 2015 г., 17:49:28 UTC+3 пользователь ru написал:
>Hi,
>Can I use in tests threading expression of cond->, and how?
>
>Thanx in advance,
>  Ru
>
>
>

-- 
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: cond->: Using of threading expression in tests?

[Jason Felice]

This doesn't work, as (fn [x] (= (:x x) 1)) is never evaluated and the
function itself is always truthy.  (Same for the #(= (:x %) 1) version).

On Fri, Oct 2, 2015 at 9:00 AM, Colin Yates  wrote:

> Alternatively you can do (cond-> {:x 1} (fn [x] (= (:x x) 1)) (assoc :x
> 2))
>
> On 2 Oct 2015, at 16:33, ru  wrote:
>
> Thank you, Colin.
>
> This works:
>
> user=> (as-> {:x 5} x1 (if (> (get x1 :x) 3) (assoc x1 :y 6) x1) (if (<=
> (get x1 :x) 3) (assoc x1 :y 12) x1))
> {:y 6, :x 5}
>
> But without cond-> at all :( :)
>
> пятница, 2 октября 2015 г., 17:49:28 UTC+3 пользователь ru написал:
>>
>> Hi,
>>
>> Can I use in tests threading expression of cond->, and how?
>>
>> Thanx in advance,
>>   Ru
>>
>
> --
> 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.
>

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

The middleware pattern

[Jason Felice]

Why is it so hard to describe to new people?

I mean, the questions I get are (I understand what's happening here, but I
can't describe it well):

1. If -> threads things first-to-last, why does the middleware run
last-to-first?
2. Why is comp backwards?
3. Wait, so how does each wrapper get a second pass at it?
4. Why would you do this to me?

I hope to write a blog or something on this, but I wanted to check in here
first.  Any ideas on how to talk about this?

Thanks,
-Jason

-- 
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: cond->: Using of threading expression in tests?

[Colin Yates]

Well I feel a numpty :-).

> On 2 Oct 2015, at 18:23, Jason Felice  wrote:
> 
> This doesn't work, as (fn [x] (= (:x x) 1)) is never evaluated and the 
> function itself is always truthy.  (Same for the #(= (:x %) 1) version).
> 
> On Fri, Oct 2, 2015 at 9:00 AM, Colin Yates  > wrote:
> Alternatively you can do (cond-> {:x 1} (fn [x] (= (:x x) 1)) (assoc :x 2))
> 
>> On 2 Oct 2015, at 16:33, ru > 
>> wrote:
>> 
>> Thank you, Colin.
>> 
>> This works:
>> 
>> user=> (as-> {:x 5} x1 (if (> (get x1 :x) 3) (assoc x1 :y 6) x1) (if (<= 
>> (get x1 :x) 3) (assoc x1 :y 12) x1))
>> {:y 6, :x 5}
>> 
>> But without cond-> at all :( :)
>> 
>> пятница, 2 октября 2015 г., 17:49:28 UTC+3 пользователь ru написал:
>> Hi,
>> 
>> Can I use in tests threading expression of cond->, and how?
>> 
>> Thanx in advance,
>>   Ru
>> 
>> -- 
>> 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 
> .
> 
> 
> -- 
> 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: 'seq' performance for 'empty?' compared to 'count'. And where's !=?

[Mark Engelberg]

When I know I'm dealing with a counted collection, like vector, then for
performance I test for empty with (zero? (count v)).

It would be nice if empty? were more polymorphic, but I'm not sure how that
would affect performance - might make things worse for the common case.
Certainly in the general case, the current implementation of empty? is the
only real way to do it.  If you have an infinite sequence, a count-based
version would run forever.

-- 
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: The middleware pattern

[Raymond Huang]

To follow up on middleware, this is a great picture to demonstrate it.

687474703a2f2f692e737461636b2e696d6775722e636f6d2f68623864422e706e67


On Fri, Oct 2, 2015 at 2:43 PM, Marc O'Morain  wrote:

> Could you use Russian Dolls as an analogy? To build a Russian doll (or to
> build middleware) you start out with the smallest doll, and put it inside
> the second smallest, which in turn goes inside the third smallest. When
> opening the doll (calling the function) you start with the largest doll,
> and open it to reveal the second largest, etc.
>
> Imagine the function as a marble, and Russian Dolls as middleware. To put
> the marble inside the dolls you wrap it in the smallest doll first. To call
> the function (retrieve the marble) you need to open the largest, outermost
> doll first.
>
>
>
> On Fri, Oct 2, 2015 at 8:10 PM, Jason Felice 
> wrote:
>
>> Why is it so hard to describe to new people?
>>
>> I mean, the questions I get are (I understand what's happening here, but
>> I can't describe it well):
>>
>> 1. If -> threads things first-to-last, why does the middleware run
>> last-to-first?
>> 2. Why is comp backwards?
>> 3. Wait, so how does each wrapper get a second pass at it?
>> 4. Why would you do this to me?
>>
>> I hope to write a blog or something on this, but I wanted to check in
>> here first.  Any ideas on how to talk about this?
>>
>> Thanks,
>> -Jason
>>
>> --
>> 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.
>

-- 
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: The middleware pattern

[Marc O'Morain]

Could you use Russian Dolls as an analogy? To build a Russian doll (or to build 
middleware) you start out with the smallest doll, and put it inside the second 
smallest, which in turn goes inside the third smallest. When opening the doll 
(calling the function) you start with the largest doll, and open it to reveal 
the second largest, etc. 




Imagine the function as a marble, and Russian Dolls as middleware. To put the 
marble inside the dolls you wrap it in the smallest doll first. To call the 
function (retrieve the marble) you need to open the largest, outermost doll 
first.

On Fri, Oct 2, 2015 at 8:10 PM, Jason Felice 
wrote:

> Why is it so hard to describe to new people?
> I mean, the questions I get are (I understand what's happening here, but I
> can't describe it well):
> 1. If -> threads things first-to-last, why does the middleware run
> last-to-first?
> 2. Why is comp backwards?
> 3. Wait, so how does each wrapper get a second pass at it?
> 4. Why would you do this to me?
> I hope to write a blog or something on this, but I wanted to check in here
> first.  Any ideas on how to talk about this?
> Thanks,
> -Jason
> -- 
> 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: The middleware pattern

[Jason Felice]

@Raymond I like the illustration a lot.  Perhaps I will use something like
this.
@Marc I think this would likely be like "monad burritos"... it makes sense
to people who understand it in the first place.  Although, I noticed when
trying to explain it today, that I had a concept of "size" in my mind -
it's sort of connected to "layer of abstraction".

On Fri, Oct 2, 2015 at 2:59 PM, Raymond Huang <12ay.hu...@gmail.com> wrote:

> To follow up on middleware, this is a great picture to demonstrate it.
>
> 687474703a2f2f692e737461636b2e696d6775722e636f6d2f68623864422e706e67
> 
>
> On Fri, Oct 2, 2015 at 2:43 PM, Marc O'Morain  wrote:
>
>> Could you use Russian Dolls as an analogy? To build a Russian doll (or to
>> build middleware) you start out with the smallest doll, and put it inside
>> the second smallest, which in turn goes inside the third smallest. When
>> opening the doll (calling the function) you start with the largest doll,
>> and open it to reveal the second largest, etc.
>>
>> Imagine the function as a marble, and Russian Dolls as middleware. To put
>> the marble inside the dolls you wrap it in the smallest doll first. To call
>> the function (retrieve the marble) you need to open the largest, outermost
>> doll first.
>>
>>
>>
>> On Fri, Oct 2, 2015 at 8:10 PM, Jason Felice 
>> wrote:
>>
>>> Why is it so hard to describe to new people?
>>>
>>> I mean, the questions I get are (I understand what's happening here, but
>>> I can't describe it well):
>>>
>>> 1. If -> threads things first-to-last, why does the middleware run
>>> last-to-first?
>>> 2. Why is comp backwards?
>>> 3. Wait, so how does each wrapper get a second pass at it?
>>> 4. Why would you do this to me?
>>>
>>> I hope to write a blog or something on this, but I wanted to check in
>>> here first.  Any ideas on how to talk about this?
>>>
>>> Thanks,
>>> -Jason
>>>
>>> --
>>> 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.
>>
>
> --
> 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: JDK versions for clojure 1.7

[Ghadi Shayban]

1.6 and later.

On Friday, October 2, 2015 at 8:12:58 PM UTC-4, webber wrote:
>
> Hi,
>
> I'd like to ask a question.
> Which versions of JDK does Clojure 1.7 support ?
>
> 1.6 or later, 1.7 or later ?
>
> Thanks,
> MH
>
>

-- 
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: No recent activity for core.async?

[Daniel Compton]

If core.async is going to get out of alpha in the next version, does it
also make sense to rationalize the namespaces so that both Clojure and
ClojureScript use clojure.core.async.*? In this era of cljc and shared
namespaces, it would be nice to have a universal require. Once core.async
is out of alpha state it seems likely that the namespace structure will be
set in stone.

This is being tracked in http://dev.clojure.org/jira/browse/ASYNC-142
On Sat, Oct 3, 2015 at 2:37 AM Alex Miller  wrote:

> I talked to Rich yesterday and we expect to remove the alpha in the next
> version, fyi.
>
>
> On Wednesday, September 30, 2015 at 10:39:17 PM UTC-4, Rangel Spasov wrote:
>>
>> We've been using the library very actively from both Clojure and
>> ClojureScript and have no problems with it - no reasons to worry about the
>> alpha label I think :).
>>
>>
>> On Saturday, September 26, 2015 at 2:49:22 AM UTC-7, Rafik NACCACHE wrote:
>>>
>>> core.async didn't move since more than a year.
>>>
>>> Is any new release coming soon? I actually use this library intensively,
>>> and the fact it is staying alpha for more than a year starts giving me some
>>> shivers :)
>>>
>>> Thank you for any updates !!
>>>
>> --
> 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.
>
-- 
Daniel

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

JDK versions for clojure 1.7

[webber]

Hi,

I'd like to ask a question.
Which versions of JDK does Clojure 1.7 support ?

1.6 or later, 1.7 or later ?

Thanks,
MH

-- 
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: The middleware pattern

[Matthew Boston]

comp isn't backwards, it's just "outside-in".

((comp not zero?) x) == (not (zero x))

So it reads in the same order from left-to-right as it would otherwise.

On Friday, October 2, 2015 at 1:10:54 PM UTC-6, Jason Felice wrote:
>
> Why is it so hard to describe to new people?
>
> I mean, the questions I get are (I understand what's happening here, but I 
> can't describe it well):
>
> 1. If -> threads things first-to-last, why does the middleware run 
> last-to-first?
> 2. Why is comp backwards?
> 3. Wait, so how does each wrapper get a second pass at it? 
> 4. Why would you do this to me?
>
> I hope to write a blog or something on this, but I wanted to check in here 
> first.  Any ideas on how to talk about this?
>
> Thanks,
> -Jason
>

-- 
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: JDK versions for clojure 1.7

[Makoto Hashimoto]

Thanks !

2015-10-03 9:38 GMT+09:00 Ghadi Shayban :

> 1.6 and later.
>
>
> On Friday, October 2, 2015 at 8:12:58 PM UTC-4, webber wrote:
>>
>> Hi,
>>
>> I'd like to ask a question.
>> Which versions of JDK does Clojure 1.7 support ?
>>
>> 1.6 or later, 1.7 or later ?
>>
>> Thanks,
>> MH
>>
>> --
> 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: safety and reusability of clojure.lang.RT, Compiler and co. in multi-classloader environment

[Georgi Danov]

Toby, you might want to add one more thread leak — 
clojure.core.async.impl.timers/timeout-daemon, even though this is not 
official core lib


On Tuesday, September 29, 2015 at 4:14:48 AM UTC+2, Toby Crawley wrote:
>
> Note that that post is out of date - the runtime isolation pieces of 
> Immutant 1.x have been extracted into 
> https://github.com/projectodd/shimdandy (which Stephen mentioned). 
> Note that with shimdandy, shims *can't* share Clojure classes - each 
> shim will have its own copy. This is required if you want them to be 
> isolated from each other, or you want them to have different effective 
> classpaths. If you do give shimdandy a try, let me know if you have 
> any problems/questions. 
>
> - Toby 
>
> On Mon, Sep 28, 2015 at 6:57 PM, Gary Trakhman  > wrote: 
> > Here is another interesting read about how they solved it in immutant: 
> > http://immutant.org/news/2012/05/18/runtime-isolation/ 
> > 
> > On Mon, Sep 28, 2015 at 6:54 PM Stephen Gilardi  > wrote: 
> >> 
> >> I haven’t seen discussion of isolating some of the RT data structures 
> >> while sharing others and the executable parts. 
> >> 
> >> In case you haven’t seen these, here are some references about isolated 
> >> Clojure runtimes that may be helpful: 
> >> 
> >> https://github.com/boot-clj/boot and its “pods” facility: 
> >> https://github.com/boot-clj/boot/tree/master/boot/pod which uses 
> >> https://github.com/projectodd/shimdandy . 
> >> 
> >> More on pods: https://github.com/boot-clj/boot/wiki/Pods 
> >> 
> >> A presentation about boot (including pods): 
> >> https://www.youtube.com/watch?v=TcnzB2tB-8Q . 
> >> 
> >> —Steve 
> >> 
> >> https://github.com/projectodd/shimdandy 
> >> 
> >> On Sep 28, 2015, at 6:08 PM, Georgi Danov  > wrote: 
> >> 
> >> Hi, 
> >>  I am integrating clojure into java micro container. It has 
> hierarchical 
> >> classloaders and can restart modules on the fly. It's almost REPL for 
> Java 
> >> :). 
> >> 
> >>  I have clojure running inside it, but even after reading some of the 
> RT 
> >> and Compiler classes source code I don't understand well enough how 
> much 
> >> state is accumulated where (theadLocals, static class fields/Vars, 
> >> classloader, so on). Given that I don't want to have each module run 
> >> different clojure version, I would prefer to have the basic things 
> loaded 
> >> once and shared. 
> >> 
> >>  I am also not sure what is shareable — I see the RT class has some 
> static 
> >> init functionality that appears to be safe for sharing the same 
> clojure.jar 
> >> classloader with all modules, but can't be sure. 
> >> 
> >>  Would be glad if there is article I have missed that outlines this. 
> >> 
> >> Thanks, 
> >> Georgi 
> >> 
> >> -- 
> >> 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 . 
> >> 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 

Origin for Clojure using the term 'vector' instead of 'array'?

[Daniel Compton]

I recently had someone learning Clojure ask me why Clojure used the term
'vector' when many other languages used the term 'array'. I thought for a
bit, and the only reason I could come up with was that it clearly
differentiated Clojure's array-like data structures from Java's array data
structures. I had a search online and couldn't find anything discussing
this.

Does anyone know if there is an official reason for this?
-- 
Daniel

-- 
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: The middleware pattern

[Jason Felice]

@Matthew It also follows the dot notation for function composition, right?
This makes sense, but then:

(def iso8601->timestamp
  (comp date-time->timestamp iso8601->date-time))


On Fri, Oct 2, 2015 at 5:39 PM, Matthew Boston 
wrote:

> comp isn't backwards, it's just "outside-in".
>
> ((comp not zero?) x) == (not (zero x))
>
> So it reads in the same order from left-to-right as it would otherwise.
>
>
> On Friday, October 2, 2015 at 1:10:54 PM UTC-6, Jason Felice wrote:
>>
>> Why is it so hard to describe to new people?
>>
>> I mean, the questions I get are (I understand what's happening here, but
>> I can't describe it well):
>>
>> 1. If -> threads things first-to-last, why does the middleware run
>> last-to-first?
>> 2. Why is comp backwards?
>> 3. Wait, so how does each wrapper get a second pass at it?
>> 4. Why would you do this to me?
>>
>> I hope to write a blog or something on this, but I wanted to check in
>> here first.  Any ideas on how to talk about this?
>>
>> Thanks,
>> -Jason
>>
> --
> 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: Origin for Clojure using the term 'vector' instead of 'array'?

[James Reeves]

In a number of languages, arrays are typically a fixed size, whereas
vectors are typically a variable size.

I imagine Clojure adopts this for the same reason, and also because "array"
already refers to Java arrays.

- James

On 3 October 2015 at 03:49, Daniel Compton 
wrote:

> I recently had someone learning Clojure ask me why Clojure used the term
> 'vector' when many other languages used the term 'array'. I thought for a
> bit, and the only reason I could come up with was that it clearly
> differentiated Clojure's array-like data structures from Java's array data
> structures. I had a search online and couldn't find anything discussing
> this.
>
> Does anyone know if there is an official reason for this?
> --
> Daniel
>
> --
> 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: Origin for Clojure using the term 'vector' instead of 'array'?

[Mars0i]

I have no idea about the official reason, but outside of certain 
programming languages that use "array" for one-dimensional data structures, 
an array often has two (or more) dimensions.  In R, for example, arrays can 
have an arbitrary number of dimensions.  Honestly, when I'm away from Java 
for a while and then encounter the term "array" in Java, I have to stop and 
remember that it's 1-D, or check some documentation, because "array" 
doesn't automatically mean 1-D to me.

On the other hand, I believe that vectors are always one-dimensional, as in 
linear algebra.

So maybe Rich Hickey just decided that "vector" was a better, less 
ambiguous name.

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