AW: Editor Tab Expansion

[matt hellige]

[Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl>]
> 
> All these problems are caused by people who use a different tab size
> than 8. With consistent tab size there is no reason to convert between
> tabs and spaces.
> 

i've tried to avoid getting involved in this, but now i can no longer
resist.

fist and probably most importantly, it becomes clear that the layout
arguments revolve around personal preferences, and what we can call
"meta-preferences," statements like: "for these good reasons, i'd
prefer that no one have that particular preference." unfortunately,
someone will always think differently, and what is intuitive to one
person will invariably make no sense to someone else. so the danger
here is that a community of like-minded individuals will end up making
decisions and anyone who has un-fashionable preferencees will feel
excluded and frustrated, and may throw the baby out with the
bathwater. now, programming languages are, by nature, nothing BUT a
lot of preferences, so it's a pretty fine line, but in many cases it's
important to support those members of the community whose preferences
you do not share, and indeed whose preferences you consider
unreasonable.

the fact is, ingo's points are reasonable. for large multi-developer
projects, it's very important that there be some way of automatically
finding semantic changes in source files. anyone who has ever needed
to figure out what another programmer "actually" changed in a source
file that they also completely re-indented before checkin knows how
painful this can be. "diff -b" can be a godsend, but obviously, only
if whitespace is insignificant.

there seems to be an awfully strong bias against using hard tabs with
a configurable displayed width. i'd like to describe a situation where
i believe that option makes a lot of sense... suppose you're working
on a team of programmers on a project, and you need to come up with
some coding standards, since you all agree that's a wise thing to do.
no suppose 40% of the programmers like a 4-space indent, 40% like a
2-space indent, and the other 20% like an 8-space indent. what to do?

well, if you're all using relatively smart editors, the traditional
solution is to mandate the use of hard tabs, and allow people to
configure their editors however they want. that way i can see:

for () 
{
  // do some stuff...
  if ()
    // do something else...
}

and the guy in the next office can see:

for () 
{
    // do some stuff...
    if ()
        // do something else...
}

cvs always sees the same thing, and we're all happy. obviously, this
only works if indentation is used ONLY to indicate nesting depth and
NEVER to align text vertically at some specific column. it seems that
many people on this list prefer laying out haskell code with vertical
alignment, in which case these coding standards would not make sense,
but there has been some support for a strict nesting depth layout
style as well.

all in all, i think it's neat that haskell supports different layout
styles, and i think it was VERY wise to support a non-layout syntax as
well (compare with python, which many people refuse to touch because
they enforce layout, and people consider it unmaintainable).

my only concern about the whole system is the interpretation of tab
characters. as irritating is it is when make complains that you're
using spaces instead of tabs (is there a programmer alive who was
never mystified by "*** Missing separator. Stop."?), at least there
can be no disagreement about how many spaces equal one tab. i would
PREFER if haskell enforeced a strict distinction between spaces and
tabs for layout purposes, i.e., this:

let x = y
^I  z = q
  ^Iw = l
in ...

should be an error. if a given indent is noted as "^I  ", subsequent
lines must match exactly. no number of spaces will every "equal" a
tab. in fact, this brings to mind a question about the layout system.
currently, is a tab character ALWAYS interpreted as eight spaces, or
is it treated as "go to the next tab stop", where tab stops are every
eight spaces? if it's the latter, i live in fear!

not sure if i should send this or just cancel it... ;)

matt


-- 
matt hellige                  matt@immute.net
http://matt.immute.net