On Mon, 2018-07-09 at 19:20 +0200, Johannes Waldmann wrote:

Dear Cafe,

a student in my class detected this inconsistency in the design of Haskell:

...

Why require that each "if-then" has an "else" while still allowing incomplete sets of patterns? We could define "if p then a" by translating to "case p of { True -> a }"

This is the same as (case p of { True -> a; _ -> throw PatternDoesNotMatchException }). Therefore (if False then a) would give an exception. Normally, every expression has a value. The value of (if p then x else y) is properly defined. What would be the value of (if p then x)? If it is (), then x should also have type (), I think. You can do something like that in a Monad, and the function is called when. And there is an unless, which is an if-else without a then.

I think that "but then we'd have the dangling-else problem" is not a good answer because this is really about semantics, not surface syntax.

For reference, Scheme has short-if, see http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.4.3 (value is "unspecified" if condition is false) and Common LISP does as well https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node84.html#SECTION001 160000000000000000 (value is "nil")

Was this considered at some point in Haskell's design process? There is Section 5.2 on pattern matching in http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf (*) but it does not mention if-then(-else).

- J.W.

(*) can we please add this to https://www.haskell.org/documentation Upvote this: https://github.com/haskell-infra/hl/issues/86 _______________________________________________

Hope this helps and kind regards, Arjen

Was this considered at some point in Haskell's design process?

I don't know, but such an `if .. then` without `else` would encourage bad coding practices, IMO. On a related note: in C and friends if can do if () { .... }; but you can't do int x = E1 ? E2; So, even those pragmatic people (including those C++ people who like to include not just the kitchen sink but the surrounding farm as well) agree with Haskell's designers. Stefan

On 2018-07-09 01:20 PM, Johannes Waldmann wrote:

a student in my class detected this inconsistency in the design of Haskell:

...

Why require that each "if-then" has an "else" while still allowing incomplete sets of patterns? We could define "if p then a" by translating to "case p of { True -> a }"

I think that "but then we'd have the dangling-else problem" is not a good answer because this is really about semantics, not surface syntax.

Anthony Clayden is right that if-then-else has the benefit of giving an unambiguous grammar. if-then can be made unambiguous if you throw in delimiting, e.g., if-then-fi, if-then-begin-end. Suppose you like to support if-then (and have your disambiguation story) on the ground that case-of-True is already supported, and you don't mind the partiality, then why stop there? Why is if-else getting no love from you? Afterall, case-of-False is already supported, too.

:)