AW: AW: Editor Tab Expansion

[D. Tweed]

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