- Haskell-Cafe - Haskell.org

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

Re: Editor Tab Expansion
by C.Reinke 05 Dec '02

05 Dec '02

> Having more than 10 years expirience with "whitespace does not > matter" languages, the only thing that drives me crazy is the > layout rule. so in 10 years of programming, you've never written a Makefile?-) > As far as I understand it, I have 2 options: > > 1. Use braces and semicolons and ignore the layout rules. > > 2. Change the settings in all my editors so that the code looks > like the Haskell compiler sees it. 3. Change the settings in all your editors to get rid of those crazy hard-tabs! Good editors support this by enabling you to replace hard-tabs by soft-tabs (you type <Tab>, your editor inserts the right number of spaces, for a configurable notion of "right" => you can keep your favourite tab2space number and you and the compiler see the same code). (e.g., in Vim, type ":help tabstop" for a discussion of alternatives, my personal favourite is 2. Set 'tabstop' and 'shiftwidth' to whatever you prefer and use 'expandtab'. This way you will always insert spaces. The formatting will never be messed up when 'tabstop' is changed. you can still enter hard tabs when needed, e.g., in Makefiles, using CTRL-V <Tab>; there's also a useful help to make hard-tabs visible for debugging - ":help 'list'"). I got into the habit of hating hard-tabs before learning Haskell - in multi-developer projects, different layout styles are one thing, but combined with hard-tabs and different tab2space settings.. Hth, Claus

1 0

Re: Haskell-Cafe -- confirmation of subscription -- request 771383
by Nikita Ayzikovsky 05 Dec '02

05 Dec '02

On Thu, 05 Dec 2002 18:59:48 -0500 (EST) haskell-cafe-request(a)haskell.org wrote: > Haskell-Cafe -- confirmation of subscription -- request 771383 > > We have received a request from 24.78.145.92 for subscription of your > email address, <ayzik(a)shaw.ca>, to the haskell-cafe(a)haskell.org > mailing list. To confirm the request, please send a message to > haskell-cafe-request(a)haskell.org, and either: > > - maintain the subject line as is (the reply's additional "Re:" is > ok), > > - or include the following line - and only the following line - in the > message body: > > confirm 771383 > > (Simply sending a 'reply' to this message should work from most email > interfaces, since that usually leaves the subject line in the right > form.) > > If you do not wish to subscribe to this list, please simply disregard > this message. Send questions to haskell-cafe-admin(a)haskell.org.

1 0

actions
by Nuno Silva 04 Dec '02

04 Dec '02

I'm using an action that generates a random number, for the user to discover it. each time he guesses, if the number is diferent that the one generated, it is suposed to call itself again to try again, but each time I call it, it generates the number again. how can I overcome this? sample of the code: descodificador = do c1 <- gera c2 <- gera c3 <- gera c4 <- gera "code in the middle to check if the number is equal" if not than go down... descodificador --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now

2 1