Hacker News new | past | comments | ask | show | jobs | submit login

Are short-circuiting boolean operators as conditional-plus-result-rolled-together really a functional technique? Certainly in strongly typed functional languages like Haskell they're impossible, because his example isn't even well-typed:

  evt && (evt.target || evt.srcElement)
You can't apply a boolean operator to an event! And even if you could, the result would always be a boolean. I associate this most commonly with languages I wouldn't really call functional, like Perl and Ruby (I believe Perl popularized the technique).

Even in Lisp, where you can write like that, it's much more idiomatic to use the if or cond forms, which is more morally equivalent to C's ternary conditional than to short-circuiting booleans.




> evt && (evt.target || evt.srcElement)

It's certainly true that this isn't well typed (not to mention not valid Haskell, since the . is used for namespacing, not access to member variables), but there's no reason that one couldn't do something conceptually similar:

    class Boolable a where
        toBool :: a -> Bool
        (&&)   :: a -> a -> a
        (||)   :: a -> a -> a

        a && b = if (toBool a) then b else a
        a || b = if (toBool a) then a else b

    instance Boolable Int where
        toBool 0 = False
        toBool _ = True
I don't know how idiomatic this is, but it works. One can see that it really is short-circuiting:

    > :l Boolable
    [1 of 1] Compiling Main             ( Boolable.hs, interpreted )
    Ok, modules loaded: Main.
    > 1 Main.|| undefined :: Int
    1
    > 1 Main.&& undefined :: Int
    *** Exception: Prelude.undefined
I don't know Haskell well enough to know why the `:: Int` on the end is needed, but I'm sure that that, too, can be worked around.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: