Language.C deriving (Show)

[John Van Enk]

As far as the Show instances are concerned, some one in #haskell pointed me
to {-# OPTIONS -XStandaloneDeriving #-}.

I as able to define all of the needed instances in my module instead of
hacking Language.C to include it.

deriving instance Show CTranslUnit
deriving instance Show CExtDecl
deriving instance Show CStrLit
deriving instance Show CFunDef
deriving instance Show CDecl
deriving instance Show CStat
deriving instance Show CDeclr
deriving instance Show CDeclSpec
deriving instance Show CInit
deriving instance Show CExpr
deriving instance Show CAsmStmt
deriving instance Show CBlockItem
deriving instance Show CAttr
deriving instance Show CDerivedDeclr
deriving instance Show CTypeQual
deriving instance Show CTypeSpec
deriving instance Show CDesignator
deriving instance Show CBuiltin
deriving instance Show CConst
deriving instance Show CAsmOperand
deriving instance Show CArrSize
deriving instance Show CEnum
deriving instance Show CStructUnion
deriving instance Show CStructTag

This came in quite handy when I wanted to know the structure of what was
parsed. It is still messy, but makes working with the AST much easier
(especially if you're trying to hack something quick).

As far as the record syntax is concerned, perhaps a generic query setup
would be better. The (seemingly trivial) case where I first wanted to have
record syntax was finding the names of all the top level function
declarations.

I had to do a lot of pattern matching to get down to the function names
(CTranslUnit -> CExtDecl -> CFDefExt -> CFunDef -> CDeclr).

I think things like unCTranslUnit would come in handy (along with some
utilities like isFunDef).

I think I need to look at quasiquotation again. That does appear to be
useful in this case.

/jve


On Sun, Feb 15, 2009 at 9:54 AM, Joe Thornber <joe.thornber at gmail.com>wrote:

> 2009/2/15 Benedikt Huber <benedikt.huber at gmail.com>:
> >
> > On 13.02.2009, at 19:58, John Van Enk wrote:
> >
> >> Benedikt,
> >>
> >> Have you considered adding a derived show clause to Language.C? I
>
> I think a pretty printer for the AST itself would indeed be useful.
> There have been a couple of occasions where I've been no idea why my
> generic query doesn't work - obviously the parsed AST wasn't what I
> expected, but I didn't really have a way of finding out what it
> actually was.
>
> I have tried the examples/sourceview program, but it provides limited
> information so far.
>
> >> One other thing, is there a plan in the future to convert your data
> >> structure to using the record syntax?
> > This is certainly something to think about, though I'd say e.g.
> > expressions don't benefit as much from record syntax as
> > declarations do. Do you suggest to use records for all AST types, or
> > just some of them (as ghc does) ?
>
> For most of the little uses I have for language-c quasi-quoting
> support would make a big difference.  It has obvious applications for
> code generation, but I also think that a quasi-quoted query language
> would remove the need for most people to handle the AST directly.  For
> example I may be interested in finding out the places in a C codebase
> where someone assigns a value within an if-condition.  It would be
> much nicer to be able to say something like:
>
>  runQuery $ parseQuery [|c-query| if (:x = :y)|]
>
> than have to grapple with the AST directly and write a generic query.
>
> - Joe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.haskell.org/pipermail/language-c/attachments/20090215/7b71f1ca/attachment.html