I'm confused as to details here.
* Edsko is doing something; Nick is doing something else (attached for
completeness).
* I can't locate a Trac Wiki page that describes the design
I'm more than happy to adopt patches that improve the plugin API, but you'll
have to lead me through it!
No hurry, just when you are ready.
Simon
From: Edsko de Vries [mailto:[email protected]]
Sent: 26 June 2013 09:21
To: Luite Stegeman
Cc: Simon Peyton-Jones; Thomas Schilling; [email protected]
Subject: Re: Patch/feature proposal: "Source plugins"
Hi Luite,
I was fully planning on a first version of the patch yesterday, but so far my
efforts were thwarted by annoying problems with dynamic libraries (not --
directly -- related to the patch at all). I will try again today :)
Edsko
On Wed, Jun 26, 2013 at 8:51 AM, Luite Stegeman
<[email protected]<mailto:[email protected]>> wrote:
Any news on this? I'd really like to have this in GHC 7.8.1 so that we can
release a fully working GHCJS with GhcMake functionality based on it. I'd be
happy to help write the patch.
luite
On Tue, Jun 11, 2013 at 3:21 PM, Simon Peyton-Jones
<[email protected]<mailto:[email protected]>> wrote:
Guys,
I'm not following the details here, but I'm open to suggestions (patches, even)
that improve the GHC API.
Simon
| -----Original Message-----
| From: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>]
| On Behalf Of Thomas Schilling
| Sent: 11 June 2013 12:53
| To: Edsko de Vries
| Cc: [email protected]<mailto:[email protected]>
| Subject: Re: Patch/feature proposal: "Source plugins"
|
| On 5 June 2013 13:51, Edsko de Vries
<[email protected]<mailto:[email protected]>> wrote:
| > It is a little bit messy mostly because parts of the AST get lost
| along the
| > way: quasi-quotes in the renamer, data type declarations and other
| things
| > during type checking. A more ideal way, but also more time consuming,
| would
| > be to change this so that the renamer leaves evidence of the quasi-
| quotes in
| > the tree, and the type checker returns the entire tree type checked,
| rather
| > than just a subset. I think that ultimately this is the better
| approach, at
| > least for our purposes -- I'm not sure about other tools, but since
| this
| > would be a larger change that affects larger parts of the ghc pipeline
| I'm
| > not sure that I'll be able to do it.
|
| I needed something similar. In particular, I built a custom code
| generator, but now I need a similar feature for extracting information
| from a Haskell file (for IDE features).
|
| Since I needed to modify one-shot compilation mode I couldn't use the
| GHC API. For the IDE stuff I'm using Shake as the build manager, so
| that also needs a customized one-shot mode. For my current
| implementation I just copied and adapted the necessary parts of
| HscMain, DriverPipeline, etc. That's very messy, fragile and breaks
| on every GHC release so I'd really like to see the necessary features
| put into GHC.
|
| Do you have a working patch somewhere?
|
| _______________________________________________
| ghc-devs mailing list
| [email protected]<mailto:[email protected]>
| http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]<mailto:[email protected]>
http://www.haskell.org/mailman/listinfo/ghc-devs
--- Begin Message ---
Just a quick update: I patched a local copy of 7.6.3 to add
FastString.string_table to the CoreMonad.reinitializeGlobals mechanism. After
that change, I can invoke the front-end (parser,renamer,typechecker,desugarer)
from within my plugin on a simple example.
Original module:
> module Test where
>
> data X = X Int Int
Syntax parser from within the plugin:
> data Y = Y X X
> f (Y (X a b) (X c d)) = a + b + c + d
Perhaps this simple example is luckily avoiding some nasty pitfalls, but it
seems to be working.
On Thu, Jun 20, 2013 at 11:27 AM, Nicolas Frisby
<[email protected]<mailto:[email protected]>> wrote:
I'd like to generate new declarations/bindings from within a GHC plugin. My
current concrete goal is just to add a new vanilla data definition, but
long-term it could be more open-ended. Crucially, these new declarations will
reference variables bound by the original module and its imports.
Long-term, it'd be nice if we could invoke the parser/renamer/typechecker in
order to do so. Broadly, the required plumbing seems doable. I wrote a custom
initTc that initializes the TcGblEnv from the ModGuts that the plugin receives.
This is enough to invoke the renamer/typechecker/desugarer. The resulting new
ModGuts can then be merged into the original ModGuts, perhaps after some
Simplification.
Has anyone explored/designed down this path? I've got some questions about a
snag I hit.
Parsing seems fine (superficially) but the renamer fails. I'm re-using the
global Rdr environment from the plugin's input ModGuts, so that free vars from
the new syntax will reference other bindings in the original module and its
imports. However, that environment is keyed on the uniques of FastStrings,
ultimately raising "name not found" errors.
This happens because the global variable for the FastString Table is not
being shared between the actual compiler and the new image of the GHC library
that the plugin is using. One solution seems to be including the FastString
Table in the "reinitializeGlobals" mechanism. This would require a GHC patch.
Questions:
1) Was the FastString Table intentionally left out of the
reinitializeGlobals mechanism?
2) Are there similar obstacles lurking beyond this one that people know
about? How incompatible is the invocation of front-end phases wrt the current
plugin architecture?
My design assumes the HscEnv and ModGuts received by the plugin include
enough information to reconstruct a meaningful TcGblEnv representing the
original module. This seems to be at least nearly true. I am, however, not very
well-versed with how imports are handled (EPS and such), so I don't know if the
FastString Table issue is just the tip of the iceberg.
Thanks for your thoughts.
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
--- End Message ---
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
