December 2002 - Haskell-Cafe

AW: Editor Tab Expansion
by Ingo Wechsung 07 Dec '02

07 Dec '02

Simon wrote: >There's no reason not to use 8 column tab stops, so please don't do it. Ok, if "it just looks better to me" is no reason, then the following also holds: There's no reason not to use braces and semicolons, so please use them. > but it will be interpreted differently by a Haskell compiler. That's exactly my point. I consider it harmful, to put it mildly. >Tab characters are a primitive compression mechanism, nothing more. Well, layout rule may be regarded as an even more primitive compression mechanism, since it saves fewer bytes than tabs. (Remember that "it looks better" was outlawed before.) I have the impression that the view is somewhat biased toward the layout. Nobody seems to care about the trouble that is luring in the long run. You can't go professional with "use another editor", "change your long established habits", "don't use diff -b". Cheers, Ingo

3 2

AW: Editor Tab Expansion
by Ingo Wechsung 06 Dec '02

06 Dec '02

Thanks for the anserws. So I will write the braces and semicolons. It's better anyway in my opinion. I am not going to change my editing habits just to make hugs or ghc happy. Wether spaces or tabs are better in source files is a matter of taste and a language should not force me to use one or another. I can't help it, but to make the meaning of a program depend on the questions whether there are spaces or tabs in front of the line, and how many, seems silly to me. Sorry. Hal Daume III wrote: >so it needs to know where the boundaries between declarations are, hence >the need for semicolons. therefore, if you have embedded lets, you need >braces to delimit them: > let x = let y = z > q = r > in l > in q >would be ambiguous without layout/braces&semis. I don't see that. Sure, you need semis. But then let x = let y=z; q=r; in l in q or even let x = let y=z; q=r in l in q is just as unambiguous as (hypothetical) ( x = ( y=z; q=r ) l ) q I mean, you can see "let" as opening brace and "in" as closing brace. So no real need to write "let {" and "} in". Greetings, Ingo

6 5

AW: Editor Tab Expansion
by Ingo Wechsung 06 Dec '02

06 Dec '02

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

2 1

AW: AW: AW: Editor Tab Expansion
by Ingo Wechsung 06 Dec '02

06 Dec '02

Kevin, thanks for your helpfull comments. Ingo> Or, to turn it another way: "What you see is not necessarily Ingo> what you get". This may be fine for ad hoc scripts that one Ingo> examines in hugs. >So is that the language's fault (because of what you get) or the >editor's fault (because of what you see)? It depends on the abstraction level. Sure, I don't see Tabs and Spaces on the character level. I was not supposed to, up to now. On a higher level I see whitespace. Whitespace didn't matter, except for making things look nicer, up to now. I don't say the language is wrong. Beware. I only have my doubts about the question if its a good idea to cast a whitespace aware thing into an environment, namely *nix, where whitespace didn't matter. Up to now. Now that I know I can use semicolons and braces safely with any spacing, I can live with it. It's fine for me. I could write a haskell-insert-braces-and-semicolons-where-needed program if I feel like it. I think I will not feel like so, except for amusement. But then, I've got to get checks from my customers by the end of the month. So, perhaps I'll rather try to get my work done. But the problem will hurt others, again and again. Good night Ingo

1 0

Completeness of pattern matching
by Ingo Wechsung 06 Dec '02

06 Dec '02

Hi there, I wonder if the compiler could check, if all possible combinations have been checked in a pattern match. For example: data Colour = Red | Yellow | Green | Blue; trafficlight Red = True; trafficlight Yellow = True; trafficlight Green = True; trafficlight Blue = False; This is complete and okay. But, if somebody adds Magenta to Colour, then the function trafficlight becomes incomplete and the program might terminate at runtime whereas before it could not. (Of course, there could be dozens of more complicated case scattered over multiple files ...) If this could be checked, shouldn't it be an compile time error to have incomplete functions? Cheers, Ingo

3 2

RE: Editor Tab Expansion
by Simon Marlow 06 Dec '02

06 Dec '02

> 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. Not true: most editors don't insert a ^H when you hit the backspace key, so why should they insert ^I when you hit the tab key? This whole problem boils down to one thing: people configure their editors to display tab stops at something other than every 8 columns. There's no reason not to use 8 column tab stops, so please don't do it. Not only will your code be unreadable by someone using standard tab-stop settings, but it will be interpreted differently by a Haskell compiler. Tab characters are a primitive compression mechanism, nothing more. No-one is saying that you can't use units of 4 columns for indentation, just that you can't use tab characters for that. Cheers, Simon

1 0

AW: Editor Tab Expansion
by Ingo Wechsung 06 Dec '02

06 Dec '02

Markus wrote: >Perhaps somebody could come up with a "Haskell indent" (part of a pretty >printer?)? Hmmm... while for example "cb" is a comparably simple program, this "Haskell indent" had to be a full blown parser. I'd rather like to have a "Haskell brace" that makes fun (x,y) = case x of 7 -> case y of -- one tab 4 -> "seven four" -- two tabs _ -> "no seven in front" -- eight spaces into fun (x,y) = case x of { 7 -> case y of { 4 -> "seven four"; } _ -> "no seven in front"; } Regards, Ingo

1 0

AW: Editor Tab Expansion
by Markus.Schnell＠infineon.com 06 Dec '02

06 Dec '02

When I got somebody else's C-Code, I used gnu indent to bring it into a layout I liked (and could easily grasp). One of the points I like about Haskell is just its use of space: it makes things clearer and doesn't clutter up your screen as it does in C. I definitely had less problems with layout in Haskell than with forgetting braces in C (and line them up nicely). > unambiguous one using spaces) . I think it's really the fault of ASCII for > allowing the tab character code which has user-defined semantics, just > like the other abomination the form-feed character. That's because of its history: ASCII was used first for telegraphs, so TAB was just a shorter way of saying "make some space", same with form-feed, the bell, and all those other characters from 0-31 you never use. If somebody wants to write his/her Haskell code with braces, so be it - unless you develop in a group, then you should have layout rules anyway. Perhaps somebody could come up with a "Haskell indent" (part of a pretty printer?)? Markus

1 0

Re: Editor Tab Expansion
by Ashley Yakeley 05 Dec '02

05 Dec '02

At 2002-12-05 15:34, Andrew J Bromage wrote: >> Wether spaces or tabs are better in source files is a matter of taste and >> a language should not force me to use one or another. > >The language does not force you to do anything of the sort. It's your >editor's fault if it can't decouple the concept of hitting the tab >key from the concept of putting a ^I character in your file. Haven't we all been through this argument several months ago? I believe the conclusion was "people have different preferences, and Haskell allows for that". Certainly when I write my own Haskell I like to use tabs, real ones, to indent. And I can easily outdent by using the backspace key, once, which will cleanly delete exactly one tab. I'll have no truck with Haskell's "layout" and its picky interpretations of whitespace. Luckily for people like me there's braces and semicolons, which let you ignore this layout nonsense entirely. YMMV, of course. -- Ashley Yakeley, Seattle WA

2 1

Re: AW: Editor Tab Expansion
by Ashley Yakeley 05 Dec '02

05 Dec '02

At 2002-12-05 12:49, Ingo Wechsung wrote: >So I will write the braces and semicolons. It's better anyway in my opinion. > >I am not going to change my editing habits just to make hugs or ghc happy. >Wether spaces or tabs are better in source files is a matter of taste and >a language should not force me to use one or another. I can't help it, but >to make the meaning of a program depend on the questions whether there are >spaces or tabs in front of the line, and how many, seems silly to me. Sorry. I also use braces and semicolons for the exact same reason. -- Ashley Yakeley, Seattle WA

1 0