
[Marcin 'Qrczak' Kowalczyk
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