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
G'day all. On Thu, Dec 05, 2002 at 09:49:27PM +0100, Ingo Wechsung wrote:
I am not going to change my editing habits just to make hugs or ghc happy.
What editor do you use? If you use a relatively smart one (e.g. vim, emacs etc), you should be able to configure it to do it to do what you want when the extension is .hs or .lhs or whatever. I use vim and I have been known to use the following: set ts=8 set sts=4 " Or sometimes 2 With either expandtab or noexpandtab as the mood takes me. That way, when I hit "tab" I get 2 or 4 spaces, which are expanded to an 8-space tab if I hit it enough times.
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. Cheers, Andrew Bromage
I used to run into more problems with layout until i switched to a simple set of layout rules which make it very easy to keep everything laid out on tab boundrys. rather than start layout blocks right after the 'let' 'do' or 'where', put them on the next line with one more tabstop than the current line. the end result is everything is always indented to a tab boundry and cutting and pasting code is nice and simple. example: main = do foo bar test withMVar mv $ \v -> do something done this makes your code independent of the tabstop and much easier to work with IMHO. John more examples: http://repetae.net/john/computer/haskell/GenUtil.hs http://repetae.net/john/computer/haskell/Format.hs http://repetae.net/john/computer/haskell/ErrorLog.hs -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
John Meacham
rather than start layout blocks right after the 'let' 'do' or 'where', put them on the next line with one more tabstop than the current line.
I've also a bit baffled by all the people apparently struggling with layout; I realize the rules are a bit complex, but it's something that "just works" for me. But then I also use this convention, (except in really simple cases: f x = let y = g x in h y f x = h y where y = g x (It could be because I use Emacs, though, where the hs mode has TAB cycling through the possible indentations.)
this makes your code independent of the tabstop and much easier to work with IMHO.
Also it is safer if you are using non-ASCII characters, e.g. f \x06de = case \x06de of foo -> bar blah -> -- where to align this? -kzm -- If I haven't seen further, it is by standing in the footprints of giants
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.
Well note that it doesn't only confuse compilers: if you post code for other people to read (whose display software has their personal own interpretation of what a tab character means) it may be confusingly formatted (for C like languages) or downright meaning changed (Haskell, python). I know I certainly hate reading/patching source code in any language when the original writer used tab characters because you have to play the `figure out what interpretation of tab produces sensibly laid-code' game and then temporarily reset your editor to that. (You can probably tell that I much prefer the mechanism where the tab key is a configurable input mechanism but the representation in the file is an 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. ___cheers,_dave_________________________________________________________ www.cs.bris.ac.uk/~tweed/ | `It's no good going home to practise email:tweed@cs.bris.ac.uk | a Special Outdoor Song which Has To Be work tel:(0117) 954-5250 | Sung In The Snow' -- Winnie the Pooh
On Thu, 5 Dec 2002 21:49:27 +0100
Ingo Wechsung
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.
What about using untabified files? Or an haskell-aware auto-indenting editor? V. -- Fedeli alla linea, anche quando non c'è Quando l'imperatore è malato, quando muore,o è dubbioso, o è perplesso. Fedeli alla linea la linea non c'è. [CCCP] Il contenuto di questa e-mail può essere modificato e redistribuito purchè questa nota e il suo significato rimangano intatti.
participants (6)
-
Andrew J Bromage -
D. Tweed -
Ingo Wechsung -
John Meacham -
ketil＠ii.uib.no -
Nick Name