No if-then-else

[strake]

View

[hvr]

Btw, I'd point out in the motivation that pattern-guards subsume some uses of if/then/else, e.g.

x = if p then a else b

is easily rewritten into

x | p         = a
  | otherwise = b

(and the idea of dropping if-then-else sugar is not new, so maybe it's also worth pointing to https://wiki.haskell.org/If-then-else)

[hvr]

Also, how does this relate to #4 (Multi-way if)?

[quchen]

• Guards and multiway-if don’t work well if you want to put something into a single line.
• Explaining to beginners that we use case on true/false instead of having an if thing is awkward.
• I try to avoid if as much as I can in my own code, and still found it impossible to remove all if (via HLint nagging me) without compromising code readability.
• Breaks almost every module ever written.

I am strongly against this.

[cartazio]

Also doesn't seem to help accomplish anything. Agreed. It's unclear what the upside of not providing if then else could possibly have. Though I should still read the proposal 😇

On Saturday, September 24, 2016, David Luposchainsky < notifications@github.com> wrote:

• Guards and multiway-if don’t work well if you want to put something into a single line.
• Explaining to beginners that we use case on true/false instead of having an if thing is awkward.
• I try to avoid if as much as I can in my own code, and still found it impossible to remove all if (via HLint nagging me).
• Breaks almost every module ever written.

I am strongly against this.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/haskell/rfcs/pull/10#issuecomment-249379699, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAQwgMz2U-_ZJAAvp2ItoGsAyT8NkUGks5qtWo2gaJpZM4KFlLc .

[osa1]

@quchen

Guards and multiway-if don’t work well if you want to put something into a single line.

It works fine actually. In MultiWayIf we don't need line breaks between cases. It's just that current implementation is broken, but it's about to get fixed. See https://ghc.haskell.org/trac/ghc/ticket/10807 and https://phabricator.haskell.org/D2524 (see the test file here for an example).

[strake]

Explaining to beginners that we use case on true/false instead of having an if thing is awkward.

While learning Haskell myself i remember being quite perplexed why (&&) and (||) were mere functions while if-then-else was special syntax: if non-strict semantics let us define operators which evaluate the right operand iff they must, why have if-then-else at all?

I try to avoid if as much as I can in my own code, and still found it impossible to remove all if (via HLint nagging me) without compromising code readability.

Have you some examples?

In my experience, defining the operator (?) :: Bool -> a -> a -> a sometimes helps.

It's unclear what the upside of not providing if then else could possibly have.

The cost of such syntactic sugar is not zero: it complicates the language, potentially perplexes students (as in my experience), and must be parsed. I am not arguing against all syntactic sugar but i think if-then-else is a wart.

[yav]

if-then-else has special syntax because it makes programs more readable. Removing it from the language will break every program out there, and make the rest (subjectively) less readable.

Guards are not the same as if-then-else because they apply to declarations, while if-then-else is an expression.

I am unconvinced by the argument that if-then-else does not belong in the language because you may define an equivalent operator---one could apply the same reasoning to remove all kinds of other sugar (e.g., list literals, case statements, record notation, to name just a few).

[cartazio]

I agree with iavor.

On Oct 4, 2016 1:01 PM, "Iavor S. Diatchki" notifications@github.com wrote:

if-then-else has special syntax because it makes programs more readable. Removing it from the language will break every program out there, and make the rest (subjectively) less readable.

Guards are not the same as if-then-else because they apply to declarations, while if-then-else is an expression.

I am unconvinced by the argument that if-then-else does not belong in the language because you may define an equivalent operator---one could apply the same reasoning to remove all kinds of other sugar (e.g., list literals, case statements, record notation, to name just a few).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/haskell/rfcs/pull/10#issuecomment-251448332, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAQwpWFW8t039m7cQBnakQDwDNuideQks5qwoY6gaJpZM4KFlLc .

[strake]

if-then-else has special syntax because it makes programs more readable.

Here we disagree.

Removing it from the language will break every program out there

I have non-contrived counterexamples, so it won't break every program.

Nonetheless it will break many, as noted in the RFC, but we already have at least 1 program to automatically convert to alternatives.

Guards are not the same as if-then-else because they apply to declarations, while if-then-else is an expression.

Ergo "many cases", not "all cases" ☺

I am unconvinced by the argument that if-then-else does not belong in the language because you may define an equivalent operator

It does not belong in the language because we may define an equivalent operator, and said operator is more versatile and seldom less convenient.

one could apply the same reasoning to remove all kinds of other sugar (e.g., list literals, case statements, record notation, to name just a few).

These are good ideas, but i had to start somewhere ☺

For case statements, you mean they are sugar for λ-case, yes?

For record notation, i think we ought to wait for GHC to blaze this trail; with their ideas the record system may no more be a bad joke.

[cartazio]

Until you give me mix fix, we don't have an alternative for if then else notation. And that's gonna be a tad controversial ;)

This chat is no longer grounded in technical and usage pattern based advocacy. The utility of the change seems low ATM

On Wednesday, October 5, 2016, M Farkas-Dyck notifications@github.com wrote:

if-then-else has special syntax because it makes programs more readable.

Here we disagree.

Removing it from the language will break every program out there

I have non-contrived counterexamples, so it won't break every program.

Nonetheless it will break many, as noted in the RFC, but we already have at least 1 program https://github.com/RefactoringTools/HaRe/wiki/Home/dc5e82a63885601302e507163a903a6631f145d3 to automatically convert to alternatives.

Guards are not the same as if-then-else because they apply to declarations, while if-then-else is an expression.

Ergo "many cases", not "all cases" ☺

I am unconvinced by the argument that if-then-else does not belong in the language because you may define an equivalent operator

It does not belong in the language because we may define an equivalent operator, and said operator is more versatile and seldom less convenient.

one could apply the same reasoning to remove all kinds of other sugar (e.g., list literals, case statements, record notation, to name just a few).

These are good ideas, but i had to start somewhere ☺

For case statements, you mean they are sugar for λ-case, yes?

For record notation, i think we ought to wait for GHC to blaze this trail; with their ideas the record system may no more be a bad joke.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/haskell/rfcs/pull/10#issuecomment-251578222, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAQwsPsQ2I0TrwdZoXA26ubqVTzArbnks5qwyV9gaJpZM4KFlLc .

[thoughtpolice]

It does not belong in the language because we may define an equivalent operator, and said operator is more versatile and seldom less convenient.

It is only "seldom less convenient" if you ignore the minor issue that "it breaks almost every Haskell module ever written". I assure you, 100% -- nobody will be convinced by this argument when they suddenly have to fix hundreds of lines of code that worked perfectly OK before, and were broken for no reason (with imports, because Data.Bool.bool isn't in the scope of Prelude as it stands, and that's an entirely separate issue.)

We change things in GHC that users ask us to change and we still get complaints about breaking code. You can't please everyone. I expect we will make changes to Haskell that not everyone is fully pleased by. This change will please almost nobody, however. I hope that doesn't sound harsh, but my experience tells me: this is a bad change.

Unless we are going to first adopt an extension to support mixfix operators as Carter mentioned (which, frankly -- I'm not even sure if we want that, because it would likely make the Haskell grammar even more complex), this breaks every program ever, for basically no benefit -- and without a backwards-compatible way to mitigate the breakage, there is almost no interpretation under which this proposal is "more convenient" than the status quo.

I am strongly -1 on this proposal.

[jwiegley]

I'm also strong -1. This seems like a gratuitous change at this point, whereas it would have been fine nearer the beginning of Haskell's history.

[thoughtpolice]

So, just to be fair -- @hvr did rightfully point out to me on IRC that we can control some of the breakage, because obviously GHC would need to continue supporting -XHaskell2010 for a while. So we couldn't just nuke it from the implementation for a very long time. It wouldn't explode the world over night. And there's a more general discussion we could have about the way tooling could handle this, to be fair. So, I apologize for perhaps giving an unfair impression of how negative the consequences would be.

Regardless - I still think this is essentially a gratuitous change, independent of tooling arguments (it will eventually break code), and I think we have many more difficult extensions with better power-to-weight ratios to think about, everything else aside. So my position still remains an overall -1 (somewhat less strongly, perhaps).

[wrengr]

I'm also against the change. If this were the H98 committee, then it might be worth debating. But given as it'd break the majority of code and for little gain, I think our time is best spent debating other longer-standing concerns.

Moreover, historically Haskell has taken the aesthetic position of not forcing any particular style on users (whence so much duplication between expression- vs binding-forms of the same thing); which this proposal directly contradicts. There may be reasons to revisit our commitment to that aesthetic position, but if so then we should address it directly. IMO, if we were to back off on that position, there's practically zero chance of getting a consensus nor even a majority to agree on what the new position should be.

[nhn1966]

I will not repeat all arguments that have been put forward against this. I essentially agree with them all.

However, I would like to point out that when any fundamental aspect of a language like this is changed (possibly even in a non-breaking way as far as code is concerned), lots of other things break or are severely compromised as well: books, tutorials, lecture notes, research papers, what thousands and thousands of programmers and students have learned and thought they knew. Thus, to even contemplate a change like this one, the payoff must be almost universally agreed to be very large indeed to offset the massive costs.

I, for one, don't see any payoff at all. And I dare say that that there would be nowhere near any universal agreement regarding the proposed change. In fact, I'd go even further and say that this is the kind of change that severely would compromise Haskell's standing as a language fit for serious software development and teaching.

I'm thus strongly opposed.

[zenzike]

I also oppose this strongly.

[jurriaanhage]

As a teacher of Haskell: seconded.

On 4Nov, 2016, at 18:30, Nicolas Wu notifications@github.com wrote:

I also oppose this strongly.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[nomeata]

I agree with everyone that this unfeasible in the current form, as it breaks too much code.

It might be worth considering specifying an IfThenElse language extension, on by default, which an interested user could disable using NoIfThenElse – more Lego-based language design.

(But not strong feeling here really.)

[strake]

It might be worth considering specifying an IfThenElse language extension, on by default, which an interested user could disable using NoIfThenElse

Seems a good compromise to me ☺

I'll modify the RFC.

[quchen]

Sounds like a GHC language extension, not a Haskell Prime suggestion. If you're migrating the proposal, we can close this PR.

[DemiMarie]

I don't like this proposal, since it breaks practically every Haskell program.

[zenzike]

I'm also against this proposal. From a process perspective it looks like this proposal is going to be rejected: what's the process we'll go through to reach a consensus and close this?

[cartazio]

I think here there's a strong super majority of no. Let's just close it and punt on process for now.

did the majority of committee members for H2020 say no? If so that should be enough I think.

On Tue, Dec 13, 2016 at 4:16 AM Nicolas Wu notifications@github.com wrote:

I'm also against this proposal. From a process perspective it looks like this proposal is going to be rejected: what's the process we'll go through to reach a consensus and close this?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/haskell/rfcs/pull/10#issuecomment-266686154, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAQwjDp6ygI7t4e0Z65ToG9HMt2nZixks5rHmJmgaJpZM4KFlLc .

[mitchellwrosen]

Not to beat a dead horse here, but I'm not sure this point has been raised yet: nested if-then-else doesn't translate well to guard syntax. For example,

x = if foo
      then if bar then baz else quz
      else wat

can't be written as

x | foo
    | bar = baz
    | otherwise = qux
  | otherwise = wat

because it gets parsed as

x | foo
  | bar = baz
  | otherwise = qux
  | otherwise = wat

So, yeah, pass.

[jmct]

I’m also against.

So at my count 9 of the 10 committee members that have commented have come out as ‘nay’ on this (I didn’t count @hvr as it wasn’t clear what their thoughts were).

As other have suggested, the path forward would be a GHC extension and, if it gains widespread adoption, maybe the next revision of Haskell can consider this.