Re: The Do-Let-Braces problem
Mark Utting writes:
fb::IO ()
fb =
do {
putStr "Enter Data: ";
line - getLine;
let line2 = line;
putStr line2;
}
ERROR "f.hs" (line 13): Syntax error in definition
(unexpected symbol "putStr")
I find it hard to determine exactly from the Report whether this is
a bug in Haskell, or just a bug in ghc. For what it's worth, nhc98
parses and accepts your example exactly as you intended.
Fix 3: I might be happy to put ALL the semicolons at the beginning
of lines, which also works, but you are not allowed a semicolon
at the beginning of the first brace, so this looks asymmetric.
f3 =
do {
putStr "Enter Data: "
;line - getLine
;let line2 = line
;putStr line2
}
A common style I have seen is
do { putStr "Enter Data: "
; line - getLine
; let line2 = line
; putStr line2
}
which matches nicely what Sebastien Carlier proposed in his message:
Ideally, I would like an editor be able to draw a pretty square bracket
(graphically, or with semi-graphic characters) around blocks, a bit like
this:
f3 =
do |~ putStr "Enter Data: "
| line - getLine
| let line2 = line
|_ putStr line2
Regards,
Malcolm
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: The Do-Let-Braces problem
fb =
do {
putStr "Enter Data: ";
line - getLine;
let line2 = line;
putStr line2;
}
I suggest doing this:
fb =
do { putStr "Enter Data: "
; line - getLine
; let line2 = line
; putStr line2
}
which looks nicer and has the advantage of being much easier to keep
track of where the semicolons are.
-Paul
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
RE: The Do-Let-Braces problem
Mark Utting writes:
fb::IO ()
fb =
do {
putStr "Enter Data: ";
line - getLine;
let line2 = line;
putStr line2;
}
ERROR "f.hs" (line 13): Syntax error in definition
(unexpected symbol "putStr")
I find it hard to determine exactly from the Report whether this is
a bug in Haskell, or just a bug in ghc. For what it's worth, nhc98
parses and accepts your example exactly as you intended.
GHC and Hugs both conform to the report here. The ';' on the end of the
'let' line is interpreted as the terminator for the 'line2 = line'
declaration, the layout system inserts a '}' before 'putStr', and
there's a missing semicolon before 'putStr' since we're back in
non-layout mode now.
Arguably the layout rule is not clever enough: it only allows one token
of lookahead when deciding whether to insert a close curly or not (in
the above example, if it had two tokens of lookahead it could determine
that the close curly was required before the ';' in the 'let'
declaration). I'm not seriously suggesting that the layout rule should
be extended to cope with this, rather that since it isn't general enough
we should simplify or throw away altogether the parse error condition in
the layout rule.
In my experience, mixing layout and non-layout in nested contexts
generally leads to trouble: stick to one or the other.
Cheers,
Simon
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: The Do-Let-Braces problem
Mark Utting wrote: Summary: Haskell layout has problems within 'do' (see below). Can we change Haskell to improve it? I don't think the language has to be changed. It seems to me that the problems is more with the idea of editing the source code as plain text. Ideally, I would like an editor be able to draw a pretty square bracket (graphically, or with semi-graphic characters) around blocks, a bit like this: f3 = do |~ putStr "Enter Data: " | line - getLine | let line2 = line |_ putStr line2 XEmacs could probably be tricked into doing that, but it seems quite difficult. And you would have to redefine most key bindings so that it behaves correctly. You may have a look at Mjolner (http://www.mjolner.com/mjolner-system/), it is a development environment for BETA with a hierarchical editor which works in a similar way. It wouldn't be adequate for Haskell, but it demonstrates the idea. By the way, with a proper editor, you wouldn't even need the layout rule. Source code would be stored with explicit bracing, and the editor could hide all these cluttering symbols, or display them in any fancy way you like. -- Sebastien Carlier ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The Do-Let-Braces problem
Thu, 15 Feb 2001 15:20:19 +1300, Mark Utting [EMAIL PROTECTED] pisze:
fb::IO ()
fb =
do {
putStr "Enter Data: ";
line - getLine;
let line2 = line;
putStr line2;
}
I have a different proposal. Let's drop the 'let' keyword in value
bindings in a 'do' block!
The largest continouos block of bindings is translated to a single 'let'.
(They can define a function by cases and can be mutually recursive.)
fb1 ::IO ()
fb1 =
do {
putStr "Enter Data: ";
line - getLine;
line2 = line;
putStr line2;
}
fb2 ::IO ()
fb2 = do
putStr "Enter Data: "
line - getLine
line2 = line
putStr line2
A disadvantage of let is that when the definition must be continued
on the next line, the word after 'let' set the indentation and the
continuation must be indented more than expected:
do
foo
let x = a very long expression - note that the next line
must be indented *too much*!
bar
I would like to have indents of the width four and a single indent here.
My proposal solves both of these problems.
A disadvantage: it breaks code which uses separate 'let' clauses
which shadow their variables.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTPCZA
QRCZAK
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
