Hi, I've been spending a bit of time looking into using Parsec as a parser for a subset of the syntax of the Haskell language, a high level description of what I'm looking to create is a parser which confirms whether a given Haskell code file is valid or in the case that it isn't returns some helpful error messages to the user. (Please bear with me, I know this is a strange implementation) My question is that while I have a modest understanding of Parsec from tutorials, the haskell-src package has also been recommended of which I can find very limited documentation in comparison. However, the issue arises from both my limited understanding of haskell and lack of information on the usage of haskell-src. Can anybody provide me with some guidance on whether to try and create the parser using Parsec or if haskell-src is a better option. In the case that haskell-src is a better option, are there any tutorials or documents that I would benefit from reading? Thanks in advance, Seán
Hi Sean,
1. Please do not confuse haskell-src and haskell-src-exts. You should
definitely use the latter. I also find it relatively well documented.
2. If your goal is to write a tool and not to write a Haskell parser as
an exercise, then I would recommend haskell-src-exts. Another option
is the GHC API.
If you have any particular questions or difficulties with these
libraries, feel free to post them here.
Roman
* Sean Cormican
Hi,
I've been spending a bit of time looking into using Parsec as a parser for a subset of the syntax of the Haskell language, a high level description of what I'm looking to create is a parser which confirms whether a given Haskell code file is valid or in the case that it isn't returns some helpful error messages to the user. (Please bear with me, I know this is a strange implementation)
My question is that while I have a modest understanding of Parsec from tutorials, the haskell-src package has also been recommended of which I can find very limited documentation in comparison. However, the issue arises from both my limited understanding of haskell and lack of information on the usage of haskell-src.
Can anybody provide me with some guidance on whether to try and create the parser using Parsec or if haskell-src is a better option. In the case that haskell-src is a better option, are there any tutorials or documents that I would benefit from reading?
Thanks in advance, Seán
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On 2 February 2013 20:08, Sean Cormican
Can anybody provide me with some guidance on whether to try and create the parser using Parsec or if haskell-src is a better option. In the case that haskell-src is a better option, are there any tutorials or documents that I would benefit from reading?
As Roman Cheplyaka says, go with Haskell-src-exts... Haskell-src-exts parses real Haskell - including most (if not all?) GHC extensions. If you were wanting to analyze 'in the wild' Haskell projects you might also want to use CPPHS as many Haskell projects use the CPP preprocessor. Once you have chosen the appropriate parse function (I remember that haskell-src-exts provides quite a few) there is not much work to using haskell-src-exts. Writing your own parser with Parsec would be quite a lot of work. But it would it might be an advantage if you want, say, custom error reporting. Also, if your micro-Haskell is not actually a proper subset of Haskell, then you would have to write your own parser. The original distribution of Parsec (available from Dann Leijen's legacy page at the Utrecht University) has parsers for two small functional languages Mondrian and Henk that are syntactically quite close to Haskell. These are useful starting points if you choose the Parsec route.
On 2/3/13 12:27 AM, Stephen Tetley wrote:
Haskell-src-exts parses real Haskell - including most (if not all?) GHC extensions. If you were wanting to analyze 'in the wild' Haskell projects you might also want to use CPPHS as many Haskell projects use the CPP preprocessor.
That was something that surprised me when I first started using haskell-src-exts. Since haskell-src-exts parses language pragmas (including the CPP pragma), and since the haskell-src-exts package depends on the cpphs package, I'd made the assumption it would run the C preprocessor if the source file asked for the CPP language extension. So, I was surprised when it didn't; it might be worth documenting that it doesn't run CPP for you. (From reading the source, I discovered the reason it depends on the cpphs package is to run the unlit preprocessor, but not to run cpp itself.) I'm still a beginning Haskeller, so this code might be ugly, but I wrote a little bit of code to determine whether the C preprocessor was requested by the source file, and run it if necessary: stripShebang :: String -> String stripShebang ('#':'!':rest) = tail $ dropWhile (/= '\n') rest stripShebang s = s -- extension ".lhs" is same criterion haskell-src-exts uses to decide unlit perhapsUnlit fn contents = if ".lhs" `isSuffixOf` fn then unlit fn contents else contents parseFileWithCpp :: Maybe CpphsOptions -> Maybe ParseMode -> FilePath -> IO (ParseResult (Module SrcSpanInfo, [Comment])) parseFileWithCpp chopts pmode fn = do contents <- readFile fn let pmode' = fromMaybe (ParseMode fn [] False False (Just baseFixities)) pmode exts = fromMaybe [] $ readExtensions $ perhapsUnlit fn $ stripShebang contents pmode'' = if ignoreLanguagePragmas pmode' then pmode' else pmode' { extensions = nub (exts ++ extensions pmode'), -- since we already read language pragmas... ignoreLanguagePragmas = True } wannaCpp = CPP `elem` extensions pmode'' chopts' = fromMaybe defaultCpphsOptions chopts -- haskell-lang-exts already handles unlit itself, so defer to that chopts'' = chopts' { boolopts = (boolopts chopts') { literate = False } } doCpp = if wannaCpp then runCpphs else (\_ _ -> return) contents' <- doCpp chopts'' fn contents return $ parseFileContentsWithComments pmode'' contents' Although this is fairly short, it isn't entirely trivial, and since it seems like using haskell-src-exts together with cpphs is something many people would want to do, I'm wondering if I should contribute a small module to Hackage ("haskell-src-exts-cpp", perhaps) with this function and perhaps a few other functions I've discovered are useful when using haskell-src-exts. Also, just a meta-question: if I encounter bugs or want to suggest features for a package like haskell-src-exts, am I better off bringing them up on a mailing list such as this one, or should I just email the author directly? (Since haskell-src-exts, according to its Hackage page, doesn't have a bug tracker or real home page, just a darcs repository.) --Patrick
* Patrick Pelletier
On 2/3/13 12:27 AM, Stephen Tetley wrote:
Haskell-src-exts parses real Haskell - including most (if not all?) GHC extensions. If you were wanting to analyze 'in the wild' Haskell projects you might also want to use CPPHS as many Haskell projects use the CPP preprocessor.
That was something that surprised me when I first started using haskell-src-exts. Since haskell-src-exts parses language pragmas (including the CPP pragma), and since the haskell-src-exts package depends on the cpphs package, I'd made the assumption it would run the C preprocessor if the source file asked for the CPP language extension. So, I was surprised when it didn't; it might be worth documenting that it doesn't run CPP for you. (From reading the source, I discovered the reason it depends on the cpphs package is to run the unlit preprocessor, but not to run cpp itself.)
The reason is historical confusion about cpphs licensing. Hopefully it'll be fixed soon.
Also, just a meta-question: if I encounter bugs or want to suggest features for a package like haskell-src-exts, am I better off bringing them up on a mailing list such as this one, or should I just email the author directly?
It really depends on the project...
(Since haskell-src-exts, according to its Hackage page, doesn't have a bug tracker or real home page, just a darcs repository.)
Since recently, its issue tracker lives here: https://code.google.com/p/haskell-src-exts/issues/list Roman
participants (4)
-
Patrick Pelletier -
Roman Cheplyaka -
Sean Cormican -
Stephen Tetley