[Haskell-cafe] Layout rule (was Re: PrefixMap: code review request)

[Ben Rudiak-Gould]

Brian Hulley wrote:
> Here is my proposed layout rule:
> 
> 1) All layout keywords (where, of, let, do) must either be followed by a 
> single element of the corresponding block type, and explicit block 
> introduced by '{', or a layout block whose first line starts on the 
> *next* line

I wouldn't have much trouble adapting to that.

> and whose indentation is accomplished *only* by tabs

You can't be serious. This would cause far more problems than the current rule.

> I would also make it that explicit braces are not allowed to switch off 
> the layout rule (ie they can be used within a layout),

I don't understand. What does "used within a layout" mean?

> multiline strings would not be permitted,

They aren't now, except with \ escapes. A stray " will be caught on the same 
line unless the line happens to end with \ and the next line happens to 
begin with \, which is exceedingly unusual.

> and multiline comments would not be permitted 
> (pragmas could easily be used just by using --#)

But --# doesn't introduce a comment. And this would make UNPACK pragmas 
rather inconvenient to use.

> 1) When you see a ';' you could immediately tell which block it belongs 
> to by looking backwards till the next '{'

I guess that might be helpful, but it doesn't seem easier than looking left 
to the beginning of the current line and then up to the first less-indented 
line.

> 2) Variable width fonts can be used,

They can be used now, if you adhere to a certain style, but not everyone 
likes that style. I wrote in C++ with a variable width font and tabs at one 
time, but eventually went back to fixed width. One reason was that I 
couldn't use comment layout conventions that tend (in my experience) to 
improve readability more than monospacing hurts it. Another reason was that 
glyph widths appropriate to natural languages didn't work all that well for 
source code. Spaces are much more important in source code than in natural 
language, for example. A proportional font designed for source code would be 
nice, but I haven't found one yet. Stroustrup used a mixture of proportional 
and monospaced glyphs in _The C++ Programming Language_ and it worked well.

> or different font faces to 
> represent different sorts of identifier eg class names, tycons, value 
> constructors, operators like `seq` as opposed to seq etc

Lots of editors do this with monospaced fonts; I think it's orthogonal to 
the layout issue.

> 3) Using only tabs ensures that vertical alignment goes to the same 
> position on the screen regardless of the font and tabs could even have 
> different widths just like in a wordprocessor

Requiring tabs is a really bad idea. Just forget it. Seriously.

> 4) Any keypress has a localised effect on the parse tree of the buffer 
> as a whole ( { " no longer kill everything which follows and there would 
> be no {- )

I don't understand why this is an advantage. If you have an editor that 
highlights comments in green, then large sections of the program will flash 
green while you type a {- -} comment, which might be annoying, but it also 
means you'll never forget to close the comment, so the practical benefit of 
forbidding {- -}, as opposed to simply not typing it yourself, seems nil.

> 5) It paves the way for a much more immersive editing environment, but I 
> can't say more about this at the moment because I haven't finished 
> writing it yet and it will be a commercial product :-)))

I guess everything has been leading up to this, but my reaction is that it 
renders the whole debate irrelevant. The only reason layout exists in the 
first place is to make source code look good in ordinary text editors. If 
you have a high-level source code editor that manipulates the AST, then you 
don't need layout, or tabs, or any of that silly ASCII stuff. The only time 
you need to worry about layout is when interoperating with implementations 
that use the concrete syntax, and then there's nothing to stop you from 
exporting in any style you like. And when importing, there's no reason to 
place restrictions on Haskell's layout rule, because the visual layout you 
display in the editor need have no connection to the layout of the imported 
file.

> Using my self-imposed layout rule I'm currently editing all my Haskell 
> code in a standard text editor using tabs set to 4 spaces and a variable 
> width font and have no problems.

Which is the best argument for keeping the current rule! If it were changed 
as you propose, then someday Hugh Briley would come along and complain that 
Haskell's layout syntax squandered screen space---but he *wouldn't* be able 
to program in his preferred style, because it would no longer be allowed. 
Religious freedom is a good thing.

{- Ben -}