rious different goals in mind that we can address at once.
>>
>>
>>
>> Selfishly, I don’t really want to review code until I have a very clear
>> picture of what it is trying to achieve. (And I’m rushing towards the POPL
>> deadline anyway!)
>>
>>
>
t you’ll
> have to lead me through it!
>
>
>
> No hurry, just when you are ready.
>
>
>
> Simon
>
>
>
> From: Edsko de Vries [mailto:edskodevr...@gmail.com]
> Sent: 26 June 2013 09:21
> To: Luite Stegeman
> Cc: Simon Peyton-Jones; Thomas Schilling; ghc-devs@h
2013 18:02
To: Simon Peyton-Jones
Cc: Luite Stegeman; Thomas Schilling; ghc-devs@haskell.org; Nicolas Frisby
Subject: Re: Patch/feature proposal: "Source plugins"
Ok, sorry all for the delay. Attached is a "frontend plugins" patch for ghc
7.4.2. It will not work for ghc HEA
> ** **
>
> Simon
>
> ** **
>
> *From:* Edsko de Vries [mailto:edskodevr...@gmail.com]
> *Sent:* 26 June 2013 09:21
> *To:* Luite Stegeman
> *Cc:* Simon Peyton-Jones; Thomas Schilling; ghc-devs@haskell.org
>
> *Subject:* Re: Patch/feature proposal: "Sour
gt;>
>> Simon
>>
>> ** **
>>
>> *From:* Edsko de Vries [mailto:edskodevr...@gmail.com]
>> *Sent:* 26 June 2013 09:21
>> *To:* Luite Stegeman
>> *Cc:* Simon Peyton-Jones; Thomas Schilling; ghc-devs@haskell.org
>>
>> *Subject:* Re: Patch/f
t;
> ** **
>
> *From:* Edsko de Vries [mailto:edskodevr...@gmail.com]
> *Sent:* 26 June 2013 09:21
> *To:* Luite Stegeman
> *Cc:* Simon Peyton-Jones; Thomas Schilling; ghc-devs@haskell.org
>
> *Subject:* Re: Patch/feature proposal: "Source plugins"
>
> ** *
;ll
have to lead me through it!
No hurry, just when you are ready.
Simon
From: Edsko de Vries [mailto:edskodevr...@gmail.com]
Sent: 26 June 2013 09:21
To: Luite Stegeman
Cc: Simon Peyton-Jones; Thomas Schilling; ghc-devs@haskell.org
Subject: Re: Patch/feature proposal: "Source plugins"
Hi L
etails here, but I'm open to suggestions (patches,
>> even) that improve the GHC API.
>>
>> Simon
>>
>> | -Original Message-
>> | From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
>> | On Behalf Of Thomas Schilling
>> |
:ghc-devs-boun...@haskell.org
>> ]
>> | On Behalf Of Thomas Schilling
>> | Sent: 11 June 2013 12:53
>> | To: Edsko de Vries
>> | Cc: ghc-devs@haskell.org
>> | Subject: Re: Patch/feature proposal: "Source plugins"
>> |
>> | On 5 June 2013 13:
ne 2013 12:53
> | To: Edsko de Vries
> | Cc: ghc-devs@haskell.org
> | Subject: Re: Patch/feature proposal: "Source plugins"
> |
> | On 5 June 2013 13:51, Edsko de Vries wrote:
> | > It is a little bit messy mostly because parts of the AST get lost
> | along
To: Edsko de Vries
| Cc: ghc-devs@haskell.org
| Subject: Re: Patch/feature proposal: "Source plugins"
|
| On 5 June 2013 13:51, Edsko de Vries wrote:
| > It is a little bit messy mostly because parts of the AST get lost
| along the
| > way: quasi-quotes in the renamer, data t
On 5 June 2013 13:51, Edsko de Vries 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
Sounds good, but for some reason we have HscAsm as a target at the moment
in GHCJS, and set it to HscNothing only after typechecking. I forgot why,
might have something to do with TH. Do you have an implementation of this
patch that i can test it with (even if it's not the final API or really
ugly)
Luite,
On Fri, Jun 7, 2013 at 2:08 PM, Luite Stegeman wrote:
> I'd also be very happy with some plugin interface that allows us to use
> more GhcMake functionality from the GHC API. For GHCJS we would want to run
> our own (STG -> JavaScript) code generator on sources that need to be
> recompile
I'd also be very happy with some plugin interface that allows us to use
more GhcMake functionality from the GHC API. For GHCJS we would want to run
our own (STG -> JavaScript) code generator on sources that need to be
recompiled instead of letting GHC run its pipeline. Do you think that's
possible
+1. I don't have any comments on the technical issues I'm afraid, but
the more ways we can extend GHC without having to change it directly,
the better.
Cheers,
Simon
On 05/06/13 12:51, Edsko de Vries wrote:
Sorry for the earlier mishap, here's the full email.
Hi all,
The plugin mec
Sorry for the earlier mishap, here's the full email.
Hi all,
The plugin mechanism gives access to the program in Core; this suffices for
many but not quite all purposes. Tools that need access to the original AST
can call typecheckModule directly, but of course this requires using the
GHC API dir
Uh. I'm sorry, I don't know why that email got sent, I was still
writing it. Please ignore it for now, will send the full version later :)
On Wed, Jun 5, 2013 at 12:14 PM, Edsko de Vries wrote:
> Hi all,
>
> The plugin mechanism gives access to the program in Core; this suffices
> for many b
Hi all,
The plugin mechanism gives access to the program in Core; this suffices for
many but not quite all purposes. Tools that need access to the original AST
can call typecheckModule directly, but of course this requires using the
GHC API directly. Moreover, even when using the GHC API directly
19 matches
Mail list logo
