Dear all, how can I convince the Language.Haskell.Parser to accept "GHC Haskell" (i.e., -fglasgow-exts, e.g. for existential types) or: how can I convince the GHC API loader to parse a module from a string (not from a file)? Any hints appreciated, Johannes.
how can I convince the Language.Haskell.Parser to accept "GHC Haskell" (i.e., -fglasgow-exts, e.g. for existential types)
You use my haskell-src-exts package instead. :-) http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts-... Cheers, /Niklas
On Mon, Apr 14, 2008 at 12:52:33PM +0200, Niklas Broberg wrote:
how can I convince the Language.Haskell.Parser to accept "GHC Haskell" (i.e., -fglasgow-exts, e.g. for existential types) You use my haskell-src-exts package instead. :-)
Hi Niklas, nice to meet you. And even nicer to see how well your library is supported :) I'm planning to extend shim to get a more featured ide (vim / emacs.. Maybe the Eclipse supporters do join as well?) One thing I'd like to add is adding modules/ import statements to a module. Do you think your' parsers / resulting abstract syntax tree is suited to add some import statements? Or do you suggest hacking my own fuzzy approach? Is it easy to explain the main difference between your output and the output produced by the GHC parser? Sincerly Marc Weber
[...] to add some import statements?
what is your plan? Leif wrote down some ideas (for eclipsefp2) here: http://leiffrenzel.de/eclipse/wiki/doku.php?id=editororganizeimports best regards, J.W.
Hi Niklas, nice to meet you.
Likewise. :-)
I'm planning to extend shim to get a more featured ide (vim / emacs.. Maybe the Eclipse supporters do join as well?)
One thing I'd like to add is adding modules/ import statements to a module. Do you think your' parsers / resulting abstract syntax tree is suited to add some import statements? Or do you suggest hacking my own fuzzy approach?
I'd say that's definitely a good use of haskell-src-exts, and very easy to accomplish. A fuzzy approach sounds scary to me. ;-)
Is it easy to explain the main difference between your output and the output produced by the GHC parser?
I'd say the most striking difference is that the AST used by haskell-src-exts is much much simpler than the GHC one. It's only an AST, it doesn't try to cater to the different passes of a compiler to do renaming or any such nonsense. It is also contained in a single module so it is easy to reference (try digging up where some specific constructor in the GHC AST is defined and you'll appreciate the merit of this). For any project that just needs to parse/fiddle with/print haskell source code, I see very little reason to choose GHC API instead of haskell-src-exts. The only reason is of course that GHC API is guaranteed to be up to date with the latest GHC, and will be able to parse exactly everything that GHC does. On the other hand, haskell-src-exts allows you to handle regular patterns and literal XML syntax a la HSP, which GHC doesn't. :-) Cheers, /Niklas
Niklas Broberg wrote:
For any project that just needs to parse/fiddle with/print haskell source code, I see very little reason to choose GHC API instead of haskell-src-exts.
Does your pretty-printer round trip? One problem I've had using GHC API is that the pretty-printer produces unparseable output. Jesse
Does your pretty-printer round trip?
Absolutely. I'd think a parser that can't parse what the pretty-printer yields means you either have a broken parser or a broken pretty-printer. :-) Except for line numbering (it inserts but doesn't read line pragmas), the AST should be preserved under f = parse . pretty. Cheers, /Niklas
Does your pretty-printer round trip?
Absolutely. I'd think a parser that can't parse what the pretty-printer yields means you either have a broken parser or a broken pretty-printer. :-)
Except for line numbering (it inserts but doesn't read line pragmas), the AST should be preserved under f = parse . pretty.
and what about (pretty . parse) = id :: String -> String ?-) preserving everything that isn't transformed at the AST level would be a necessary starting point for refactoring larger code bases. having easy access to comments and layout information is where most frontends tend to let us down. how much of the source is preserved by (pretty . parse)? layout/comments/pragmas/.. claus ps it is good to hear that src-ext is supported, follows language developments, and is separated from the other parts of your projects!-)
Except for line numbering (it inserts but doesn't read line pragmas), the AST should be preserved under f = parse . pretty.
and what about (pretty . parse) = id :: String -> String ?-)
Most certainly not I'm afraid. It doesn't handle pragmas at all (treats them as comments), and by default it inserts line pragmas in the output (though that can be turned off). Comments are simply discarded, and to be honest I really don't see how they could be kept in general, except in specific pre-defined places (like for Haddock). I'm sure you have ideas on that though. Layout is also not preserved exactly, and do { ... ; ... } results in the same AST as if done with layout instead of { ; }.
preserving everything that isn't transformed at the AST level would be a necessary starting point for refactoring larger code bases. having easy access to comments and layout information is where most frontends tend to let us down.
Indeed, and I'm afraid haskell-src-exts will join the crowd in that regard. But to be honest I'm not sure haskell-src-exts *should* do those things you ask for, since the added machinery would be rather heavy-weight for applications that just want the basic stuff, which I guess is the vast majority of applications.
ps it is good to hear that src-ext is supported, follows language developments, and is separated from the other parts of your projects!-)
Thanks, and yes I try to keep them as separate as possible, knowing their usefulness to others. Cheers, /Niklas
..Comments are simply discarded, and to be honest I really don't see how they could be kept in general, except in specific pre-defined places (like for Haddock). I'm sure you have ideas on that though. Layout is also not preserved exactly, and do { ... ; ... } results in the same AST as if done with layout instead of { ; }.
just recalling some previous discussions: a) add a whitespace&layout field to every AST construct + should work well enough for source location info and for braces yes/no flags - doesn't work so well for comments: do they belong to the next or the previous item, or are they standalone text? b) add a comment construct to the AST + avoids association issue, comments stand on their own - AST traversals have to deal with comments - AST transformations still have to decide which comments to move with which AST fragments + comments in untransformed code remain c) add source location and layout info to every AST construct, keep comments out of the AST, link source locations to comment sections + keeps AST traversals simple - AST transformations still need to decide which comments to move with which AST fragments + allows finding related comments after AST transformations (the ghc ticket suggests two lookup functions, for comments before/after a given AST fragment) + comments in untransformed code remain d) ..? i'd be interested in other alternatives so far, it seems that c is the way to go (HaRe used the Programatica's token stream as comment storage, with every identifier having source location info, and some heuristics for matching comments to AST fragments), though i'd be interested in other alternatives - keeping the parts of a split-up source representation in sync during transformation and weaving everything back together before presentation proved tedious.
Indeed, and I'm afraid haskell-src-exts will join the crowd in that regard. But to be honest I'm not sure haskell-src-exts *should* do those things you ask for, since the added machinery would be rather heavy-weight for applications that just want the basic stuff, which I guess is the vast majority of applications.
would the added machinery really affect applications that don't care about comments/layout? with (c), there'd be one field not to look at and a comment store to ignore. and the bonus would be to enable a large variety of applications based on source to source transformations (refactoring, pretty printing, desugaring, layout<->braces, optimizations, ..). but perhaps that isn't the target for haskell-src-ext, and things like HaRe are currently hoping/aiming for the ghc api.
ps it is good to hear that src-ext is supported, follows language developments, and is separated from the other parts of your projects!-)
Thanks, and yes I try to keep them as separate as possible, knowing their usefulness to others.
keep up the good work!-) claus
participants (5)
-
Claus Reinke -
Jesse Tov -
Johannes Waldmann -
Marc Weber -
Niklas Broberg