Isn't this a more fundamental problem tho'...:
(def x 0)
(or (zero? x) (/ 100 x)) ;; true
(alt-or (zero? x) (/ 100 x)) ;; java.lang.ArithmeticException: Divide by zero
Sean
On Feb 20, 2014, at 4:58 AM, Niels van Klaveren
wrote:
>
> The result wouldn't return faster if the input is an infi
>
>
> The result wouldn't return faster if the input is an infinite list.
>
> Ah, I see the gotcha now. If you don't implement *or *as a macro, all
arguments will be evaluated before *or *is invoked. Macro-expansion won't
evaluate later arguments if a former one short-circuits, of course.
I'd on
>
>
> The definitions of alt-or and alt-and are swapped:
>
> (alt-or false true) and (alt-or true false) both return false, (but (and)
> is true, and both (alt-and) and (alt-or) are false).
>
> (alt-and true false) and (alt-and false true) both return true.
>
That's some serious C&P errors there
On Wed, Feb 19, 2014 at 10:02 AM, Niels van Klaveren <
niels.vanklave...@gmail.com> wrote:
> Currently, *and* and *or *are implemented as macro's, and cannot be used
> in *apply *or as function parameters. Related functions like *every?* and
> *some* are implemented either on the basis of *or* or
