Hello, the following code doesn't compile <snip> module Matrix where import Control.Monad.ST import Data.Array.ST import Data.Array.Unboxed type Block s = STUArray s Int Double data MMatrix s = MMatrix Int Int (Block s) newMatrix_ :: Int -> Int -> ST s (MMatrix s) newMatrix_ m n = do b <- newArray_ (1, m*n) return (MMatrix m n b) runMatrix = do _A <- newMatrix_ 3 3 _B <- newMatrix_ 3 3 matMul _A _B return "Success" main = show $ runST runMatrix matMul :: MMatrix s -> MMatrix s -> ST s (MMatrix s) --matMul a b = do let foo = 2*5 --return a matMul a b = do { let foo = 2*5; return a } </snip> under ghc 6.4.1, yielding the error message: question.hs:25:41: parse error on input `<-' Failed, modules loaded: none. The offending is line the one containing "let foo = 2*5", which is a little test I've done of let-clauses. Now, suppose instead that for the last function, matMul, I replace the version that's commented out. No errors! Could someone enlighten me as to why? I'm a bit confused, as I thought the two forms are equivalent save for formatting... This is on the back of a email discussion that I was reading about let-clauses, in which someone declared that they where better than where clauses for monadic code. If anyone could comment on this, I'd appreciate it as well. Many thanks in advance, Martin
Martin Percossi wrote:
matMul a b = do { let foo = 2*5; return a }
probably { let {foo = 2*5}; return a } will work (untested) your ";" indicates a further let-equation, but the possibility to use ";" without "{" and "}" is a bit pathologic (and haddock used to reject it) Christian
Christian Maeder wrote:
Martin Percossi wrote:
matMul a b = do { let foo = 2*5; return a }
probably { let {foo = 2*5}; return a } will work (untested)
your ";" indicates a further let-equation, but the possibility to use ";" without "{" and "}" is a bit pathologic (and haddock used to reject it)
I think this kind of example just proves my numerous arguments that the layout rule should be changed to only allow ';' after an *explicit* opening brace... Regards, Brian.
Am Donnerstag, 9. März 2006 14:04 schrieb Martin Percossi:
Hello, the following code doesn't compile <snip> matMul :: MMatrix s -> MMatrix s -> ST s (MMatrix s) --matMul a b = do let foo = 2*5 --return a matMul a b = do { let foo = 2*5; return a } </snip>
under ghc 6.4.1, yielding the error message:
question.hs:25:41: parse error on input `<-' Failed, modules loaded: none. ?? my error message is what I expect: Matrix.hs:25:42: parse error on input `}' Failed, modules loaded: none.
There's no '<-' around.
The offending is line the one containing "let foo = 2*5", which is a little test I've done of let-clauses. Now, suppose instead that for the last function, matMul, I replace the version that's commented out. No errors!
Could someone enlighten me as to why? I'm a bit confused, as I thought the two forms are equivalent save for formatting...
The offending line is parsed as matMul a b = do { let { foo = 2*5; return a } } (cf. Sec. 9.3 of the report), which obviously doesn't make sense. This is because let expressions extend as far to the right as possible and separating local bindings by ';' is legitimate, so the parser tries to parse a binding for return after the semicolon, and fails. It isn't smart enough to then backtrack and let the let-binding end at the semicolon. This is one of the dangers of mixing explicit braces and layout. In the other version, layout leads to correct parsing, as will replacing the semicolon with an 'in' or changing the layout to matMul a b = do { let foo = 2*5 ; return a } I suggest using semicolons only as the first token on a line, aligned below the opening brace, then all's well.
This is on the back of a email discussion that I was reading about let-clauses, in which someone declared that they where better than where clauses for monadic code. If anyone could comment on this, I'd appreciate it as well.
Many thanks in advance, Martin
Cheers, Daniel -- "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton
participants (4)
-
Brian Hulley -
Christian Maeder -
Daniel Fischer -
Martin Percossi