Andrew wrote:
My remark was merely in response to the claim that Haskell cares whether you put tabs or spaces in your files. It does not, so long as the tabs are of length 8. If your editor produces tabs of a different size, that's a problem with your editor or the way you dislike Haskell's layout rules.
No. My editor produces the ASCII code for horizontal tab, when I hit the tab key. Just as it produces the ASCII code for a when I hit the a key. That's how it should be. The real problem is, that nobody could tell from just looking at the screen, what a program means even if you know the layout rules very well. The reason is, that the Haskell lexer sees tabs while you cannot see tabs unless you use a hex editor. Instead, your text editor displays some space in place of the tab. Only if the expansion rules of your editor are compatible with Haskell's may you grasp the source codes meaning. But, again, you can't know that by just looking at the screen. You have to use the :l command or the :se command in vi, for example, to make sure a) there are either only tabs or only spaces in front of the lines or b) the editor lets you view tabs expanded to 8. Or, to turn it another way: "What you see is not necessarily what you get". This may be fine for ad hoc scripts that one examines in hugs. But how can one hope to convince people that this is a good thing for reusable code, to be compiled code, serious software production! I mean business. Teams. Maintenance of code that has been written by someone else, etc. Some people suggested that the editor be configured so that it converts all tabs to spaces or vice versa on file open. Beware! Think of a software development team. One member (in India) uses "convert n leading spaces to tabs", the other (in Japan) "convert leading tabs to m spaces". Everytime one of them makes a small change in a file that has been changed by the other before, the source code control system will have a huge diff. Because, you can't use diff -b (ignore leading white space in comparision) on Haskell source. That implies that you cannot see later what this small change was. Instead, every indended line will be displayed as changed. This is a NIGHTMARE for project leaders, quality assistance staff, code maintainers. Greetings, Ingo
Ingo Wechsung wrote:
You have to use the :l command or the :se command in vi, for example, to make sure
a) there are either only tabs or only spaces in front of the lines or b) the editor lets you view tabs expanded to 8.
b) is a non-issue; *every* editor lets you view tabs expanded to 8, although some might not let you view them expanded to anything other than 8. There are three ways in which tabs may be handled: a) A tab is just a character, with no concept of width. b) Tab stops are every 8 characters, and this cannot be changed. c) Tab stops default to being every 8 characters, although the user can change this if they wish. There is no option d); nothing which assigns a width to a tab character either requires or assumes that the width is anything other than 8. Option c) normally equates to the user not understanding why they shouldn't do this. Someone who thinks that it's OK to pretend that tabs aren't 8 columns wide is someone whose experience is sufficiently narrow that they've never encountered a situation which forcibly dispels this delusion (e.g. where a key piece of software or hardware falls into category b) above).
Or, to turn it another way: "What you see is not necessarily what you get". This may be fine for ad hoc scripts that one examines in hugs.
Actually, one of the main benefits of layout is that the person
reading the code cannot be misled by the indentation. E.g.:
if (foo)
if (bar)
something();
else
something_else();
With layout, the compiler *will* interpret the code in the same way as
a human reading the code (unless they've specifically (mis)configured
their software to display tabs incorrectly).
If whitespace really didn't matter, then why do programmers care so
much about layout in languages where it isn't significant? (IOW, why
does "indent" exist?) Why not just write:
if (foo)
if (bar)
something();
else
something_else();
After all, you can deduce the nesting from the languages syntax,
right? Except that humans don't; they deduce the nesting from the
layout, so the layout had better match the syntactic structure or
else. OTOH, if the syntactic structure is determined by the layout,
then the two cannot fail to match.
--
Glynn Clements
participants (2)
-
Glynn Clements -
Ingo Wechsung