Yeah, cond will probably do the trick as well.
I do consider if complex (and yeah my argument is true for a lot of
functions)
What i'm talking about is some accidental complexity of the language. That
I must constantly be aware of what parameter of the function I'm looking
at.
My point is not so
How about cond?
(cond
test true
:else false)
BTW I personally don't consider if complected. If reverse order is more
appropriate, I use if-not.
On Sunday, December 9, 2012 12:02:54 AM UTC+1, Thomas Goossens wrote:
>
> One of the issues i had and still have with the if function is that
>
Cool thanks!
On Sunday, December 9, 2012 11:52:32 AM UTC+1, Alex Baranosky wrote:
>
> The version I just posted also has the benefit that it does not cause
> multiple evaluations of its branches.
>
> On Sun, Dec 9, 2012 at 2:39 AM, Herwig Hochleitner
>
> > wrote:
>
>> 2012/12/9 Ben Wolfson >
>>
You could add check for other keys than :then and :else being used.
For documentation, I'd add a docstring "Macro, similar to if but with
branches labeled by keywords :then, :else." + the usage examples you posted.
Also, have you looked at cond and if-not?
Using cond to me feels like labeling the
>>
>> (defmacro iff [test & {:keys [then else]}]
You probably want a different name for this, 'iff' already has a well
understood meaning as 'if and only if'
See
http://en.m.wikipedia.org/wiki/If_and_only_if
--
You received this message because you are subscribed to the Google
Groups "Clojure"
Nice :)
On Sunday, December 9, 2012 1:17:48 AM UTC+1, Michał Marczyk wrote:
>
> Better yet,
>
> (defmacro iff [test & {:keys [then else]}]
> `(if ~test ~then ~else))
>
> (that's doing the lookup for then and else in the map constructing
> from the macro's rest argument at compilation time ra
Better yet,
(defmacro iff [test & {:keys [then else]}]
`(if ~test ~then ~else))
(that's doing the lookup for then and else in the map constructing
from the macro's rest argument at compilation time rather than in an
evaluated map including both at run time).
Cheers,
Michał
On 9 December 2012
You may want to use some delays to prevent evaluation of untaken branches:
user=> (iff true :else (println 1) :then (println 3))
3
1
nil
user=>
On Sat, Dec 8, 2012 at 3:02 PM, Thomas Goossens
wrote:
> One of the issues i had and still have with the if function is that
> because it has ordered
One of the issues i had and still have with the if function is that
because it has ordered arguments, makes things more complex.
For small functions this is no so much of a problem.
(if test 1 0)
But when things get larger, that extra complexity of order without
explicit information can get s
