Sean Cormican | 2 Feb 21:08 2013
Picon

Parsec Vs. src exts

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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Roman Cheplyaka | 2 Feb 22:23 2013

Re: Parsec Vs. src exts

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 <seancormican1 <at> gmail.com> [2013-02-02 20:08:48+0000]
> 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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
Stephen Tetley | 3 Feb 09:27 2013
Picon

Re: Parsec Vs. src exts

On 2 February 2013 20:08, Sean Cormican <seancormican1 <at> gmail.com> wrote:

> 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.
Patrick Pelletier | 3 Feb 19:57 2013

Re: Parsec Vs. src exts

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
Roman Cheplyaka | 3 Feb 23:59 2013

Re: Parsec Vs. src exts

* Patrick Pelletier <code <at> funwithsoftware.org> [2013-02-03 10:57:14-0800]
> 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

Gmane