use ghc's parser to classify statments/decls instead of haskell-src-exts

[aavogt]

input source code passes through haskell-src-exts parser. This is bad because the HSE parser doesn't support everything ghc does (-XDataKinds for example), and furthermore you would have to keep track of a separate set of extensions.

[gibiansky]

Good idea... I originally avoided ghc's parser due to the lack of clear ghc
api documentation, but switching is probably a good idea.
On Oct 23, 2013 2:31 PM, "aavogt" notifications@github.com wrote:

input source code passes through haskell-src-exts parser. This is bad
because the HSE parser doesn't support everything ghc does (-XDataKinds for
example), and furthermore you would have to keep track of a separate set of
extensions.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/14
.

[gibiansky]

I've had difficulty getting anywhere at all with GHC's parser, mostly due to the absolute lack of overview (and in some modules, specific) documentation.

Do you have any pointers on this issue, by any chance? I ran into this again when dealing with type declarations at the top level.

[aavogt]

My suggestions are

• look at ghci source code
• look at haddocks for ghc-api. There is a GHC.parser to replace parseDecl, and also these ones for the other bits

I am having a go at adapting IHaskell to use this now.

[aavogt]

04c1e6a17a3532d32cf4bf95723e49446e850e98 is kind of complete, but I think I broke imports.

@gibiansky why did you decide to send the smallest possible chunks to ghci at a time? It seems better to send as much as possible to support mutually recursive functions, as the above commit does.

[gibiansky]

No good reason - it was mostly because I did not realize that runDecls would happily take more than one Decl until after I had written the code, so I didn't write code to join many Decls...

I like the general architecture in that commit and it is way better than the sketchy string parsing that I wrote for the original. I haven't read the commit in complete depths but there are a few bits which seemed a bit cryptic to me at first glance; in particular, codeToChunks is a bit dense.

Anyway, looks great :) Once it's ready send a PR and I'll spend a while to review it and hopefully get this merged soon.

[gibiansky]

@aavogt This is finally done! :D

I attempted to build off the work you'd done, but ended up finding several edge cases that were very difficult to handle. The final solution - which seems to work robustly - is to slightly modify the Happy grammar that GHC uses and compile it into IHaskell. This makes development a bit more difficult, but means that it's using the same exact grammar as the version of GHC that it's happy file is from. (Updating will be a bit of a pain, but oh well...)

I haven't yet figured out exactly how to get happy + cpphs to play nicely with cabal, though...

Anyway, seems to pass a bunch of tests and work relatively well, but if you find anything that's broken with it let me know - I'm sure there's something.

Pushed with commit 9ab5b40

[aavogt]

very good. The cabal integration is pretty straightforward: c76b002