Documentation for latest features in the 2.0.1 branch:
https://github.com/Engelberg/better-cond/tree/v2.0.1
An example:
(cond
(odd? a) 1
:let [a (quot a 2)]
:when-let [x (fn-which-may-return-nil a),
y (fn-which-may-return-nil (* 2 a))]
:when (seq x)
:do (println x)
(odd? (+ x y)) 2
:else 3)
The :do performs a side-effecting statement if it gets that far in the
cond. :do is my favorite bonus addition for cond beyond :let. I find I
use it a lot to quickly insert some debugging print commands without
needing to change the shape of my code, so it can be trivially removed
later.
When :do did not exist, but :let did exist in my cond macro, I found myself
frequently writing things like:
:let [_ (println x)]
in order to insert a side-effecting statement into the cond sequence.
:do is a cleaner solution.
:when only continues with the cond if the value is truthy, otherwise it
bails out of the cond with nil.
:when-some (not yet merged in) will do much the same thing, but continuing
if non-nil, rather than truthy.
:when, :when-some, and :when-let don't add a whole lot of richness. For
example, that :when line in the example could just have easily been written
as:
(not (seq x)) nil
But using these can potentially add clarity of intention, so even though I
could make do without them, I go ahead and use them when relevant.
In better-cond's cond macro, that final :else is optional. You may prefer
the new cond-let library if you want to continue enforcing the use of :else
on the last clause.
To reiterate, :let is by far the most valuable addition, and I find :do to
be the second-most valuable addition. Other additions are fairly minor
syntactic sugar.
On Thu, Oct 4, 2018 at 1:36 PM Alan Thompson <clooj...@gmail.com> wrote:
> How would the :when and :do forms work?
> Alan
>
> On Wed, Oct 3, 2018 at 7:22 PM Mark Engelberg <mark.engelb...@gmail.com>
> wrote:
>
>> This looks like a case of "convergent evolution".
>>
>> Having the ability to do a :let in the middle of a cond feels like one of
>> those things that *should* be in the core language, so if it's not in
>> there, a bunch of people are naturally going to arrive at the same solution
>> and make it happen in their own utility libraries. A bunch of us Clojure
>> programmers from the early 1.0 days had been privately passing around and
>> using a "cond that supports :let bindings" macro for years. The first time
>> I saw the macro was in a blog post by Christophe Grand. I really hoped it
>> would make it into Clojure proper -- other functional languages like Racket
>> and F# support ways to bind local variables with "clearer, more linear
>> code, that doesn't make a march for the right margin", as Howard Lewis Ship
>> put it. But after several years had passed without any indication that
>> CLJ-200 was ever going to be addressed, I eventually made the improved cond
>> macro into a clojars library.
>>
>> walmartlabs' cond-let addresses the most important thing (let), which is
>> the critical piece of functionality that feels like the most natural,
>> needed addition to the language. better-cond's :let syntax is identical.
>> But as us old-school Clojurians passed around the "better cond" macro over
>> the years, it grew in functionality. So in better-cond, I included the
>> other little improvements that had accumulated over time, which I had found
>> useful. So better-cond also supports :when, :when-let, and :do (and will
>> soon have :when-some). :let is the only piece that I felt really belonged
>> in the core language's cond, and if CLJ-200 had made it into the core
>> language, I would have been content to just use Clojure's own cond. But
>> once I realized I was going to need a library to achieve the much-needed
>> :let inside of cond, I figured I might as well use that library to include
>> the other convenient cond additions as well. So better-cond is a superset
>> of cond-let's functionality, with support for :let plus a few bonuses.
>>
>> Use whichever one strikes your fancy. cond-let is perfect if all you
>> care about is adding :let to your cond. If you want to experiment with
>> some of the other features beyond :let, you could use better-cond and see
>> what you think.
>>
>> Either way, I strongly encourage you to use one of these two libraries so
>> you can start using :let inside your cond. I agree fully with Howard Lewis
>> Ship that it results in clearer code. Try either library which supports
>> this -- it will change your life!
>>
>>
>> On Wed, Oct 3, 2018 at 5:05 PM Matching Socks <phill.w...@gmail.com>
>> wrote:
>>
>>> Is this a refinement of Mark Engelberg's "better-cond", or an
>>> alternative approach?
>>>
>>> I have not used better-cond myself, but it starts here:
>>> https://dev.clojure.org/jira/browse/CLJ-200.
>>>
>>> --
>>> 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.
