Hello, I'm new to Haskell and FP in general and I find it great. Having more than 10 years expirience with "whitespace does not matter" languages, the only thing that drives me crazy is the layout rule. 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. Currently, I expand tabs to 4 spaces only, so \tx=bar looks like ____foo = bar to me when the compiler sees ________foo = bar I would not want to change dozens of .exrc files, shell startup files with and/or ultraedit settings on many different machines. I also do not want to care whether there are spaces or tabs in front of my source code lines. So I'm stuck with option 1, right? Just to be sure, can I really, really forget about layout if I write fully braced and semicolonoized code? Besides, is there any reason why the syntax is LET { decl1; decl2; ... } IN expr when LET and IN are sufficient enough to enclose the declarations? Greetings, Ingo
As far as I understand it, I have 2 options:
1. Use braces and semicolons and ignore the layout rules.
This is one option.
Just to be sure, can I really, really forget about layout if I write fully braced and semicolonoized code?
Yes.
Besides, is there any reason why the syntax is LET { decl1; decl2; ... } IN expr when LET and IN are sufficient enough to enclose the declarations?
because you can say: let x = y z = q w = l in ... 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. - Hal p.s., I'm surprised you're having difficulty with tabs; a few people have had such problems, but usually there's an easy fix in the editor. I don't really know enough about this to say one way or another thogh...
I think the compiler sees ^I and not spaces.
The layout rule follows similar guidelines to good
indenting practice expected in organizations that
program in other languages.
If you use (g)vim to edit, you can :set expandtab
to only use spaces for tabs. We do that where I
work after some grumblings over whether a tab
should represent 4 or 8 spaces. Now we use 4 spaces
and no tabs. (:set list works in most vi flavors
to show whether tab is spaces or ^I chars.)
There are ways to implement it in (n)vi described
in the vi FAQ published each month in comp.editors
on Usenet and Google Groups.
Also availble at
ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/comp/editors/
Also, be careful to write "let ... in ..." in lowercase.
Haskell is case sensitive.
--- Ingo Wechsung
Hello,
I'm new to Haskell and FP in general and I find it great.
Having more than 10 years expirience with "whitespace does not matter" languages, the only thing that drives me crazy is the layout rule.
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. Currently, I expand tabs to 4 spaces only, so
\tx=bar
looks like
____foo = bar
to me when the compiler sees
________foo = bar
I would not want to change dozens of .exrc files, shell startup files with and/or ultraedit settings on many different machines. I also do not want to care whether there are spaces or tabs in front of my source code lines.
So I'm stuck with option 1, right? Just to be sure, can I really, really forget about layout if I write fully braced and semicolonoized code?
Besides, is there any reason why the syntax is LET { decl1; decl2; ... } IN expr when LET and IN are sufficient enough to enclose the declarations?
Greetings, Ingo _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
===== Christopher Milton cmiltonperl@yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
From: "Ingo Wechsung"
... Currently, I expand tabs to 4 spaces only, so
\tx=bar
looks like
____foo = bar
to me when the compiler sees
________foo = bar
If you want to go the layout way perhaps someone/you could put in a compiler option for tab expansion. Check in ghc/compiler/parser/Lex.lhs - it should be a starting point. Perhaps I will do it if I get a chance.
Peter wrote:
Currently, I expand tabs to 4 spaces only, so
\tx=bar
looks like
____foo = bar
to me when the compiler sees
________foo = bar
If you want to go the layout way perhaps someone/you could put in a compiler option for tab expansion. Check in ghc/compiler/parser/Lex.lhs - it should be a starting point. Perhaps I will do it if I get a chance.
That seems like a really bad idea to me. If someone writes code which
relies upon this particular option, but it isn't given, there's a good
chance that the code will be compiled incorrectly but without any
warning.
--
Glynn Clements
[Glynn Clements
Peter wrote:
Currently, I expand tabs to 4 spaces only, so
\tx=bar
looks like
____foo = bar
to me when the compiler sees
________foo = bar
If you want to go the layout way perhaps someone/you could put in a compiler option for tab expansion. Check in ghc/compiler/parser/Lex.lhs - it should be a starting point. Perhaps I will do it if I get a chance.
That seems like a really bad idea to me. If someone writes code which relies upon this particular option, but it isn't given, there's a good chance that the code will be compiled incorrectly but without any warning.
please see my previous suggestion: i believe the compiler should refuse to do "tab expansion" at all... m -- matt hellige matt@immute.net http://matt.immute.net
participants (6)
-
Christopher Milton -
Glynn Clements -
Hal Daume III -
Ingo Wechsung -
matt hellige -
Peter