Parsec as a Dependency?

[Thomas Schilling]

On 6/11/07, Ian Lynagh <igloo at earth.li> wrote:
>
> Hi Thomas,
>
> On Sun, Jun 10, 2007 at 03:44:14PM +0200, Thomas Schilling wrote:
> >
> > now that .cabal files are getting a more complex syntax (due to
> > configurations), I'd really like to use Parsec instead of lots of
> > hand-written and hard to maintain parsing code.  By getting rid of
> > ReadP-based field parsing, we'd also get proper error messages for
> > field values.
> >
> > At the Parsec homepage I says that it's now included by default in
> > GHC, Hugs and NHC,
>
> As Simon said, unfortunately as of 6.8 it won't be included with GHC (as
> things stand, at least).
>
> alex+happy is another alternative, although I don't know off-hand if
> hugs/nhc/... can build them currently.
>
> Have you got a description of the grammar you want to parse?
>
> I'd like it if we could say
>     if flag(foo) {
>         other-modules: Foo
>                        Bar
>                        Baz
>         ghc-options: -wibble
>     }
> which needs some sort of layout rule for the module list. If we go for
> something like that then I wouldn't be surprised if this wasn't easiest
> to parse with just ad-hoc code, which would avoid any dependencies and
> give good error messages.
>
> The parser would only parse it down to something like
>
>     Cond (Flag "foo) [Pair "other-modules:" "Foo\n   Bar\n   Baz\n",
>                       Pair "ghc-options:" "-wibble\n"]
>
> and these would then be further parsed by their own little parsers.
>
>
>
> Just looked at
> http://hackage.haskell.org/trac/hackage/wiki/CabalConfigurations
>
> I'd also suggest putting the top block of your example on that page in
>     General { ... }
> (or some better name) and the next two in
>     Flag: fps_in_base { ... }
>     Flag: debug { ... }

The current syntax looks like this:

Name: Foo
Version: 0.1
...

Flag name {
  Description: ...
}

...

Library {
  Build-Depends: ...
  if os(freebsd) && flag(foo) {
    Build-Depends: ...
  }
  some-flag: ...
}

Executable name {
  ...
}

...

}


I first parse it into the general syntactic constructs
(field-description, section, or if-statement) and then transform it
into something like an AST which then gets parsed into the existing
back-end structure, depending on the flags and available dependencies.
 The code however is rather ugly and ad-hoc.  But since we won't need
the full parsec anyways, maybe i can extract some combinators and will
be fine.

/Thomas
-- 
"Remember! Everytime you say 'Web 2.0' God kills a startup!" -
userfriendly.org, Jul 31, 2006