Re: Parsing namespaced XML with clojure.data.xml

[Herwig Hochleitner]

http://dev.clojure.org/jira/browse/CLJ-2030
​

-- 
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: Parsing namespaced XML with clojure.data.xml

[Herwig Hochleitner]

So, your comment about using uri-encoding inspired me to just use that as
an encoding to fit in a kw-ns. It seems to work out:
https://github.com/bendlas/data.xml/commit/22cbe21181175d302c884b4ec9162bd5ebf336d7

There is a couple of open issues, that I commented on the commit.
​
I'll open a dev-thread about the possibility of making clojure.core/alias
auto-creating, with varars and expose it as (ns (:alias al n ak )).
That would make this incarnation of data.xml very convenient to use, as
well as solve similar cases for creating a namespace just for the sake of
naming keywords in them.

-- 
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: Idiom question

[paul]

All very interesting, and Sean that first/or threading pattern is very 
helpful.

@puzzler - totally get that the language is extensible yup and appreciate 
the mainstream warning. When I read your cond-better version I got it; and 
I also thought "a return statement like thing could be useful in a 
construct something like this" and then remembered just how far the macro 
system in lisps lets you go, which was really instructive.

The patterns here are very useful. Thanks again to all of you who offered 
up tips so far.

On Wednesday, September 28, 2016 at 5:53:10 PM UTC-4, Sean Corfield wrote:
>
> Ooops, should be: 
>
> (defn has-transmitters 
>   [^MidiDevice device] 
>   (<= 0 (.getMaxTransmitters device))) 
>
> And if we made a helper for open-device, we could make it return the 
> now-open device and then you wouldn’t need the doto – just call 
> (open-device). 
>
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
>
> "If you're not annoying somebody, you're not really alive." 
> -- Margaret Atwood 
>
> On 9/28/16, 2:48 PM, "Sean Corfield" > 
> wrote: 
>
> And for comparison, here’s a threaded version that uses -> (with ->> 
> embedded, and doto): 
> 
>   (-> (MidiSystem/getMidiDeviceInfo) 
>   (->> (filter #(= (.getName ^MidiDevice$Info %) name)) 
>(map #(MidiSystem/getMidiDevice ^MidDevice$Info %)) 
>(filter #(>= (.getMaxTransmitters ^MidiDevice %) 0))) 
>   (first) 
>   (or (throw (ex-info "No midi devices with recievers" {:name 
> name}))) 
>   (doto (.open)) 
>   (.getReceiver)) 
> 
> Note that I replaced the empty? check by just calling first followed 
> by or/throw. Calling first on an empty sequence produces nil and (or x 
> (throw …)) will yield x if it is not nil (else throw the exception). 
> 
> Also note that you lose the type hints here which may affect 
> performance and/or method resolution (if the calls are ambiguous without 
> the type hints). 
> 
> If the code isn’t performance critical and the calls are still 
> resolvable without type hint, I’d probably omit them just to make the code 
> cleaner. If the hints are needed, then I’d probably defn helpers for the 
> interop calls (with type hinted arguments) to make the code cleaner: 
> 
>   (-> (MidiSystem/getMidiDeviceInfo) 
>   (->> (filter #(= (get-device-name %) name)) 
>(map get-midi-device) 
>(filter #(>= (get-max-transmitters %) 0))) 
>   (first) 
>   (or (throw (ex-info "No midi devices with recievers" {:name 
> name}))) 
>   (doto (open-device)) 
>   (get-receiver)) 
> 
> I’d probably make predicates for the two filter calls: 
> 
> (defn matches-device-name 
>   [name] 
>   (fn [^MidiDevice$Info info] 
> (= name (.getName info 
> 
> (defn has-transmitters 
>   [^MidiDevice$Info info] 
>   (<= 0 (.getMaxTransmitters info))) 
> 
>   (-> (MidiSystem/getMidiDeviceInfo) 
>   (->> (filter (matches-device-name name)) 
>(map get-midi-device) 
>(filter has-transmitters)) 
>   (first) 
>   (or (throw (ex-info "No midi devices with recievers" {:name 
> name}))) 
>   (doto (open-device)) 
>   (get-receiver)) 
> 
> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN 
> An Architect's View -- http://corfield.org/ 
> 
> "If you're not annoying somebody, you're not really alive." 
> -- Margaret Atwood 
> 
> On 9/28/16, 2:12 PM, "clo...@googlegroups.com  on behalf 
> of pa...@pwjw.com "  
> on behalf of pa...@pwjw.com > wrote: 
> 
> This is a super interesting thread. Thank you all for your input 
> 
> I think you are right, @puzzler, that for my case a let may be better. 
> The original code is above. Using as-> it looks like this (using 'it' as 
> the name) 
> 
>   (as-> (MidiSystem/getMidiDeviceInfo) it 
>  (filter #(= (.getName ^MidiDevice$Info %) name) it) 
>  (map #(MidiSystem/getMidiDevice ^MidDevice$Info %) it) 
>  (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0) it) 
>  (if (empty? it) (throw (ex-info "No midi devices with recievers" 
> {:name name})) it) 
>  (first it) 
>  (do (.open ^MidiDevice it) it) 
>  (.getReceiver ^MidiDevice it) 
>  ) 
>) 
> 
> using let it looks like this 
> 
> (let [device-info   (MidiSystem/getMidiDeviceInfo) 
>  named-device-info (filter #(= (.getName ^MidiDevice$Info %) 
> name) device-info) 
>  devices   (map #(MidiSystem/getMidiDevice 
> ^MidDevice$Info %) named-device-info) 
>  receivables   (filter #(>= (.getMaxTransmitters 
> ^MidiDevice %) 0) devices) 
>  _ (when (empty? receivables) (throw (ex-info 
>

Re: Idiom question

[Sean Corfield]

Ooops, should be:

(defn has-transmitters
  [^MidiDevice device]
  (<= 0 (.getMaxTransmitters device)))

And if we made a helper for open-device, we could make it return the now-open 
device and then you wouldn’t need the doto – just call (open-device).

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

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

On 9/28/16, 2:48 PM, "Sean Corfield"  wrote:

And for comparison, here’s a threaded version that uses -> (with ->> 
embedded, and doto):

  (-> (MidiSystem/getMidiDeviceInfo)
  (->> (filter #(= (.getName ^MidiDevice$Info %) name))
   (map #(MidiSystem/getMidiDevice ^MidDevice$Info %))
   (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0)))
  (first)
  (or (throw (ex-info "No midi devices with recievers" {:name name})))
  (doto (.open))
  (.getReceiver))

Note that I replaced the empty? check by just calling first followed by 
or/throw. Calling first on an empty sequence produces nil and (or x (throw …)) 
will yield x if it is not nil (else throw the exception).

Also note that you lose the type hints here which may affect performance 
and/or method resolution (if the calls are ambiguous without the type hints).

If the code isn’t performance critical and the calls are still resolvable 
without type hint, I’d probably omit them just to make the code cleaner. If the 
hints are needed, then I’d probably defn helpers for the interop calls (with 
type hinted arguments) to make the code cleaner:

  (-> (MidiSystem/getMidiDeviceInfo)
  (->> (filter #(= (get-device-name %) name))
   (map get-midi-device)
   (filter #(>= (get-max-transmitters %) 0)))
  (first)
  (or (throw (ex-info "No midi devices with recievers" {:name name})))
  (doto (open-device))
  (get-receiver))

I’d probably make predicates for the two filter calls:

(defn matches-device-name
  [name]
  (fn [^MidiDevice$Info info]
(= name (.getName info

(defn has-transmitters
  [^MidiDevice$Info info]
  (<= 0 (.getMaxTransmitters info)))

  (-> (MidiSystem/getMidiDeviceInfo)
  (->> (filter (matches-device-name name))
   (map get-midi-device)
   (filter has-transmitters))
  (first)
  (or (throw (ex-info "No midi devices with recievers" {:name name})))
  (doto (open-device))
  (get-receiver))

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

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

On 9/28/16, 2:12 PM, "clojure@googlegroups.com on behalf of p...@pwjw.com" 
 wrote:

This is a super interesting thread. Thank you all for your input

I think you are right, @puzzler, that for my case a let may be better. The 
original code is above. Using as-> it looks like this (using 'it' as the name)

  (as-> (MidiSystem/getMidiDeviceInfo) it
 (filter #(= (.getName ^MidiDevice$Info %) name) it)
 (map #(MidiSystem/getMidiDevice ^MidDevice$Info %) it)
 (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0) it)
 (if (empty? it) (throw (ex-info "No midi devices with recievers" 
{:name name})) it)
 (first it)
 (do (.open ^MidiDevice it) it)
 (.getReceiver ^MidiDevice it)
 )
   )

using let it looks like this

(let [device-info   (MidiSystem/getMidiDeviceInfo) 
 named-device-info (filter #(= (.getName ^MidiDevice$Info %) name) 
device-info)
 devices   (map #(MidiSystem/getMidiDevice ^MidDevice$Info 
%) named-device-info)
 receivables   (filter #(>= (.getMaxTransmitters ^MidiDevice %) 
0) devices)
 _ (when (empty? receivables) (throw (ex-info "No 
midi devices with recievers" {:name name})))
 receivable(first receivables)
 result(do 
 (.open ^MidiDevice receivable)
 (.getReceiver ^MidiDevice receivable))]
 result)

and if I were doing a code review, I think I would like the last one better.

How very interesting. Thanks all for your constructive answers. What a 
great community.







-- 
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: Idiom question

[Sean Corfield]

And for comparison, here’s a threaded version that uses -> (with ->> embedded, 
and doto):

  (-> (MidiSystem/getMidiDeviceInfo)
  (->> (filter #(= (.getName ^MidiDevice$Info %) name))
   (map #(MidiSystem/getMidiDevice ^MidDevice$Info %))
   (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0)))
  (first)
  (or (throw (ex-info "No midi devices with recievers" {:name name})))
  (doto (.open))
  (.getReceiver))

Note that I replaced the empty? check by just calling first followed by 
or/throw. Calling first on an empty sequence produces nil and (or x (throw …)) 
will yield x if it is not nil (else throw the exception).

Also note that you lose the type hints here which may affect performance and/or 
method resolution (if the calls are ambiguous without the type hints).

If the code isn’t performance critical and the calls are still resolvable 
without type hint, I’d probably omit them just to make the code cleaner. If the 
hints are needed, then I’d probably defn helpers for the interop calls (with 
type hinted arguments) to make the code cleaner:

  (-> (MidiSystem/getMidiDeviceInfo)
  (->> (filter #(= (get-device-name %) name))
   (map get-midi-device)
   (filter #(>= (get-max-transmitters %) 0)))
  (first)
  (or (throw (ex-info "No midi devices with recievers" {:name name})))
  (doto (open-device))
  (get-receiver))

I’d probably make predicates for the two filter calls:

(defn matches-device-name
  [name]
  (fn [^MidiDevice$Info info]
(= name (.getName info

(defn has-transmitters
  [^MidiDevice$Info info]
  (<= 0 (.getMaxTransmitters info)))

  (-> (MidiSystem/getMidiDeviceInfo)
  (->> (filter (matches-device-name name))
   (map get-midi-device)
   (filter has-transmitters))
  (first)
  (or (throw (ex-info "No midi devices with recievers" {:name name})))
  (doto (open-device))
  (get-receiver))

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

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

On 9/28/16, 2:12 PM, "clojure@googlegroups.com on behalf of p...@pwjw.com" 
 wrote:

This is a super interesting thread. Thank you all for your input

I think you are right, @puzzler, that for my case a let may be better. The 
original code is above. Using as-> it looks like this (using 'it' as the name)

  (as-> (MidiSystem/getMidiDeviceInfo) it
     (filter #(= (.getName ^MidiDevice$Info %) name) it)
     (map #(MidiSystem/getMidiDevice ^MidDevice$Info %) it)
     (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0) it)
     (if (empty? it) (throw (ex-info "No midi devices with recievers" {:name 
name})) it)
     (first it)
     (do (.open ^MidiDevice it) it)
     (.getReceiver ^MidiDevice it)
     )
   )

using let it looks like this

(let [device-info       (MidiSystem/getMidiDeviceInfo) 
         named-device-info (filter #(= (.getName ^MidiDevice$Info %) name) 
device-info)
         devices           (map #(MidiSystem/getMidiDevice ^MidDevice$Info %) 
named-device-info)
         receivables       (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0) 
devices)
         _                 (when (empty? receivables) (throw (ex-info "No midi 
devices with recievers" {:name name})))
         receivable        (first receivables)
         result            (do 
                             (.open ^MidiDevice receivable)
                             (.getReceiver ^MidiDevice receivable))]
     result)

and if I were doing a code review, I think I would like the last one better.

How very interesting. Thanks all for your constructive answers. What a great 
community.




-- 
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: Idiom question

[Mark Engelberg]

Right, and just to take this one step farther, imagine that instead of
throwing an error, you wanted to actually return a value.  And imagine that
your call to MidiSystem/getMidiDeviceInfo might return nil as well, and
this is something that needs to be protected against and a value returned
accordingly.  These sorts of intertwinings of conditional logic and chains
of computations is exactly when I reach for better-cond, which would make
it look like this:
(cond
  :let [device-info   (MidiSystem/getMidiDeviceInfo)]

  (nil? device-info) :device-not-available

  :let [named-device-info (filter #(= (.getName ^MidiDevice$Info %) name)
device-info)
devices   (map #(MidiSystem/getMidiDevice ^MidDevice$Info
%) named-device-info)
receivables   (filter #(>= (.getMaxTransmitters ^MidiDevice %)
0) devices)]

  (empty? receivables) :no-receivers

  :let [receivable(first receivables)]
  (do
(.open ^MidiDevice receivable)
(.getReceiver ^MidiDevice receivable)))

Since you're new to the community, I want to be sure not to mislead you --
the above example is not mainstream Clojure code.  But it's a great example
of how you can mold the language to suit your own taste of what is
readable.  The above example is my preferred way to write these sorts of
things.

On Wed, Sep 28, 2016 at 2:12 PM,  wrote:

> This is a super interesting thread. Thank you all for your input
>
> I think you are right, @puzzler, that for my case a let may be better. The
> original code is above. Using as-> it looks like this (using 'it' as the
> name)
>
>   (as-> (MidiSystem/getMidiDeviceInfo) it
>  (filter #(= (.getName ^MidiDevice$Info %) name) it)
>  (map #(MidiSystem/getMidiDevice ^MidDevice$Info %) it)
>  (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0) it)
>  (if (empty? it) (throw (ex-info "No midi devices with recievers"
> {:name name})) it)
>  (first it)
>  (do (.open ^MidiDevice it) it)
>  (.getReceiver ^MidiDevice it)
>  )
>)
>
> using let it looks like this
>
> (let [device-info   (MidiSystem/getMidiDeviceInfo)
>  named-device-info (filter #(= (.getName ^MidiDevice$Info %) name)
> device-info)
>  devices   (map #(MidiSystem/getMidiDevice ^MidDevice$Info
> %) named-device-info)
>  receivables   (filter #(>= (.getMaxTransmitters ^MidiDevice
> %) 0) devices)
>  _ (when (empty? receivables) (throw (ex-info "No
> midi devices with recievers" {:name name})))
>  receivable(first receivables)
>  result(do
>  (.open ^MidiDevice receivable)
>  (.getReceiver ^MidiDevice receivable))]
>  result)
>
> and if I were doing a code review, I think I would like the last one
> better.
>
> How very interesting. Thanks all for your constructive answers. What a
> great community.
>
> On Wednesday, September 28, 2016 at 4:47:22 PM UTC-4, puzzler wrote:
>>
>> A common convention with as-> is to use the symbol $ because it is
>> recognized as a Clojure identifier but looks distinctive, so it stands out
>> as the placeholder of where to thread.
>>
>> Personally, when reading code, I don't really like to see long uses of
>> the threading operator, and I'd argue that if you find yourself using such
>> long chains of computations that the "important" argument is switching to
>> different positions, that's a sign that maybe you shouldn't be using
>> threading operators in the first place, because it can be hard to mentally
>> follow what intermediate data structure you have at each stage of the
>> computation.  Instead, I'd argue that you should be using `let`, because
>> `let` allows you to give each stage of computation a meaningful name,
>> making it easy for others (or yourself in two months) to read and reason
>> about your code.  `let` allows you to communicate intent.
>>
>> I think one reason people sometimes shy away from using `let` is that it
>> can't easily be used at all positions within one's code.  For example, if
>> you are inside a `cond`  doing some conditional logic, adding a `let` means
>> you have to also start a new `cond`, and your code ends up awkwardly nested
>> and indented, drifting to the right.   The better-cond library removes this
>> limitation, making it easy to write clear functions which intermingle long
>> chains of computations with conditional logic:
>> https://github.com/Engelberg/better-cond
>>
> --
> 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 Go

Re: Idiom question

[Josh Tilles]

By the way, the order of arguments of as-> makes more sense when it’s used 
*within* one of the other threading macros. For example:
(-> x
  foo
  (bar y)
  (baz w z)
  (as-> mid-x
(log/debug "The intermediate value:" mid-x)
(if (color-requested? mid-x)
  (assoc mid-x :color "periwinkle")
  (do
(log/warn "skipping the addition of color")
mid-x)))
  (update :counter inc))


On Wednesday, September 28, 2016 at 4:11:42 PM UTC-4, pa...@pwjw.com wrote:
>
> Wow yes that's exactly the -%> macro I imagined just with "%" replaced 
> with "it". And it exists!  Plus I just converted my fragment to use as-> 
> and thought "aren't the first two arguments backwards (vs, say, "let"); and 
> what name should I use (I chose 's')". Thank you. Reading the tupelo docs 
> now.
>
> On Wednesday, September 28, 2016 at 4:02:38 PM UTC-4, Alan Thompson wrote:
>>
>> Hi Paul,
>>
>> Since you are interested in the threading macros, you might like to take 
>> a look at one of my favorite variants from the Tupelo library 
>> :
>>
>> Literate Threading Macro
>>
>> We all love to use the threading macros -> and ->> for certain tasks, 
>> but they only work if all of the forms should be threaded into the first or 
>> last argument.
>>
>> The built-in threading macro as-> can avoid this requirement, but the 
>> order of the first expression and the placeholder symbol is arguably 
>> backwards from what users would expect. Also, there is often no obvious 
>> name to use for the placeholder symbol. Re-using a good idea from Groovy, 
>> we simply use the symbol it as the placeholder symbol in each expression 
>> to represent the value of the previous result.
>>
>> (it-> 1
>>   (inc it)  ; thread-first or thread-last
>>   (+ it 3)  ; thread-first
>>   (/ 10 it) ; thread-last
>>   (str "We need to order " it " items." )   ; middle of 3 arguments;=> 
>> "We need to order 2 items." )
>>
>> Here is a more complicated example. Note that we can assign into a local 
>> let block from the it placeholder value:
>>
>> (it-> 3
>>   (spy :msg :initial it)
>>   (let [x it]
>> (inc x))
>>   (spy it :msg 222)
>>   (* it 2)
>>   (spyx it)); :initial => 3; 222 => 4; it => 88   ; return value
>>
>> Note that the :msg argument does not need to be a string. As shown 
>> above, keywords, integers, etc may be used.
>> Alan
>>
>>
>> On Wed, Sep 28, 2016 at 11:36 AM, Colin Yates  wrote:
>>
>>> Welcome to one of the best things about Clojure - the community. 
>>> However, if anyone starts using the phrase 'Clojurian' then it is time to 
>>> leave :-).
>>>
>>>
>>>
>>> On Wed, 28 Sep 2016, at 07:17 PM, pa...@pwjw.com wrote:
>>>
>>> Wow thank you all for the really useful responses. How great. I 
>>> appreciate the time.
>>>
>>> as-> cleans up a couple of ugly bits of my code already, yes. And I'm 
>>> sort of irritated with myself for not thinking of _ (if (throw)) in my let 
>>> but yes that's a perfect idiom.
>>>
>>>
>>> I totally get the minimalist approach in clojure.test and like it. In 
>>> fact, the ease of testing (and how easy it is to get coverage running with 
>>> cloverage) is one of the things I find the most impressive. expectations 
>>> looks interesting though too for a lot of my tests and I'll spend some time 
>>> with it too.
>>>
>>> The idiom of "most important is first unless its a sequence then it is 
>>> last" is really natural too; but I think it's what makes me end up 
>>> switching from ->> to ->. Putting a "first" in the middle of a ->> 
>>> expression is, I suppose, a hint that I'm switching.  Looking at my code, 
>>> it really seems to be a mix of ->> and "doto" that I'm looking for. Here's 
>>> a fragment, for instance, that returns me an opened instance of the first 
>>> core midi device with a name that can receive messages. (and I know I 
>>> should error check that there is one after that filter... that's on my todo 
>>> list). An "as-> doto" pair would help and I'll get right on that later on 
>>> this week.
>>>
>>> (->> (MidiSystem/getMidiDeviceInfo)
>>>
>>> (filter #(= (.getName ^MidiDevice$Info %) name))
>>>
>>> (map #(MidiSystem/getMidiDevice ^MidDevice$Info %))
>>>
>>> (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0))
>>>
>>> first
>>>
>>> (#(do (.open ^MidiDevice %) %))
>>>
>>> (#(.getReceiver ^MidiDevice %))
>>>
>>> )
>>>
>>> Anyway, wow thanks again for all the responses!
>>>
>>>
>>>
>>>
>>>
>>> On Wednesday, September 28, 2016 at 10:31:37 AM UTC-4, pa...@pwjw.com 
>>> wrote:
>>>
>>> Hi.
>>>
>>> I'm new to clojure, and it is quite lovely. The threading model is 
>>> great, the emacs integration is super, and the tasteful lisp extensions are 
>>> good. A very nice programming environment all around. 
>>>
>>> But as I write more code I f

Re: Idiom question

[paul]

This is a super interesting thread. Thank you all for your input

I think you are right, @puzzler, that for my case a let may be better. The 
original code is above. Using as-> it looks like this (using 'it' as the 
name)

  (as-> (MidiSystem/getMidiDeviceInfo) it
 (filter #(= (.getName ^MidiDevice$Info %) name) it)
 (map #(MidiSystem/getMidiDevice ^MidDevice$Info %) it)
 (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0) it)
 (if (empty? it) (throw (ex-info "No midi devices with recievers" 
{:name name})) it)
 (first it)
 (do (.open ^MidiDevice it) it)
 (.getReceiver ^MidiDevice it)
 )
   )

using let it looks like this

(let [device-info   (MidiSystem/getMidiDeviceInfo) 
 named-device-info (filter #(= (.getName ^MidiDevice$Info %) name) 
device-info)
 devices   (map #(MidiSystem/getMidiDevice ^MidDevice$Info 
%) named-device-info)
 receivables   (filter #(>= (.getMaxTransmitters ^MidiDevice %) 
0) devices)
 _ (when (empty? receivables) (throw (ex-info "No 
midi devices with recievers" {:name name})))
 receivable(first receivables)
 result(do 
 (.open ^MidiDevice receivable)
 (.getReceiver ^MidiDevice receivable))]
 result)

and if I were doing a code review, I think I would like the last one better.

How very interesting. Thanks all for your constructive answers. What a 
great community.

On Wednesday, September 28, 2016 at 4:47:22 PM UTC-4, puzzler wrote:
>
> A common convention with as-> is to use the symbol $ because it is 
> recognized as a Clojure identifier but looks distinctive, so it stands out 
> as the placeholder of where to thread.
>
> Personally, when reading code, I don't really like to see long uses of the 
> threading operator, and I'd argue that if you find yourself using such long 
> chains of computations that the "important" argument is switching to 
> different positions, that's a sign that maybe you shouldn't be using 
> threading operators in the first place, because it can be hard to mentally 
> follow what intermediate data structure you have at each stage of the 
> computation.  Instead, I'd argue that you should be using `let`, because 
> `let` allows you to give each stage of computation a meaningful name, 
> making it easy for others (or yourself in two months) to read and reason 
> about your code.  `let` allows you to communicate intent.
>
> I think one reason people sometimes shy away from using `let` is that it 
> can't easily be used at all positions within one's code.  For example, if 
> you are inside a `cond`  doing some conditional logic, adding a `let` means 
> you have to also start a new `cond`, and your code ends up awkwardly nested 
> and indented, drifting to the right.   The better-cond library removes this 
> limitation, making it easy to write clear functions which intermingle long 
> chains of computations with conditional logic: 
> https://github.com/Engelberg/better-cond
>

-- 
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: Idiom question

[Mark Engelberg]

A common convention with as-> is to use the symbol $ because it is
recognized as a Clojure identifier but looks distinctive, so it stands out
as the placeholder of where to thread.

Personally, when reading code, I don't really like to see long uses of the
threading operator, and I'd argue that if you find yourself using such long
chains of computations that the "important" argument is switching to
different positions, that's a sign that maybe you shouldn't be using
threading operators in the first place, because it can be hard to mentally
follow what intermediate data structure you have at each stage of the
computation.  Instead, I'd argue that you should be using `let`, because
`let` allows you to give each stage of computation a meaningful name,
making it easy for others (or yourself in two months) to read and reason
about your code.  `let` allows you to communicate intent.

I think one reason people sometimes shy away from using `let` is that it
can't easily be used at all positions within one's code.  For example, if
you are inside a `cond`  doing some conditional logic, adding a `let` means
you have to also start a new `cond`, and your code ends up awkwardly nested
and indented, drifting to the right.   The better-cond library removes this
limitation, making it easy to write clear functions which intermingle long
chains of computations with conditional logic:
https://github.com/Engelberg/better-cond

-- 
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: Idiom question

[paul]

Wow yes that's exactly the -%> macro I imagined just with "%" replaced with 
"it". And it exists!  Plus I just converted my fragment to use as-> and 
thought "aren't the first two arguments backwards (vs, say, "let"); and 
what name should I use (I chose 's')". Thank you. Reading the tupelo docs 
now.

On Wednesday, September 28, 2016 at 4:02:38 PM UTC-4, Alan Thompson wrote:
>
> Hi Paul,
>
> Since you are interested in the threading macros, you might like to take a 
> look at one of my favorite variants from the Tupelo library 
> :
>
> Literate Threading Macro
>
> We all love to use the threading macros -> and ->> for certain tasks, but 
> they only work if all of the forms should be threaded into the first or 
> last argument.
>
> The built-in threading macro as-> can avoid this requirement, but the 
> order of the first expression and the placeholder symbol is arguably 
> backwards from what users would expect. Also, there is often no obvious 
> name to use for the placeholder symbol. Re-using a good idea from Groovy, 
> we simply use the symbol it as the placeholder symbol in each expression 
> to represent the value of the previous result.
>
> (it-> 1
>   (inc it)  ; thread-first or thread-last
>   (+ it 3)  ; thread-first
>   (/ 10 it) ; thread-last
>   (str "We need to order " it " items." )   ; middle of 3 arguments;=> 
> "We need to order 2 items." )
>
> Here is a more complicated example. Note that we can assign into a local 
> let block from the it placeholder value:
>
> (it-> 3
>   (spy :msg :initial it)
>   (let [x it]
> (inc x))
>   (spy it :msg 222)
>   (* it 2)
>   (spyx it)); :initial => 3; 222 => 4; it => 88   ; return value
>
> Note that the :msg argument does not need to be a string. As shown above, 
> keywords, integers, etc may be used.
> Alan
>
>
> On Wed, Sep 28, 2016 at 11:36 AM, Colin Yates  > wrote:
>
>> Welcome to one of the best things about Clojure - the community. However, 
>> if anyone starts using the phrase 'Clojurian' then it is time to leave :-).
>>
>>
>>
>> On Wed, 28 Sep 2016, at 07:17 PM, pa...@pwjw.com  wrote:
>>
>> Wow thank you all for the really useful responses. How great. I 
>> appreciate the time.
>>
>> as-> cleans up a couple of ugly bits of my code already, yes. And I'm 
>> sort of irritated with myself for not thinking of _ (if (throw)) in my let 
>> but yes that's a perfect idiom.
>>
>>
>> I totally get the minimalist approach in clojure.test and like it. In 
>> fact, the ease of testing (and how easy it is to get coverage running with 
>> cloverage) is one of the things I find the most impressive. expectations 
>> looks interesting though too for a lot of my tests and I'll spend some time 
>> with it too.
>>
>> The idiom of "most important is first unless its a sequence then it is 
>> last" is really natural too; but I think it's what makes me end up 
>> switching from ->> to ->. Putting a "first" in the middle of a ->> 
>> expression is, I suppose, a hint that I'm switching.  Looking at my code, 
>> it really seems to be a mix of ->> and "doto" that I'm looking for. Here's 
>> a fragment, for instance, that returns me an opened instance of the first 
>> core midi device with a name that can receive messages. (and I know I 
>> should error check that there is one after that filter... that's on my todo 
>> list). An "as-> doto" pair would help and I'll get right on that later on 
>> this week.
>>
>> (->> (MidiSystem/getMidiDeviceInfo)
>>
>> (filter #(= (.getName ^MidiDevice$Info %) name))
>>
>> (map #(MidiSystem/getMidiDevice ^MidDevice$Info %))
>>
>> (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0))
>>
>> first
>>
>> (#(do (.open ^MidiDevice %) %))
>>
>> (#(.getReceiver ^MidiDevice %))
>>
>> )
>>
>> Anyway, wow thanks again for all the responses!
>>
>>
>>
>>
>>
>> On Wednesday, September 28, 2016 at 10:31:37 AM UTC-4, pa...@pwjw.com 
>> wrote:
>>
>> Hi.
>>
>> I'm new to clojure, and it is quite lovely. The threading model is great, 
>> the emacs integration is super, and the tasteful lisp extensions are good. 
>> A very nice programming environment all around. 
>>
>> But as I write more code I find a couple of structures I'm using a lot 
>> which seem related to me not knowing idioms for a couple of uses cases. So 
>> thought I'd ask and see if you have any suggestions. 
>>
>> Apologies if this is covered elsewhere. And if I should read some 
>> existing documentation I didn't find, I apologize for missing it. And 
>> thanks in advance for your time reading!
>>
>> First the thrush operators (-> and ->>) are super handy. But I find 
>> myself needing to 'move' arguments every now and then. So I get code which 
>> looks like
>>
>> (->> blah
>>  (do-this)
>>  (do-that arg)
>>  ((fn [s

Re: Idiom question

[Alan Thompson]

Hi Paul,

Since you are interested in the threading macros, you might like to take a
look at one of my favorite variants from the Tupelo library
:

Literate Threading Macro

We all love to use the threading macros -> and ->> for certain tasks, but
they only work if all of the forms should be threaded into the first or
last argument.

The built-in threading macro as-> can avoid this requirement, but the order
of the first expression and the placeholder symbol is arguably backwards
from what users would expect. Also, there is often no obvious name to use
for the placeholder symbol. Re-using a good idea from Groovy, we simply use
the symbol it as the placeholder symbol in each expression to represent the
value of the previous result.

(it-> 1
  (inc it)  ; thread-first or thread-last
  (+ it 3)  ; thread-first
  (/ 10 it) ; thread-last
  (str "We need to order " it " items." )   ; middle of 3
arguments;=> "We need to order 2 items." )

Here is a more complicated example. Note that we can assign into a
local let block
from the it placeholder value:

(it-> 3
  (spy :msg :initial it)
  (let [x it]
(inc x))
  (spy it :msg 222)
  (* it 2)
  (spyx it)); :initial => 3; 222 => 4; it => 88   ; return value

Note that the :msg argument does not need to be a string. As shown above,
keywords, integers, etc may be used.
Alan


On Wed, Sep 28, 2016 at 11:36 AM, Colin Yates  wrote:

> Welcome to one of the best things about Clojure - the community. However,
> if anyone starts using the phrase 'Clojurian' then it is time to leave :-).
>
>
>
> On Wed, 28 Sep 2016, at 07:17 PM, p...@pwjw.com wrote:
>
> Wow thank you all for the really useful responses. How great. I appreciate
> the time.
>
> as-> cleans up a couple of ugly bits of my code already, yes. And I'm sort
> of irritated with myself for not thinking of _ (if (throw)) in my let but
> yes that's a perfect idiom.
>
>
> I totally get the minimalist approach in clojure.test and like it. In
> fact, the ease of testing (and how easy it is to get coverage running with
> cloverage) is one of the things I find the most impressive. expectations
> looks interesting though too for a lot of my tests and I'll spend some time
> with it too.
>
> The idiom of "most important is first unless its a sequence then it is
> last" is really natural too; but I think it's what makes me end up
> switching from ->> to ->. Putting a "first" in the middle of a ->>
> expression is, I suppose, a hint that I'm switching.  Looking at my code,
> it really seems to be a mix of ->> and "doto" that I'm looking for. Here's
> a fragment, for instance, that returns me an opened instance of the first
> core midi device with a name that can receive messages. (and I know I
> should error check that there is one after that filter... that's on my todo
> list). An "as-> doto" pair would help and I'll get right on that later on
> this week.
>
> (->> (MidiSystem/getMidiDeviceInfo)
>
> (filter #(= (.getName ^MidiDevice$Info %) name))
>
> (map #(MidiSystem/getMidiDevice ^MidDevice$Info %))
>
> (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0))
>
> first
>
> (#(do (.open ^MidiDevice %) %))
>
> (#(.getReceiver ^MidiDevice %))
>
> )
>
> Anyway, wow thanks again for all the responses!
>
>
>
>
>
> On Wednesday, September 28, 2016 at 10:31:37 AM UTC-4, pa...@pwjw.com
> wrote:
>
> Hi.
>
> I'm new to clojure, and it is quite lovely. The threading model is great,
> the emacs integration is super, and the tasteful lisp extensions are good.
> A very nice programming environment all around.
>
> But as I write more code I find a couple of structures I'm using a lot
> which seem related to me not knowing idioms for a couple of uses cases. So
> thought I'd ask and see if you have any suggestions.
>
> Apologies if this is covered elsewhere. And if I should read some existing
> documentation I didn't find, I apologize for missing it. And thanks in
> advance for your time reading!
>
> First the thrush operators (-> and ->>) are super handy. But I find myself
> needing to 'move' arguments every now and then. So I get code which looks
> like
>
> (->> blah
>  (do-this)
>  (do-that arg)
>  ((fn [s] (rearrange arg s arg
>
> quite a lot.The alternate is a big nested let like
>
>  (let  [ first   (blah)
>   second  (do-this first)
>   ...
>   result  (wrap-it-up fourteenth) ]
> result)
>
> for sort of sequential application where arguments fall in different
> 'spots'. So I sort of find myself wanting to write a 'positional-thrush'
> macro like
>
> (-%> blah
>  (do-this %)
>  (do-that arg %)
>  (do-the-other a1 % a2))
>
> where % is replaced with the output of the prior. But no such operator
> exists as far as I can see. So eit

Re: Idiom question

[Colin Yates]

Welcome to one of the best things about Clojure - the community.
However, if anyone starts using the phrase 'Clojurian' then it is time
to leave :-).



On Wed, 28 Sep 2016, at 07:17 PM, p...@pwjw.com wrote:
> Wow thank you all for the really useful responses. How great. I
> appreciate the time.
>
> as-> cleans up a couple of ugly bits of my code already, yes. And I'm
> sort of irritated with myself for not thinking of _ (if (throw)) in my
> let but yes that's a perfect idiom.
>
>
> I totally get the minimalist approach in clojure.test and like it. In
> fact, the ease of testing (and how easy it is to get coverage running
> with cloverage) is one of the things I find the most impressive.
> expectations looks interesting though too for a lot of my tests and
> I'll spend some time with it too.
>
> The idiom of "most important is first unless its a sequence then it is
> last" is really natural too; but I think it's what makes me end up
> switching from ->> to ->. Putting a "first" in the middle of a ->>
> expression is, I suppose, a hint that I'm switching.  Looking at my
> code, it really seems to be a mix of ->> and "doto" that I'm looking
> for. Here's a fragment, for instance, that returns me an opened
> instance of the first core midi device with a name that can receive
> messages. (and I know I should error check that there is one after
> that filter... that's on my todo list). An "as-> doto" pair would help
> and I'll get right on that later on this week.
>
> (->> (MidiSystem/getMidiDeviceInfo)
> (filter #(= (.getName ^MidiDevice$Info %) name))
> (map #(MidiSystem/getMidiDevice ^MidDevice$Info %))
> (filter #(>= (.getMaxTransmitters ^MidiDevice %) 0))
> first
> (#(do (.open ^MidiDevice %) %))
> (#(.getReceiver ^MidiDevice %))
> )
>
> Anyway, wow thanks again for all the responses!
>
>
>
>
>
> On Wednesday, September 28, 2016 at 10:31:37 AM UTC-4,
> pa...@pwjw.com wrote:
>> Hi.
>>
>> I'm new to clojure, and it is quite lovely. The threading model is
>> great, the emacs integration is super, and the tasteful lisp
>> extensions are good. A very nice programming environment all around.
>>
>> But as I write more code I find a couple of structures I'm using a
>> lot which seem related to me not knowing idioms for a couple of uses
>> cases. So thought I'd ask and see if you have any suggestions.
>>
>> Apologies if this is covered elsewhere. And if I should read some
>> existing documentation I didn't find, I apologize for missing it. And
>> thanks in advance for your time reading!
>>
>> First the thrush operators (-> and ->>) are super handy. But I find
>> myself needing to 'move' arguments every now and then. So I get code
>> which looks like
>>
>> (->> blah
>>  (do-this)
>>  (do-that arg)
>>  ((fn [s] (rearrange arg s arg
>>
>> quite a lot.The alternate is a big nested let like
>>
>>  (let  [ first   (blah)
>>   second  (do-this first)
>>   ...
>>   result  (wrap-it-up fourteenth) ]
>> result)
>>
>> for sort of sequential application where arguments fall in different
>> 'spots'. So I sort of find myself wanting to write a 'positional-
>> thrush' macro like
>>
>> (-%> blah
>>  (do-this %)
>>  (do-that arg %)
>>  (do-the-other a1 % a2))
>>
>> where % is replaced with the output of the prior. But no such
>> operator exists as far as I can see. So either I've had a good idea
>> (which is unlikely since I'm super new to the language) or there's
>> some other idiom you all use for this pattern which I've missed.
>>
>> The second is smaller, but is more a question. clojure.test seems to
>> only have 'is' so for things like equality I end up writing (is (=
>> (...) (...))) a lot. Or to test if an exception is thrown (is
>> (thrown? ...)). That's OK, but I'm wondering what led to that
>> decision rather than having is-eq and is-thrown and so on
>> (considering the core language has shortcuts like when and unless and
>> if-not so the compound macros seem idiomatic).
>>
>> The last is sort of related to the first. Sometimes I'm assembling a
>> data structure in a set of operators and I write them with a let or a
>> -> and half way through I have an error condition I want to check. In
>> a mutable procedural language you would do something like
>>
>>   x = blah
>>   y = bim
>>   if (! (condition (y))) throw "y doesn't meet condition"
>>   z = blob
>>
>> I don't see a good idiom for this. I have to split and nest lets for
>> instance
>>
>> (let [x (blah) y (bim) ]
>>   (if (condition (y)) (throw ...)
>>  (let [ z (blob) ]
>>   ))
>>
>> which seems a bit ugly.  I sort of want a let-with-test or a thrush-with-
>> test so something which looks like
>>
>> (-%?>  (init)
>>  (operator-1 %)  (post-condition)
>>  (operator-2 %)  (post-condition) )
>>
>> where if I don't have a post condition I could just use 'true'. Then
>> this expands to doing a quick '(if (not (postcondition (intermedia-
>> result))

Re: Idiom question

[paul]

Wow thank you all for the really useful responses. How great. I appreciate 
the time.

as-> cleans up a couple of ugly bits of my code already, yes. And I'm sort 
of irritated with myself for not thinking of _ (if (throw)) in my let but 
yes that's a perfect idiom.


I totally get the minimalist approach in clojure.test and like it. In fact, 
the ease of testing (and how easy it is to get coverage running with 
cloverage) is one of the things I find the most impressive. expectations 
looks interesting though too for a lot of my tests and I'll spend some time 
with it too.

The idiom of "most important is first unless its a sequence then it is 
last" is really natural too; but I think it's what makes me end up 
switching from ->> to ->. Putting a "first" in the middle of a ->> 
expression is, I suppose, a hint that I'm switching.  Looking at my code, 
it really seems to be a mix of ->> and "doto" that I'm looking for. Here's 
a fragment, for instance, that returns me an opened instance of the first 
core midi device with a name that can receive messages. (and I know I 
should error check that there is one after that filter... that's on my todo 
list). An "as-> doto" pair would help and I'll get right on that later on 
this week.

(->> (MidiSystem/getMidiDeviceInfo)

(filter #(= (.getName ^MidiDevice$Info %) name))

(map #(MidiSystem/getMidiDevice ^MidDevice$Info %))

(filter #(>= (.getMaxTransmitters ^MidiDevice %) 0))

first

(#(do (.open ^MidiDevice %) %))

(#(.getReceiver ^MidiDevice %))

)

Anyway, wow thanks again for all the responses!





On Wednesday, September 28, 2016 at 10:31:37 AM UTC-4, pa...@pwjw.com wrote:
>
> Hi.
>
> I'm new to clojure, and it is quite lovely. The threading model is great, 
> the emacs integration is super, and the tasteful lisp extensions are good. 
> A very nice programming environment all around. 
>
> But as I write more code I find a couple of structures I'm using a lot 
> which seem related to me not knowing idioms for a couple of uses cases. So 
> thought I'd ask and see if you have any suggestions. 
>
> Apologies if this is covered elsewhere. And if I should read some existing 
> documentation I didn't find, I apologize for missing it. And thanks in 
> advance for your time reading!
>
> First the thrush operators (-> and ->>) are super handy. But I find myself 
> needing to 'move' arguments every now and then. So I get code which looks 
> like
>
> (->> blah
>  (do-this)
>  (do-that arg)
>  ((fn [s] (rearrange arg s arg
>
> quite a lot.The alternate is a big nested let like
>
>  (let  [ first   (blah)
>   second  (do-this first)
>   ...
>   result  (wrap-it-up fourteenth) ]
> result)
>
> for sort of sequential application where arguments fall in different 
> 'spots'. So I sort of find myself wanting to write a 'positional-thrush' 
> macro like
>
> (-%> blah
>  (do-this %)
>  (do-that arg %)
>  (do-the-other a1 % a2))
>
> where % is replaced with the output of the prior. But no such operator 
> exists as far as I can see. So either I've had a good idea (which is 
> unlikely since I'm super new to the language) or there's some other idiom 
> you all use for this pattern which I've missed.
>
> The second is smaller, but is more a question. clojure.test seems to only 
> have 'is' so for things like equality I end up writing (is (= (...) (...))) 
> a lot. Or to test if an exception is thrown (is (thrown? ...)). That's OK, 
> but I'm wondering what led to that decision rather than having is-eq and 
> is-thrown and so on (considering the core language has shortcuts like when 
> and unless and if-not so the compound macros seem idiomatic).
>
> The last is sort of related to the first. Sometimes I'm assembling a data 
> structure in a set of operators and I write them with a let or a -> and 
> half way through I have an error condition I want to check. In a mutable 
> procedural language you would do something like
>
>   x = blah
>   y = bim
>   if (! (condition (y))) throw "y doesn't meet condition"
>   z = blob
>
> I don't see a good idiom for this. I have to split and nest lets for 
> instance
>
> (let [x (blah) y (bim) ]
>   (if (condition (y)) (throw ...)
>  (let [ z (blob) ] 
>   ))
>
> which seems a bit ugly.  I sort of want a let-with-test or a 
> thrush-with-test so something which looks like
>
> (-%?>  (init)
>  (operator-1 %)  (post-condition)
>  (operator-2 %)  (post-condition) )
>
> where if I don't have a post condition I could just use 'true'. Then this 
> expands to doing a quick '(if (not (postcondition (intermedia-result 
> throw...)
>
> but that's a crazy thing to want. So curious how you all tackle this.
>
> Thank you all for your consideration. And apologies again if this is 
> covered elsewhere or I should have asked in a different forum.
>
> Best,
>
>   Paul
>

-- 
You received this message because you are subscribed to the 

Re: Idiom question

[Sean Corfield]

Welcome to Clojure!

As others have noted, there are quite a few threading macros so your example 
could become:

(-> blah
(do-this)
(->> (do-that arg))
(as-> s (do-the-other a1 s a2)))

Or:

(-> (->> blah
 (do-this)
 (do-that arg))
(as-> s (do-the-other a1 s a2)))

How elegant the result ends up being will depend on exactly how many first 
position, last position, and “in the middle” position your expressions are. One 
thing to be aware of is that, idiomatically, Clojure tries to follow the 
pattern that the “important” argument is always the first one (the thing being 
“operated on”), except for collection functions where it is always the last 
one. The former lends itself to -> and the latter to ->> (and partial) so if 
you have an expression that seems to be a mixture of both, think hard about 
whether the functions are following that idiom.

In your example, if blah is a collection, then do-the-other probably ought to 
be:

(do-the-other a1 a2 coll)
   ;; and use ->> blah across all three calls

If blah is the “important” argument, then maybe do-that and do-the-other should 
have it consistently in the first position:

(do-that s arg)
(do-the-other s a1 a2)
;; and use -> blah across all three calls

If you still need to mix -> and ->> perhaps break the expression up and use let 
to bind appropriate names to the subexpressions for clarity of intent.

For the conditional throw code, I’d suggest two possible alternatives:

(let [x blah
  y bim
  _ (when-not (condition y) (throw …))
  z blob]
  …)

The _ is just a convention for “this is unused”. Or, if your blob does not 
depend on y, simply reorder things:

(let [x blah
  y bim
  z blob]
  (when-not (condition y) (throw …))
  …)

As for clojure.test/is – if you want something a bit more expressive that is 
still concise, I’d recommend Expectations http://jayfields.com/expectations/ -- 
we switched to this from clojure.test several years ago and we’ve been very 
happy with it:

(expect value expression)
(expect predicate? expression)
(expect SomeException expression)

To us, that’s a very natural way to write tests. clojure.test feels a bit 
“imperative” since it’s “assert this, assert that”. Mind you, testing is very 
subjective and I know there are folks who won’t like the opinionated way 
Expectations wants you to write your tests.

Hope that helps?

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

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

On 9/28/16, 7:26 AM, "clojure@googlegroups.com on behalf of p...@pwjw.com" 
 wrote:

Hi.

I'm new to clojure, and it is quite lovely. The threading model is great, the 
emacs integration is super, and the tasteful lisp extensions are good. A very 
nice programming environment all around. 

But as I write more code I find a couple of structures I'm using a lot which 
seem related to me not knowing idioms for a couple of uses cases. So thought 
I'd ask and see if you have any suggestions. 

Apologies if this is covered elsewhere. And if I should read some existing 
documentation I didn't find, I apologize for missing it. And thanks in advance 
for your time reading!

First the thrush operators (-> and ->>) are super handy. But I find myself 
needing to 'move' arguments every now and then. So I get code which looks like

(->> blah
     (do-this)
     (do-that arg)
     ((fn [s] (rearrange arg s arg

quite a lot.The alternate is a big nested let like

 (let  [ first   (blah)
          second  (do-this first)
          ...
          result  (wrap-it-up fourteenth) ]
    result)

for sort of sequential application where arguments fall in different 'spots'. 
So I sort of find myself wanting to write a 'positional-thrush' macro like

(-%> blah
     (do-this %)
     (do-that arg %)
     (do-the-other a1 % a2))

where % is replaced with the output of the prior. But no such operator exists 
as far as I can see. So either I've had a good idea (which is unlikely since 
I'm super new to the language) or there's some other idiom you all use for this 
pattern which I've missed.

The second is smaller, but is more a question. clojure.test seems to only have 
'is' so for things like equality I end up writing (is (= (...) (...))) a lot. 
Or to test if an exception is thrown (is (thrown? ...)). That's OK, but I'm 
wondering what led to that decision rather than having is-eq and is-thrown and 
so on (considering the core language has shortcuts like when and unless and 
if-not so the compound macros seem idiomatic).

The last is sort of related to the first. Sometimes I'm assembling a data 
structure in a set of operators and I write them with a let or a -> and half 
way through I have an error condi

Re: Idiom question

[Stuart Sierra]

I will answer the clojure.test question, since I wrote it.

You can call clojure.test/is with *any* Clojure expression: if the 
expression returns logical true, the assertion passes. Having just the one 
expression keeps the scope of the testing library small.

The `clojure.test/is` macro was designed to be extensible, based on the 
syntax of the expression you pass it, but in a really convoluted way 
involving multimethods and macroexpansion. It was an experiment that did 
not turn out well, and I don't recommend it.

–Stuart S.


On Wednesday, September 28, 2016 at 10:31:37 AM UTC-4, paul wrote:
>
> The second is smaller, but is more a question. clojure.test seems to only 
> have 'is' so for things like equality I end up writing (is (= (...) (...))) 
> a lot. Or to test if an exception is thrown (is (thrown? ...)). That's OK, 
> but I'm wondering what led to that decision rather than having is-eq and 
> is-thrown and so on (considering the core language has shortcuts like when 
> and unless and if-not so the compound macros seem idiomatic).
>

-- 
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: Idiom question

[Colin Yates]

You might want to checkout 'cond->', 'condp' and 'as->'. Checkout the
excellent clojuredocs.org website for examples of their usage
(https://clojuredocs.org/clojure.core/condp for example).

Sorry to be so succinct - deadlines etc.

On Wed, 28 Sep 2016, at 03:26 PM, p...@pwjw.com wrote:
> Hi.
>
> I'm new to clojure, and it is quite lovely. The threading model is
> great, the emacs integration is super, and the tasteful lisp
> extensions are good. A very nice programming environment all around.
>
> But as I write more code I find a couple of structures I'm using a lot
> which seem related to me not knowing idioms for a couple of uses
> cases. So thought I'd ask and see if you have any suggestions.
>
> Apologies if this is covered elsewhere. And if I should read some
> existing documentation I didn't find, I apologize for missing it. And
> thanks in advance for your time reading!
>
> First the thrush operators (-> and ->>) are super handy. But I find
> myself needing to 'move' arguments every now and then. So I get code
> which looks like
>
> (->> blah
>  (do-this)
>  (do-that arg)
>  ((fn [s] (rearrange arg s arg
>
> quite a lot.The alternate is a big nested let like
>
>  (let  [ first   (blah)
>   second  (do-this first)
>   ...
>   result  (wrap-it-up fourteenth) ]
> result)
>
> for sort of sequential application where arguments fall in different
> 'spots'. So I sort of find myself wanting to write a 'positional-
> thrush' macro like
>
> (-%> blah
>  (do-this %)
>  (do-that arg %)
>  (do-the-other a1 % a2))
>
> where % is replaced with the output of the prior. But no such operator
> exists as far as I can see. So either I've had a good idea (which is
> unlikely since I'm super new to the language) or there's some other
> idiom you all use for this pattern which I've missed.
>
> The second is smaller, but is more a question. clojure.test seems to
> only have 'is' so for things like equality I end up writing (is (=
> (...) (...))) a lot. Or to test if an exception is thrown (is (thrown?
> ...)). That's OK, but I'm wondering what led to that decision rather
> than having is-eq and is-thrown and so on (considering the core
> language has shortcuts like when and unless and if-not so the compound
> macros seem idiomatic).
>
> The last is sort of related to the first. Sometimes I'm assembling a
> data structure in a set of operators and I write them with a let or a
> -> and half way through I have an error condition I want to check. In
> a mutable procedural language you would do something like
>
>   x = blah
>   y = bim
>   if (! (condition (y))) throw "y doesn't meet condition"
>   z = blob
>
> I don't see a good idiom for this. I have to split and nest lets for
> instance
>
> (let [x (blah) y (bim) ]
>   (if (condition (y)) (throw ...)
>  (let [ z (blob) ]
>   ))
>
> which seems a bit ugly.  I sort of want a let-with-test or a thrush-with-
> test so something which looks like
>
> (-%?>  (init)
>  (operator-1 %)  (post-condition)
>  (operator-2 %)  (post-condition) )
>
> where if I don't have a post condition I could just use 'true'. Then
> this expands to doing a quick '(if (not (postcondition (intermedia-
> result throw...)
>
> but that's a crazy thing to want. So curious how you all tackle this.
>
> Thank you all for your consideration. And apologies again if this is
> covered elsewhere or I should have asked in a different forum.
>
> Best,
>
>   Paul
>
> --
> 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: Idiom question

[Alex Miller]

Hi Paul, there is a rich history of people extending the thread macros. For 
things in core, check out some of the other threading operators: as->, 
cond->, some-> etc as they handle more of your cases below. This is a good 
overview of what they do:

http://clojure.org/guides/threading_macros

Additionally, there are a bunch of libraries that provide other variants 
like synthread , swiss-arrows 
, and even core.incubator 
. 


On Wednesday, September 28, 2016 at 9:31:37 AM UTC-5, p...@pwjw.com wrote:
>
> Hi.
>
> I'm new to clojure, and it is quite lovely. The threading model is great, 
> the emacs integration is super, and the tasteful lisp extensions are good. 
> A very nice programming environment all around. 
>
> But as I write more code I find a couple of structures I'm using a lot 
> which seem related to me not knowing idioms for a couple of uses cases. So 
> thought I'd ask and see if you have any suggestions. 
>
> Apologies if this is covered elsewhere. And if I should read some existing 
> documentation I didn't find, I apologize for missing it. And thanks in 
> advance for your time reading!
>
> First the thrush operators (-> and ->>) are super handy. But I find myself 
> needing to 'move' arguments every now and then. So I get code which looks 
> like
>
> (->> blah
>  (do-this)
>  (do-that arg)
>  ((fn [s] (rearrange arg s arg
>
> quite a lot.The alternate is a big nested let like
>
>  (let  [ first   (blah)
>   second  (do-this first)
>   ...
>   result  (wrap-it-up fourteenth) ]
> result)
>
> for sort of sequential application where arguments fall in different 
> 'spots'. So I sort of find myself wanting to write a 'positional-thrush' 
> macro like
>
> (-%> blah
>  (do-this %)
>  (do-that arg %)
>  (do-the-other a1 % a2))
>
> where % is replaced with the output of the prior. But no such operator 
> exists as far as I can see. So either I've had a good idea (which is 
> unlikely since I'm super new to the language) or there's some other idiom 
> you all use for this pattern which I've missed.
>
> The second is smaller, but is more a question. clojure.test seems to only 
> have 'is' so for things like equality I end up writing (is (= (...) (...))) 
> a lot. Or to test if an exception is thrown (is (thrown? ...)). That's OK, 
> but I'm wondering what led to that decision rather than having is-eq and 
> is-thrown and so on (considering the core language has shortcuts like when 
> and unless and if-not so the compound macros seem idiomatic).
>
> The last is sort of related to the first. Sometimes I'm assembling a data 
> structure in a set of operators and I write them with a let or a -> and 
> half way through I have an error condition I want to check. In a mutable 
> procedural language you would do something like
>
>   x = blah
>   y = bim
>   if (! (condition (y))) throw "y doesn't meet condition"
>   z = blob
>
> I don't see a good idiom for this. I have to split and nest lets for 
> instance
>
> (let [x (blah) y (bim) ]
>   (if (condition (y)) (throw ...)
>  (let [ z (blob) ] 
>   ))
>
> which seems a bit ugly.  I sort of want a let-with-test or a 
> thrush-with-test so something which looks like
>
> (-%?>  (init)
>  (operator-1 %)  (post-condition)
>  (operator-2 %)  (post-condition) )
>
> where if I don't have a post condition I could just use 'true'. Then this 
> expands to doing a quick '(if (not (postcondition (intermedia-result 
> throw...)
>
> but that's a crazy thing to want. So curious how you all tackle this.
>
> Thank you all for your consideration. And apologies again if this is 
> covered elsewhere or I should have asked in a different forum.
>
> Best,
>
>   Paul
>

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

Idiom question

[paul]

Hi.

I'm new to clojure, and it is quite lovely. The threading model is great, 
the emacs integration is super, and the tasteful lisp extensions are good. 
A very nice programming environment all around. 

But as I write more code I find a couple of structures I'm using a lot 
which seem related to me not knowing idioms for a couple of uses cases. So 
thought I'd ask and see if you have any suggestions. 

Apologies if this is covered elsewhere. And if I should read some existing 
documentation I didn't find, I apologize for missing it. And thanks in 
advance for your time reading!

First the thrush operators (-> and ->>) are super handy. But I find myself 
needing to 'move' arguments every now and then. So I get code which looks 
like

(->> blah
 (do-this)
 (do-that arg)
 ((fn [s] (rearrange arg s arg

quite a lot.The alternate is a big nested let like

 (let  [ first   (blah)
  second  (do-this first)
  ...
  result  (wrap-it-up fourteenth) ]
result)

for sort of sequential application where arguments fall in different 
'spots'. So I sort of find myself wanting to write a 'positional-thrush' 
macro like

(-%> blah
 (do-this %)
 (do-that arg %)
 (do-the-other a1 % a2))

where % is replaced with the output of the prior. But no such operator 
exists as far as I can see. So either I've had a good idea (which is 
unlikely since I'm super new to the language) or there's some other idiom 
you all use for this pattern which I've missed.

The second is smaller, but is more a question. clojure.test seems to only 
have 'is' so for things like equality I end up writing (is (= (...) (...))) 
a lot. Or to test if an exception is thrown (is (thrown? ...)). That's OK, 
but I'm wondering what led to that decision rather than having is-eq and 
is-thrown and so on (considering the core language has shortcuts like when 
and unless and if-not so the compound macros seem idiomatic).

The last is sort of related to the first. Sometimes I'm assembling a data 
structure in a set of operators and I write them with a let or a -> and 
half way through I have an error condition I want to check. In a mutable 
procedural language you would do something like

  x = blah
  y = bim
  if (! (condition (y))) throw "y doesn't meet condition"
  z = blob

I don't see a good idiom for this. I have to split and nest lets for 
instance

(let [x (blah) y (bim) ]
  (if (condition (y)) (throw ...)
 (let [ z (blob) ] 
  ))

which seems a bit ugly.  I sort of want a let-with-test or a 
thrush-with-test so something which looks like

(-%?>  (init)
 (operator-1 %)  (post-condition)
 (operator-2 %)  (post-condition) )

where if I don't have a post condition I could just use 'true'. Then this 
expands to doing a quick '(if (not (postcondition (intermedia-result 
throw...)

but that's a crazy thing to want. So curious how you all tackle this.

Thank you all for your consideration. And apologies again if this is 
covered elsewhere or I should have asked in a different forum.

Best,

  Paul

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