Documenting if-let and if-some

[DjebbZ]

Hello,

Could you document if-let and if-some? I don't understand how they works, and would love some an example in the README like other forms. Thanks in advance!

[Engelberg]

if-let and if-some are drop-in replacements for the ones built into Clojure:
Examples here:
https://clojuredocs.org/clojure.core/if-let
https://clojuredocs.org/clojure.core/if-some

The only difference is that the ones in better-cond support multiple bindings, in which case all the values must be truthy (for if-let) or non-nil (for if-some) to be considered true.

So now you can write things like:
(if-let [a 10, b 20] [a b] [b a])
which would return [10 20].

There is a paragraph about this in the README, but you are right that I don't give concrete examples. What examples do you think would be most clarifying?

[DjebbZ]

So they bail out with the then or else branch depending on the condition? And what happens when there's no else branch? They bail out? Continue with rest of the cond?

…

On Thu, May 23, 2019, 10:56 AM Mark Engelberg ***@***.***> wrote: if-let and if-some are drop-in replacements for the ones built into Clojure: Examples here: https://clojuredocs.org/clojure.core/if-let https://clojuredocs.org/clojure.core/if-some The only difference is that the ones in better-cond support *multiple bindings*, in which case *all* the values must be truthy (for if-let) or non-nil (for if-some) to be considered true. So now you can write things like: (if-let [a 10, b 20] [a b] [b a]) which would return [10 20]. There is a paragraph about this in the README, but you are right that I don't give concrete examples. What examples do you think would be most clarifying? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#16?email_source=notifications&email_token=AAAS3XTERDLR3KFQKBFBVDDPWZL5NA5CNFSM4HO3IJY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWBRH2A#issuecomment-495129576>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAS3XQSWYOMILZZ47KNGG3PWZL5NANCNFSM4HO3IJYQ> .

[Engelberg]

if-let and if-some are not clauses to be used within cond. They are standalone macros that can be used in place of the built-in if-let and if-some if you need multiple bindings (the built-ins only support one binding).

They are mainly used as implementation details to implement better-cond's :when-let and :when-some clauses inside of the cond. But since they are arguably better versions of clojure's built-in if-let and if-some, I thought I might as well expose them as public.

I personally never use them, as I find the cond is robust enough on its own.

Instead of (if-let [a 10, b 20] [a b] [b a], I would likely write

(cond
  :let [a 10, b 20]
  (and a b) [a b]
  :else [b a])

I suppose the if-let is more concise, but the cond makes each step clear, and then can stack together with other tests and bindings easily, without indenting.

[DjebbZ]

Thanks for the explanations, very clear. I think this somehow deserve to be in the README :)

[isaksky]

if-let and if-some are not clauses to be used within cond. They are standalone macros that can be used in place of the built-in if-let and if-some if you need multiple bindings (the built-ins only support one binding).

Is there a reason to not support them within cond? Seems like it would be a good way to avoid the short circuiting behavior of when-let. E.g.,:

(def a 2)

(cond
  (odd? a)
  [:a a]

  :if-let [b (and false a)]
  [:b b]

  :if-let [c (or false a)]
  [:c c])
;=> [:c 2]

[Engelberg]

:if-let would be a three-part clause rather than two parts like everything else, complicating the macro and making it hard to understand what's going on in the event of user error. That's the main reason.

The original code from which better-cond was derived had a special syntax to pack the information into two parts (basically no keyword was used, a binding vector indicated the use of :if-let), but I never used it because I found it lacked the clarity of just doing (following your example):

:let [b (and false a)]
b [:b b]

:let [c (or false a)]
c [:c c]

In practice, even this rarely came up because usually what you want is to specify the value to bail out with when the name you just bound is false-y (i.e., you want a custom when-let that bails out with a value other than nil). So usually you want something that's the opposite of if-let, like this:

:let [b (and false a)]
(not b) [:b b]

and :if-let can't express this case. So you're better off just using better cond's abilities to express your condition for bailing out clearly, and the value you want to bail out with, like above.

[isaksky]

@Engelberg I understand - appreciate the the explanation!