Quoth Ketil Malde
Just that they seem to be natural generalizations. If it's just the single form of paramtrizing the condition, I think it's better served by a regular function, 'bool' or (??) or whatever.
Well, yes, there's some logic to that. Like, bool b c a = if a then b else c getArgs >>= bool (putStrLn "long") (putStrLn "short") . (> 0) . length And I agree that's competitive with lambda-if as I understand it - though possibly not for the same reasons. For me, Haskell is not Lisp. Haskell's syntax takes a different direction, a mix of S-expression with stuff like if-then-else, and it works. If the lambda-if feature is actually useful in a way that takes advantage of the strength of the if-then-else notation, then I'm all for it. The problem is that due to the rarity of True/False as ... terminal value of a computation (I just made that up!), neither of these constructs is going to be worth much. Forget about lambda-if, even the regular function looks like hell - bool (putStrLn "long") (putStrLn "short") . (> 0) . length Compared to \ t -> if length t > 0 then putStrLn "long" else putStrLn "short" ... and much more so, with less trivial examples. In a brief survey of my own very small code base, I see only "hIsEOF" as a place where I could really use lambda-if. There, it would be vastly better than a regular bool function, but that's a pretty minimal use case. Donn