On Fri, 6 Dec 2002, Ingo Wechsung wrote:

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.

Likewise, the initial-uppercase = typename/constructor, initial lowercase = function/argument name has absolutely got to go because -- and I'm afraid I haven't been able to track down a definitive reference -- (AFAIK all versions of) the really old language Pascal has the rule that you don't distinguish case at all in identifiers (see e.g, http://www.marcocantu.com/epascal/English/ch02code.htm), and loads of people used Pascal even up to my undergrad degree in 1993. Likewise, all the work that's been done/going to be done to allow Haskell programs to be written using full unicode characters (including decisions about how `wide' a character is so that the layout rule can still be applied) are clearly wrong because there's the unix rule that characters are `8 bit ASCII codes'. And the absolute killer is the strong module interface which allows the export of only certain entities from a module, when everyone knows the C law that if you can find a prototype for a function (even if it's just retyped in the calling .c file, not coming from the module at all) then you access it regardless of the module writers desires. In every case where you've got a new idea which conflicts with practices from the past, you've got to decide whether the benefit derived from using the new idea outweighs the difficulties caused. Virtually all of the people who actually use Haskell would say (I believe :-) ) that they feel the ease of reading and avoidance of the occasions where `explicit delimiters' say one thing but the programmer indentation says another are good enough benefits to make this the `primary mode' of talking about and using Haskell. (Remember if you dislike this you have the ability to use the explicit delimiter syntax). You seem to be saying that layout should be banished because there's a set of people (of undetermined size) who would like Haskell were they to encounter it, except for that darned optional layout rule interefering with the ability to choose a personal interpretation for what the ASCII tab character should mean. [snip]

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.

What I really want is the -renameAlphaNumStrings option to diff which renames (in a consistent, cross file way) all alphanumeric strings to canonical values in some way and then outputs lines which only differ after renaming. After all, if someone has simply renamed the variables in a local function the semantics of the function hasn't changed so you don't need to worry about it for diff purposes. I mean, a process like that has got to be even better than one which takes advantage of the fact that in some languages various combinations of ASCII characters do not affect the program represented by a given file. The point I'm trying to make here and above is that you're used to working in a particular way using rules that apply to what you've worked with before -- and there are facilities to enable you to work that way in Haskell for people who want to -- but that you seem to object to there even exists a different way that is used and really liked by a most of the people who work with Haskell. I at least think the layout rule is very valuable for the two reasons I mentioned above, but I don't clamour about the `problem of the explicit syntax for Haskell that means you can write programs where the explicit syntax says one thing to the compiler and the layout suggests something else to the human reader'; let those who prefer that way do it without any hectoring from me. [snip] ___cheers,_dave_________________________________________________________ www.cs.bris.ac.uk/~tweed/ | `It's no good going home to practise email:tweed@cs.bris.ac.uk | a Special Outdoor Song which Has To Be work tel:(0117) 954-5250 | Sung In The Snow' -- Winnie the Pooh

["D. Tweed" ]

In every case where you've got a new idea which conflicts with practices from the past, you've got to decide whether the benefit derived from using the new idea outweighs the difficulties caused.

please see my previous post... it's a very fine line... :)

You seem to be saying that layout should be banished because there's a set of people (of undetermined size) who would like Haskell were they to encounter it, except for that darned optional layout rule interefering with the ability to choose a personal interpretation for what the ASCII tab character should mean.

please do not discount this argument. the group of people who are, for one reason or another, not members of the haskell community is not a vocal group, nor are they well represented. however, they are the majority. if there is interest in promoting haskell among those who currently don't use it, which there seems to be, some time needs to be spent either soliciting opinions from people outside the haskell community, or guessing what those opinions would be. clearly, it's a tough thing to do well. many of the opinions of people who aren't using haskell now may not be particularly relevant to the future direction of the language. however, it they're completely ignored, the language may never be accepted. this is the dilemma of all software designers, and only those who have no need for actual users can afford to ignore it. m -- matt hellige matt@immute.net http://matt.immute.net