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.
All these problems are caused by people who use a different tab size than
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. 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