AW: AW: Editor Tab Expansion

[Ingo Wechsung]

Beg your pardon, Marcin

>But they are compatible because there is one most universally accepted
>interpretation of a tab (move to the next multiple of 8 columns). Any
>other interpretation hampers portability and should be avoided.

No. It didn't hamper portability with C, Java, Perl or any other *nix stuff
since more than 30 years except with COBOL, Python (?) and Haskell, where
COBOL is excused due to its origin in the punch card era. The others are not
excused, since they are yet to be established newcomers. The wise new
language designer should obey the unix rule "whitespace does not matter"
instead to expect that the world change their .exrc (by the way, according
to ls -l my .exrc is several years older than Haskell) to accomodate.

>All these problems are caused by people who use a different tab size than
8.

They used to do so, since Jan 1 1970 00:00 GMT, without real problems apart
from pure formatting problems. The formatting problems will not go away with
the advent of Haskell. But 2 new problems suddenly arise: syntax error due
to formatting and formatting dependend semantic.

But even if it were so and you could expand a tab to 8 columns only, there
is still the tools problem. No meaningful diff -b on Haskell source. Almost
every language tool has to be a haskell parser, etc. etc

If you can't or won't see that, fine. But don't expect Haskell to be too
successfull in the professional software engeneering business very soon.
Though, it was my impression, that the FP community would like to promote
their ideas of how to make more reliable, better software to more people.
This "obey the 8 column rule, use emacs, change your .exrc or get lost"
attitude is less than helpful, at least in my opinion. Cause it's FP that
matters, not the layout thing which has absolutely nothing to do with FP.

(Anyway, I still love Haskell{;})

Cheers, Ingo