Mystery Parse Error in LHS file
I have an lhs file, 'starsystem.lhs' that is not compiling because of a parse error. Specifically: $ cabal build Preprocessing executables for starsystem-0.1... Building starsystem-0.1... [1 of 4] Compiling Render ( Render.lhs, dist/build/ starsystem/starsystem-tmp/Render.o ) [2 of 4] Compiling Passive ( Passive.lhs, dist/build/ starsystem/starsystem-tmp/Passive.o ) [3 of 4] Compiling Active ( Active.lhs, dist/build/ starsystem/starsystem-tmp/Active.o ) [4 of 4] Compiling Main ( starsystem.lhs, dist/build/ starsystem/starsystem-tmp/Main.o ) starsystem.lhs:29:0: parse error on input `main' The location is at the first instance of main:
data Action = Action (IO Action)
The main program is mostly book-keeping such as initializing OpenGL and GLFW, creating window, setting up viewport, etc. \begin{code} main :: IO () -- ** line 29 main = do c_unbundled GLFW.initialize -- open window I cannot figure out what the problem here is. I have tried it in a regular hs file and it works. I have posted full source here: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=25352#a25352 Any thoughts would be welcome.
Bird-style LHS adds an implied layer of indentation, so it's difficult to use both styles within the same file. You can run "ghc -E starsystem.lhs; cat starsystem.hspp" to see what GHC is reading the file as, after pre-processing. But, **why** would you use both in the same file? The resulting code can't easily be embedded into a TeX document, nor formatted properly by email clients. There's no point to using both; just pick one.
The reason why is that bird is better for short code and \begin{code}
is better for longer code. I will just add a bird-track support to my
editor.
On May 6, 11:29 am, John Millikin
Bird-style LHS adds an implied layer of indentation, so it's difficult to use both styles within the same file. You can run "ghc -E starsystem.lhs; cat starsystem.hspp" to see what GHC is reading the file as, after pre-processing.
But, **why** would you use both in the same file? The resulting code can't easily be embedded into a TeX document, nor formatted properly by email clients. There's no point to using both; just pick one. _______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe
-- You received this message because you are subscribed to the Google Groups "Haskell-cafe" group. To post to this group, send email to haskell-cafe@googlegroups.com. To unsubscribe from this group, send email to haskell-cafe+unsubscribe@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/haskell-cafe?hl=en.
On Thursday 06 May 2010 17:02:59, Iæfai wrote:
I have an lhs file, 'starsystem.lhs' that is not compiling because of a parse error.
I cannot figure out what the problem here is.
Apparently, unlit doesn't manage to cope with mixed LaTeX and bird-track. http://haskell.org/onlinereport/syntax-iso.html#sect9.4 says: "It is not advisable to mix these two styles in the same file." The output of unlit looks like: ---------------------------------------------------------------------- #line 1 "parseErr.lhs" {-# LANGUAGE ForeignFunctionInterface #-} import Graphics.Rendering.OpenGL as GL import Graphics.UI.GLFW as GLFW foreign import ccall unsafe "unbundled" c_unbundled :: IO () data Action = Action (IO Action) main :: IO () main = do c_unbundled GLFW.initialize -- open window ---------------------------------------------------------------------- (snipped most). You can see the parse error there, can't you? Maybe file a GHC bug/feature request?
I have tried it in a regular hs file and it works. I have posted full source here: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=25352#a25352
Any thoughts would be welcome.
I can certainly see the parse error there, yes. Might file a bug then,
it should work, despite John's logic that there is no reason to.
On May 6, 11:35 am, Daniel Fischer
On Thursday 06 May 2010 17:02:59, Iæfai wrote:
I have an lhs file, 'starsystem.lhs' that is not compiling because of a parse error.
I cannot figure out what the problem here is.
Apparently, unlit doesn't manage to cope with mixed LaTeX and bird-track.http://haskell.org/onlinereport/syntax-iso.html#sect9.4says: "It is not advisable to mix these two styles in the same file."
The output of unlit looks like: ---------------------------------------------------------------------- #line 1 "parseErr.lhs" {-# LANGUAGE ForeignFunctionInterface #-}
import Graphics.Rendering.OpenGL as GL import Graphics.UI.GLFW as GLFW
foreign import ccall unsafe "unbundled" c_unbundled :: IO ()
data Action = Action (IO Action)
main :: IO () main = do c_unbundled GLFW.initialize -- open window ----------------------------------------------------------------------
(snipped most). You can see the parse error there, can't you?
Maybe file a GHC bug/feature request?
I have tried it in a regular hs file and it works. I have posted full source here: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=25352#a25352
Any thoughts would be welcome.
_______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe
-- You received this message because you are subscribed to the Google Groups "Haskell-cafe" group. To post to this group, send email to haskell-cafe@googlegroups.com. To unsubscribe from this group, send email to haskell-cafe+unsubscribe@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/haskell-cafe?hl=en.
On Thursday 06 May 2010 17:35:58, Daniel Fischer wrote:
Apparently, unlit doesn't manage to cope with mixed LaTeX and bird-track.
Ah, overlooked "The program text is recovered by taking only those lines beginning with ">", and replacing the leading ">" with a space. Layout and comments apply exactly as described in Chapter 9 in the resulting text." So unlit does exactly what the report demands, you need to indent the \begin{code}-\end{code} enclosed code to the same level as the bird- tracked.
participants (3)
-
Daniel Fischer -
Iæfai -
John Millikin