Re: macro help

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

Re: macro help

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,

Re: macro help

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

Re: macro help

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

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

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

Re: No recent activity for core.async?

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

Re: Towards Greater Code Reuse

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

Re: macro help

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

Re: clojure 1.8 java.lang.VerifyError method: invokeStatic signature: Can only throw Throwable objects

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

Re: Towards Greater Code Reuse

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

Re: prettier stacktraces?

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 >

Re: macro help

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

Re: macro help

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 &

Re: 'seq' performance for 'empty?' compared to 'count'. And where's !=?

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,

Re: macro help

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

Re: Towards Greater Code Reuse

+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

Re: macro help

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

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

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

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

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

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

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

Re: Towards Greater Code Reuse

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

Re: Towards Greater Code Reuse

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

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

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

Re: safety and reusability of clojure.lang.RT, Compiler and co. in multi-classloader environment

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

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

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

Re: Towards Greater Code Reuse

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

cond->: Using of threading expression in tests?

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 -

Re: macro help

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

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

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)

Re: Towards Greater Code Reuse

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

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

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

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 >

The middleware pattern

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

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

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

Re: 'seq' performance for 'empty?' compared to 'count'. And where's !=?

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

Re: The middleware pattern

To follow up on middleware, this is a great picture to demonstrate it. 687474703a2f2f692e737461636b2e696d6775722e636f6d2f68623864422e706e67 On Fri,

Re: The middleware pattern

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,

Re: The middleware pattern

@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

Re: JDK versions for clojure 1.7

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

Re: No recent activity for core.async?

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

JDK versions for clojure 1.7

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

Re: The middleware pattern

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

Re: JDK versions for clojure 1.7

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

Re: safety and reusability of clojure.lang.RT, Compiler and co. in multi-classloader environment

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 >

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

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

Re: The middleware pattern

@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

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

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

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

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