Indentation of If-Then-Else

[Henning Thielemann]

On Mon, 23 Oct 2006, Henrik Nilsson wrote:

> The background to the proposal was that Haskell 98 prevents
> an arguably reasonable style of indentation, and that this
> has turned out to be a problem in practice: i.e. it tends to
> trip up a lot of unsuspecting people, in particular beginners.

I like to convince other programmers of Haskell by telling them, that
Haskell can abstract so powerful, that you can define your own control
structures, and consequently most control structures are actually library
functions. Two people who I explained it this way asked me, why Haskell
needs the special if-then-else syntax although an equivalent function can
be provided in an obvious way. "if-then-else" syntax is an exception from
a simple concept (functions!), which confuses people.  They think there
must be something special in "if-then-else", because it is not just a
function from the standard libraries. In contrast to that, 'case' is
something special because of its pattern matching.

> Yes, one can argue that they should learn "the right way",
> but this is really a very minor detail that many think would
> be best if people didn't have to worry about in the first place.

There are too much of these minor details.

> If I recall correctly, the proposal was implemented in GHC
> (and JHC?) shortly after it had been put forward, with
> very little effort indeed, and has not caused any ill
> side effects that I'm aware of.

... still not. What about other compiler writers, text editor developers,
language tool writers? They all have to respect every small exception. I'm
currently concerned with HTML - much more exceptions than rules. This is
no fun, and Haskell's syntax will go the same way. Let if-then-else in
Haskell for compatibility reasons, and try to get rid of it until
Haskell-2. But do not endorse its use by new extensions.

> > 3. If a compiler suspects that a parsing problem is related to 'do'
> > and 'if'
> >    it should suggest indentation
> >      if a
> >        then b
> >        else c
> >    or even better, the usage of if- or (?)-function.
> 
> As a matter of principle, I don't think a language standard should say
> much if anything about how a conforming compiler or interpreter should
> report errors.

I only want to point out how to solve the initial problem. I make
suggestions about compiler messages, because I want to show, that the
problems can be solved without adding more syntax exceptions.

> > So, please add this to the 'Cons' list.
> 
> Henning, I'm afraid I don't quite understand what the conses are?
> Could you clarify the concrete ill effects of the proposal, please?

Cons are:
 The sketched problem with indentation can be solved without touching the language.
 The syntax extension is unnecessary, thus complicates all language tools without need.