Re: GHC 7.8 release status
Hi Nicolas, I apologize if you didn't get the notice I sent last week on the update. Right now I am endlessly battling windows, and while I actually DO have a dynamic GHC working for windows with the DLL split (#5987,) it is segfaulting in the stage2 compiler when compiling the 'time' library, and I am still looking into it for the past day or so. This is really my biggest hold up in pushing some needed fixes (I'll post some details out here on the list soon, so others can help.) I'm working this weekend to try and get a lot of it sorted out and post an update, but I will unfortunately be gone part of Saturday. On Thu, Nov 14, 2013 at 11:45 PM, Nicolas Frisby nicolas.fri...@gmail.com wrote: Unless I missed an RC announcement, I'm pretty sure we're running a little behind the schedule from that email. Deciders, has the Nov 25 target slid back? Any new estimates, if so? Thanks much. On Nov 14, 2013 9:40 PM, Andreas Voellmy andreas.voel...@gmail.com wrote: On Thu, Nov 14, 2013 at 10:38 PM, Andreas Voellmy andreas.voel...@gmail.com wrote: I added a note about the parallel IO manager status to https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8. There are two issues I'd still like to resolve. Is there a target date for the release? Oh, I just noticed http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2569 which answers my question (target is Nov. 25). -Andi On Fri, Nov 8, 2013 at 12:02 AM, Andreas Voellmy andreas.voel...@gmail.com wrote: Yes, the parallel IO manager is new in 7.8. Thanks for reminding me of that excessive system time issue. That's been nagging me for a while. Hopefully I can find some time in the coming days to look at this again. -Andi On Wed, Sep 4, 2013 at 11:42 AM, Ryan Newton rrnew...@gmail.com wrote: By the way, the parallel IO manager is also new in 7.8 right? I'm not sure but I think it may have something to do with the excessive system time bug I just filed: http://ghc.haskell.org/trac/ghc/ticket/8224 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release status
What are ways for other folks to help? (If possible) On Friday, November 15, 2013, Austin Seipp wrote: Hi Nicolas, I apologize if you didn't get the notice I sent last week on the update. Right now I am endlessly battling windows, and while I actually DO have a dynamic GHC working for windows with the DLL split (#5987,) it is segfaulting in the stage2 compiler when compiling the 'time' library, and I am still looking into it for the past day or so. This is really my biggest hold up in pushing some needed fixes (I'll post some details out here on the list soon, so others can help.) I'm working this weekend to try and get a lot of it sorted out and post an update, but I will unfortunately be gone part of Saturday. On Thu, Nov 14, 2013 at 11:45 PM, Nicolas Frisby nicolas.fri...@gmail.com javascript:; wrote: Unless I missed an RC announcement, I'm pretty sure we're running a little behind the schedule from that email. Deciders, has the Nov 25 target slid back? Any new estimates, if so? Thanks much. On Nov 14, 2013 9:40 PM, Andreas Voellmy andreas.voel...@gmail.comjavascript:; wrote: On Thu, Nov 14, 2013 at 10:38 PM, Andreas Voellmy andreas.voel...@gmail.com javascript:; wrote: I added a note about the parallel IO manager status to https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8. There are two issues I'd still like to resolve. Is there a target date for the release? Oh, I just noticed http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2569 which answers my question (target is Nov. 25). -Andi On Fri, Nov 8, 2013 at 12:02 AM, Andreas Voellmy andreas.voel...@gmail.com javascript:; wrote: Yes, the parallel IO manager is new in 7.8. Thanks for reminding me of that excessive system time issue. That's been nagging me for a while. Hopefully I can find some time in the coming days to look at this again. -Andi On Wed, Sep 4, 2013 at 11:42 AM, Ryan Newton rrnew...@gmail.comjavascript:; wrote: By the way, the parallel IO manager is also new in 7.8 right? I'm not sure but I think it may have something to do with the excessive system time bug I just filed: http://ghc.haskell.org/trac/ghc/ticket/8224 ___ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release status
I added a note about the parallel IO manager status to https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8. There are two issues I'd still like to resolve. Is there a target date for the release? -Andi On Fri, Nov 8, 2013 at 12:02 AM, Andreas Voellmy andreas.voel...@gmail.comwrote: Yes, the parallel IO manager is new in 7.8. Thanks for reminding me of that excessive system time issue. That's been nagging me for a while. Hopefully I can find some time in the coming days to look at this again. -Andi On Wed, Sep 4, 2013 at 11:42 AM, Ryan Newton rrnew...@gmail.com wrote: By the way, the parallel IO manager is also new in 7.8 right? I'm not sure but I think it may have something to do with the excessive system time bug I just filed: http://ghc.haskell.org/trac/ghc/ticket/8224 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release status
Unless I missed an RC announcement, I'm pretty sure we're running a little behind the schedule from that email. Deciders, has the Nov 25 target slid back? Any new estimates, if so? Thanks much. On Nov 14, 2013 9:40 PM, Andreas Voellmy andreas.voel...@gmail.com wrote: On Thu, Nov 14, 2013 at 10:38 PM, Andreas Voellmy andreas.voel...@gmail.com wrote: I added a note about the parallel IO manager status to https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8. There are two issues I'd still like to resolve. Is there a target date for the release? Oh, I just noticed http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2569 which answers my question (target is Nov. 25). -Andi On Fri, Nov 8, 2013 at 12:02 AM, Andreas Voellmy andreas.voel...@gmail.com wrote: Yes, the parallel IO manager is new in 7.8. Thanks for reminding me of that excessive system time issue. That's been nagging me for a while. Hopefully I can find some time in the coming days to look at this again. -Andi On Wed, Sep 4, 2013 at 11:42 AM, Ryan Newton rrnew...@gmail.com wrote: By the way, the parallel IO manager is also new in 7.8 right? I'm not sure but I think it may have something to do with the excessive system time bug I just filed: http://ghc.haskell.org/trac/ghc/ticket/8224 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release status
Thanks for the reminder. Wiki is updated; atomics branch is merged. The only further work I plan to do in the near term is add additional tests. On Wed, Sep 4, 2013 at 9:52 AM, Simon Peyton-Jones simo...@microsoft.comwrote: Friends The 7.8 release is imminent. This email is to ask abou the status of your contributions*. In each case could you update the wiki with the current state of play, and your intentions, including dates. * That is, don’t put your reply in email: it on the status page below; though by all means send email too! Summary here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 *Also : What is missing from the list that should be done?* **· ***Patrick Palka*: status of ghc –make –j? **· ***Nick*: status of your three items? **· ***Pedro/Richard*: is all the Typeable stuff, and gcast and friends, finished? **· ***Geoff*: what about the new Template Haskell story? **· ***Iavor*: when do you think you can merge? **· ***Austin*: what about ARMv7? **· ***Edsko/Thomas/Luite*: if you want anything for 7.8 it’ll have to be jolly soon. At the moment I don’t even know the motivation or design, let alone implementation. Could you make a wiki page explaining the proposed design? Is it really important to do this for 7.8? **· ***Dynamic GHCi*. I have no idea who is driving this, or how important it is. **· ***Ryan*: atomic stuff. All merged? **· ***AMP warnings*: David Luposchainsky is driving this. ** ** Thanks! Simon *Microsoft Research Limited (company number 03369488) is registered in England and Wales * *Registered office is at 21 Station Road, Cambridge, CB1 2FB* ** ** ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: GHC 7.8 release status
I do need more than a patch, please, please. A wiki page explaining the design, as seen by the user (of the GHC API), the problems it solves, and the use-cases it enables, would be most helpful. Simon | -Original Message- | From: Thomas Schilling [mailto:nomin...@googlemail.com] | Sent: 04 September 2013 17:26 | To: Simon Peyton-Jones; Luite Stegeman | Cc: Nicolas Frisby; Pedro Magalhães (drei...@gmail.com); Richard | Eisenberg (e...@cis.upenn.edu); Geoffrey Mainland | (mainl...@cs.drexel.edu); Iavor Diatchki; Austin Seipp; Edsko de Vries; | Ryan Newton (rrnew...@gmail.com); David Luposchainsky; ghc- | d...@haskell.org | Subject: Re: GHC 7.8 release status | | | On 4 Sep 2013, at 15:52, Simon Peyton-Jones simo...@microsoft.com | wrote: | | Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be | jolly soon. At the moment I don't even know the motivation or design, | let alone implementation. Could you make a wiki page explaining the | proposed design? Is it really important to do this for 7.8? | | Yes, it is quite important to get this into 7.8. Not having these | features in GHC makes it very difficult for people to adopt GHCJS. One | could argue that GHCJS is not yet production-ready anyway and users that | want to try it can figure out building GHC from source to use it, but | this doesn't quite apply. | | 1. GHCJS targets a wider audience than users brave enough to compile | GHC from source. In addition, the next chance to get these features into | GHC is in a year from now, so when GHCJS becomes more mature then this | will be a major hurdle for adoption. | | 2. These changes are also required for IDE tools which really mustn't | require users to build a custom version of GHC. | | | Luite's design is actually very flexible. It simply allows GHC API | users to provide functions that are called instead of (or in addition | to) existing functions in GHC. Instead of calling, say, genHardCode, | the driver now looks up whether the user has specified a hook for | genHardCode and calls that instead. | | Currently we only specify a small number of hooks that are sufficient | for our use cases. Future releases of GHC can be extended to include | more hooks, if that is needed. | | Hooks are stored as an untyped map inside the DynFlags (to avoid issues | with circular dependencies). Each hook is looked up using a single- | constructor type and type families are used to make this type safe. | There is one use of unsafeCoerce to avoid having to make every hook | function an instance of Typeable. | | Unlike CorePlugins, it is only a GHC API feature, and users cannot | specify plugins to be added via command line options. If we can come up | with a good design, then we could add this in GHC 7.10, but it is not | necessary at this point. | | Luite: Do you have a link to your latest patch? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release status
Thank you Ryan! I'll be getting my ARMv7 build machine back online today, hopefully. Jens Peterson reported he had a working ARMv7 build to me today from HEAD, which is good news. On Wed, Sep 4, 2013 at 10:15 AM, Ryan Newton rrnew...@gmail.com wrote: Thanks for the reminder. Wiki is updated; atomics branch is merged. The only further work I plan to do in the near term is add additional tests. On Wed, Sep 4, 2013 at 9:52 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Friends The 7.8 release is imminent. This email is to ask abou the status of your contributions. In each case could you update the wiki with the current state of play, and your intentions, including dates. That is, don’t put your reply in email: it on the status page below; though by all means send email too! Summary here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 Also : What is missing from the list that should be done? · Patrick Palka: status of ghc –make –j? · Nick: status of your three items? · Pedro/Richard: is all the Typeable stuff, and gcast and friends, finished? · Geoff: what about the new Template Haskell story? · Iavor: when do you think you can merge? · Austin: what about ARMv7? · Edsko/Thomas/Luite: if you want anything for 7.8 it’ll have to be jolly soon. At the moment I don’t even know the motivation or design, let alone implementation. Could you make a wiki page explaining the proposed design? Is it really important to do this for 7.8? · Dynamic GHCi. I have no idea who is driving this, or how important it is. · Ryan: atomic stuff. All merged? · AMP warnings: David Luposchainsky is driving this. Thanks! Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC 7.8 release status
Friends The 7.8 release is imminent. This email is to ask abou the status of your contributions. In each case could you update the wiki with the current state of play, and your intentions, including dates. That is, don't put your reply in email: it on the status page below; though by all means send email too! Summary here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 Also : What is missing from the list that should be done? · Patrick Palka: status of ghc -make -j? · Nick: status of your three items? · Pedro/Richard: is all the Typeable stuff, and gcast and friends, finished? · Geoff: what about the new Template Haskell story? · Iavor: when do you think you can merge? · Austin: what about ARMv7? · Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be jolly soon. At the moment I don't even know the motivation or design, let alone implementation. Could you make a wiki page explaining the proposed design? Is it really important to do this for 7.8? · Dynamic GHCi. I have no idea who is driving this, or how important it is. · Ryan: atomic stuff. All merged? · AMP warnings: David Luposchainsky is driving this. Thanks! Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release status
By the way, the parallel IO manager is also new in 7.8 right? I'm not sure but I think it may have something to do with the excessive system time bug I just filed: http://ghc.haskell.org/trac/ghc/ticket/8224 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 Release Status Schedule
On Sat, Oct 5, 2013 at 9:25 AM, Austin Seipp aus...@well-typed.com wrote: - Nov 1st: Cut branch, and I plan on making a 7.8 RC1 available the same day, for several platforms. Hi, Austin - Thanks for writing this up. One of the factors that's blocking my ability to build Hackage packages is that Hackage does not contain versions of a number of bundled-with-GHC packages that have versions matching the versions shipping with HEAD. It would unblock that process somewhat if you were to upload new versions of unix and various other packages that are not yet in sync fairly soon, preferably well before cutting the branch. Thanks! ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 Release Status Schedule
Indeed. There's a few straggling things but overall we're in feature freeze overall right now, right? On Wednesday, October 9, 2013, Johan Tibell wrote: On Wed, Oct 9, 2013 at 4:07 PM, Bryan O'Sullivan b...@serpentine.comjavascript:; wrote: One of the factors that's blocking my ability to build Hackage packages is that Hackage does not contain versions of a number of bundled-with-GHC packages that have versions matching the versions shipping with HEAD. It would unblock that process somewhat if you were to upload new versions of unix and various other packages that are not yet in sync fairly soon, preferably well before cutting the branch. Thanks! +1. Forgetting to upload GHC released packages altogether (even after the release) has been a problem in the past. I think we should aim for making releases of all the packages GHC ships with before we make the actual release. It will make sure 1) that's not forgotten and 2) people have more time to fix their packages. There's clearly a tension here: GHC might change last minute and break one of the just released packages again, forcing another release. If we release the packages once we enter feature freeze for GHC, that should be a rare occurrence. ___ ghc-devs mailing list ghc-devs@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
GHC 7.8 Release Status Schedule
Friends, After talking with Simon yesterday, we have some idea of how the release will go. As I'm sure you're aware, the release is winding down rather quickly, and it will be a fantastic one hopefully :) Now that all the features have landed, we're going into bugfixing mode. The schedule is, roughly: - Nov 1st: Cut branch, and I plan on making a 7.8 RC1 available the same day, for several platforms. - Release will be ~3 weeks out from there, approximately Nov 25th. This gives us a month of solid bugfixing. During the 3 weeks with the 7.8 branch open, I'm a bit hesitant to land massive changes, so that our branches don't diverge too far. OTOH, a few things can probably land in this timeframe with minimal disturbances (such as the Applicative-Monad change.) If you want to land something in that time frame, please just ask me. On the whole, things actually feel pretty good - although there a few nasty bugs to sort out, the uptake in community involvement has simply been fantastic (definitely related to the number bugs we've found,) and I think we're on track to sort the remaining stuff out. A great thanks to all of the new people helping out! And if you want to help even more, please check out the tickets remaining for 7.8.1: http://ghc.haskell.org/trac/ghc/query?status=!closedmilestone=7.8.1order=priority If you think you can take on a bug, please assign it to yourself so we know what's going on. Note: if the bug isn't *high* or *highest*, it's unlikely to get looked at, at least by me! It won't be rejected if you submit a patch, but I'm simply not going to be able to get to it I'm afraid. So please grab something, and go for it! I am also reminded that the GHC October Status report will be due shortly - I'll take some time to write it up, and follow through here on the list (and glasgow-haskell-users) so interested parties can read up on what is happening. -- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release status
Hi all, So I managed to remove 3 out of 4 of the -boot files. The one that remains, ironically, is the DsMonad.hs-boot. DsMonad has a (transitive) dependency on Hooks in at least two ways: once through Finder, which imports Packages, which imports Hooks; but that's easily solved, because Finder can import PackageState instead. However, it is less obvious to me how to resolve the following import cycle - DsMonad imports tcIfaceGlobal from TcIface - TcIface imports (loadWiredInHomeIface, loadInterface, loadDecls, findAndReadIface) from LoadIface - LoadIFace imports Hooks (There might be still others, this is the most direct one at the moment.) (Just to be clear, Hooks imports DsMonad because it needs the DsM type for the dsForeignsHook.) I'm sure this cycle can be broken somehow, but I'm not familiar enough with this part of the compiler to see if there is a natural point to do it. As things stand, we have a DsMonad.hs-boot which just exports the DsGblEnv, DsLclEnv, and DsM types. I don't know if this is something we should be worrying about or not? Just to summarize: the hooks patch as things stand now introduces the Hooks enumeration, rather than a separate type per hook so that we have a central and type checked list of all hooks; in order to do that, it moves some things around (some times moves to HscTypes), introduces a new module called PipelineMonad as per SPJ's suggestion, and introduces a single additional boot file for the DsMonad module. Edsko On Tue, Sep 10, 2013 at 12:40 PM, Simon Peyton-Jones simo...@microsoft.com wrote: I do like the single record. I would really really like a strong clear Note [blah] on the hooks::Dynamic field of DynFlags. It’s *so* non-obvious why it’s dynamic, and the reason is a really bad one, namely the windows DLL split nonsense. (Not our fault but still needs very clear signposting.) I don’t understand why we need 4 new hs-boot files. Eg why DsMonad.hs-boot? It should be safely below Hooks. Linker.hs-boot is solely because of LibrarySpec. It would be possible to push that into HscTypes. (Again with a comment to explain why.) DriverPipeline is aleady 2,100 lines long, and could reasonably be split with CompPipeline in the PipelineMonad module, say. In other words, a bit of refactoring might eliminate the loops *and* sometimes arguably improve the code. I don’t feel terribly strongly about all this. It does feel a bit ad hoc… in a variety of places (eg deep in Linker.hs) there are calls to hooks, and it’s not clear to me why exactly those are the right places. But I suppose they are simply driven by what has been needed. Anyway if you two are happy (no one else seems to mind either way) then go ahead. Simon From: Luite Stegeman [mailto:stege...@gmail.com] Sent: 10 September 2013 08:37 To: Edsko de Vries Cc: Simon Peyton-Jones; ghc-devs; Edsko de Vries Subject: Re: GHC 7.8 release status Edsko has done some work of rearranging imports in DynFlags to make the DLL split work, and I've implemented the hooks on top of this, in a record, as discussed: - https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-record.patch (not final yet, but should be usable for testing) - demo program: https://gist.github.com/luite/6506064 Some disadvantages: - as long as the DLL split exists, more restructuring will be required if a new hook is added to something in a module on which DynFlags depends - 4 new hs-boot files required, new hooks will often require additional hs-boot files (when module A has a hook (so A imports Hooks, this can't be a source import), the hook will often have some types defined by A, so Hooks will have to import A) Advantages (over type families / Dynamic hooks): - Hooks neatly defined together in a single record I'm not so sure myself, but if everyone agrees that this is better than the older hooks I'll convert GHCJS to the new implementation later today and finalize the patch (comments are a bit out of date, and I'm not 100% sure yet that GHCJS doesn't need another hook for TH support in certain setups) and update the wiki. luite On Mon, Sep 9, 2013 at 4:55 PM, Edsko de Vries edskodevr...@gmail.com wrote: Simon, I talked to Luite this morning and I think we can come up with a design that includes the enumeration we prefer, with a single use of Dynamic in DynFlags -- it involves splitting off a PackageState module from Packages so that DynFlags doesn't depend on the entirely of Packages anymore (which would then, transitively, mean that it depends on Hooks and hence on a large part of ghc), but I think that should be doable. I'm working on that now. Edsko On Mon, Sep 9, 2013 at 3:51 PM, Simon Peyton-Jones simo...@microsoft.com wrote: Edsko I’m very short of time right now. I think you understand the issues here. Can you do a round or two with Luite and emerge with a design that you both think is best
RE: GHC 7.8 release status
I'm ok with that, thanks. Can you put your comments below into DsMonad.hs-boot so that we don't lose the reasoning? It's devilish hard to work out *why* a hs-boot file must exist, sometimes. Maybe also update http://ghc.haskell.org/trac/ghc/wiki/Commentary/ModuleStructure which tries to document some these loops too. Simon | -Original Message- | From: Edsko de Vries [mailto:edskodevr...@gmail.com] | Sent: 11 September 2013 15:33 | To: Simon Peyton-Jones | Cc: Luite Stegeman; ghc-devs; Edsko de Vries | Subject: Re: GHC 7.8 release status | | Hi all, | | So I managed to remove 3 out of 4 of the -boot files. The one that | remains, ironically, is the DsMonad.hs-boot. DsMonad has a | (transitive) dependency on Hooks in at least two ways: once through | Finder, which imports Packages, which imports Hooks; but that's easily | solved, because Finder can import PackageState instead. However, it is | less obvious to me how to resolve the following import cycle | | - DsMonad imports tcIfaceGlobal from TcIface | - TcIface imports (loadWiredInHomeIface, loadInterface, loadDecls, | findAndReadIface) from LoadIface | - LoadIFace imports Hooks | | (There might be still others, this is the most direct one at the | moment.) | | (Just to be clear, Hooks imports DsMonad because it needs the DsM type | for the dsForeignsHook.) | | I'm sure this cycle can be broken somehow, but I'm not familiar enough | with this part of the compiler to see if there is a natural point to | do it. As things stand, we have a DsMonad.hs-boot which just exports | the DsGblEnv, DsLclEnv, and DsM types. I don't know if this is | something we should be worrying about or not? | | Just to summarize: the hooks patch as things stand now introduces the | Hooks enumeration, rather than a separate type per hook so that we | have a central and type checked list of all hooks; in order to do | that, it moves some things around (some times moves to HscTypes), | introduces a new module called PipelineMonad as per SPJ's suggestion, | and introduces a single additional boot file for the DsMonad module. | | Edsko | | On Tue, Sep 10, 2013 at 12:40 PM, Simon Peyton-Jones | simo...@microsoft.com wrote: | I do like the single record. | | | | I would really really like a strong clear Note [blah] on the | hooks::Dynamic | field of DynFlags. It's *so* non-obvious why it's dynamic, and the | reason is | a really bad one, namely the windows DLL split nonsense. (Not our | fault but | still needs very clear signposting.) | | | | I don't understand why we need 4 new hs-boot files. Eg why | DsMonad.hs-boot? | It should be safely below Hooks. | | | | Linker.hs-boot is solely because of LibrarySpec. It would be possible | to | push that into HscTypes. (Again with a comment to explain why.) | | | | DriverPipeline is aleady 2,100 lines long, and could reasonably be | split | with CompPipeline in the PipelineMonad module, say. | | | | | | In other words, a bit of refactoring might eliminate the loops *and* | sometimes arguably improve the code. | | | | | | I don't feel terribly strongly about all this. It does feel a bit ad | hoc... | in a variety of places (eg deep in Linker.hs) there are calls to | hooks, and | it's not clear to me why exactly those are the right places. But I | suppose | they are simply driven by what has been needed. | | | | Anyway if you two are happy (no one else seems to mind either way) | then go | ahead. | | | | Simon | | | | | | From: Luite Stegeman [mailto:stege...@gmail.com] | Sent: 10 September 2013 08:37 | To: Edsko de Vries | Cc: Simon Peyton-Jones; ghc-devs; Edsko de Vries | | | Subject: Re: GHC 7.8 release status | | | | Edsko has done some work of rearranging imports in DynFlags to make | the DLL | split work, and I've implemented the hooks on top of this, in a | record, as | discussed: | | | | - | https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc- | hooks-record.patch | (not final yet, but should be usable for testing) | | - demo program: https://gist.github.com/luite/6506064 | | | | Some disadvantages: | | - as long as the DLL split exists, more restructuring will be required | if a | new hook is added to something in a module on which DynFlags depends | | - 4 new hs-boot files required, new hooks will often require | additional | hs-boot files (when module A has a hook (so A imports Hooks, this | can't be a | source import), the hook will often have some types defined by A, so | Hooks | will have to import A) | | | | Advantages (over type families / Dynamic hooks): | | - Hooks neatly defined together in a single record | | | | I'm not so sure myself, but if everyone agrees that this is better | than the | older hooks I'll convert GHCJS to the new implementation later today | and | finalize the patch (comments are a bit out of date, and I'm not 100% | sure | yet that GHCJS doesn't need another hook
Re: GHC 7.8 release status
Edsko has done some work of rearranging imports in DynFlags to make the DLL split work, and I've implemented the hooks on top of this, in a record, as discussed: - https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-record.patch(not final yet, but should be usable for testing) - demo program: https://gist.github.com/luite/6506064 Some disadvantages: - as long as the DLL split exists, more restructuring will be required if a new hook is added to something in a module on which DynFlags depends - 4 new hs-boot files required, new hooks will often require additional hs-boot files (when module A has a hook (so A imports Hooks, this can't be a source import), the hook will often have some types defined by A, so Hooks will have to import A) Advantages (over type families / Dynamic hooks): - Hooks neatly defined together in a single record I'm not so sure myself, but if everyone agrees that this is better than the older hooks I'll convert GHCJS to the new implementation later today and finalize the patch (comments are a bit out of date, and I'm not 100% sure yet that GHCJS doesn't need another hook for TH support in certain setups) and update the wiki. luite On Mon, Sep 9, 2013 at 4:55 PM, Edsko de Vries edskodevr...@gmail.comwrote: Simon, I talked to Luite this morning and I think we can come up with a design that includes the enumeration we prefer, with a single use of Dynamic in DynFlags -- it involves splitting off a PackageState module from Packages so that DynFlags doesn't depend on the entirely of Packages anymore (which would then, transitively, mean that it depends on Hooks and hence on a large part of ghc), but I think that should be doable. I'm working on that now. Edsko On Mon, Sep 9, 2013 at 3:51 PM, Simon Peyton-Jones simo...@microsoft.com wrote: Edsko I’m very short of time right now. I think you understand the issues here. Can you do a round or two with Luite and emerge with a design that you both think is best? As I said earlier I’m uncomfortable with doing design work so late in the cycle, and I feel that I don’t have time to study the various alternatives properly in the next four days. But since you tell me it’s crucial for GHCJS, I suppose that a possible compromise is this. We release a GHC with some design for hooks, but specifically say that the hook design is evolving and may well change with the next version. And then you two, with Thomas and other interested parties, work together to evolve a design that everyone is happy with. Does that sound ok? Simon From: Luite Stegeman [mailto:stege...@gmail.com] Sent: 07 September 2013 22:04 To: Simon Peyton-Jones Cc: Thomas Schilling; Edsko de Vries; ghc-devs Subject: Re: GHC 7.8 release status · Why aren’t you using Data.Dynamic for the hook things? You are precisely doing dynamic typing after all. (Moreover I want to change Data.Dynamic so that it says data Dynamic where Dyn :: Typeable a = a - Dynamic and you want to take advantage of this. Ah the goal is to avoid the Typeable constraint on the hooked function, and to identify what things are actually hooks. Wrapping it in a newtype also achieves the first goal and does make the design a bit simpler. No need for these strange “data DsForeignsHook = DsForeignsHook” things, or for the Hook type family. Simple! But it means that hooks are no longer recognisable by their type, they're just some Typeable (the type families approach would at least prevent users from accidentally inserting wrong hooks, even though they would still be able to make bogus instances on purpose) · The design *must* list all the hooks that GHC uses and their types. There’s no point in adding a hook that GHC doesn’t call! It appears to be difficult to define all hooks in one module or have them in one record because of dependencies and the DLL split on Windows. Re-exporting everything from a single module can be done, but would offer no guarantees about completeness. With the type families design, everything that's an instance of Hook is a hook, although the definitions are scattered throughout the GHC source. The Dynamic design would just have to rely on a consistent naming convention. Would listing the hooks in comments (in the Hooks module) and on the wiki be a reasonable way to document them? I've uploaded a new patch, using Dynamic, although I'm not sure if it's an improvement over the original one: - patch: https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-dynamic.patch - updated hooksDemo: https://gist.github.com/luite/6478973 It also adds hscParse' and tcRnModule' exports for Edsko's use case (I think that makes it somewhat more flexible than exporting another version of hscFileFrontend, since it allows users
RE: GHC 7.8 release status
I do like the single record. I would really really like a strong clear Note [blah] on the hooks::Dynamic field of DynFlags. It's *so* non-obvious why it's dynamic, and the reason is a really bad one, namely the windows DLL split nonsense. (Not our fault but still needs very clear signposting.) I don't understand why we need 4 new hs-boot files. Eg why DsMonad.hs-boot? It should be safely below Hooks. Linker.hs-boot is solely because of LibrarySpec. It would be possible to push that into HscTypes. (Again with a comment to explain why.) DriverPipeline is aleady 2,100 lines long, and could reasonably be split with CompPipeline in the PipelineMonad module, say. In other words, a bit of refactoring might eliminate the loops *and* sometimes arguably improve the code. I don't feel terribly strongly about all this. It does feel a bit ad hoc... in a variety of places (eg deep in Linker.hs) there are calls to hooks, and it's not clear to me why exactly those are the right places. But I suppose they are simply driven by what has been needed. Anyway if you two are happy (no one else seems to mind either way) then go ahead. Simon From: Luite Stegeman [mailto:stege...@gmail.com] Sent: 10 September 2013 08:37 To: Edsko de Vries Cc: Simon Peyton-Jones; ghc-devs; Edsko de Vries Subject: Re: GHC 7.8 release status Edsko has done some work of rearranging imports in DynFlags to make the DLL split work, and I've implemented the hooks on top of this, in a record, as discussed: - https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-record.patch (not final yet, but should be usable for testing) - demo program: https://gist.github.com/luite/6506064 Some disadvantages: - as long as the DLL split exists, more restructuring will be required if a new hook is added to something in a module on which DynFlags depends - 4 new hs-boot files required, new hooks will often require additional hs-boot files (when module A has a hook (so A imports Hooks, this can't be a source import), the hook will often have some types defined by A, so Hooks will have to import A) Advantages (over type families / Dynamic hooks): - Hooks neatly defined together in a single record I'm not so sure myself, but if everyone agrees that this is better than the older hooks I'll convert GHCJS to the new implementation later today and finalize the patch (comments are a bit out of date, and I'm not 100% sure yet that GHCJS doesn't need another hook for TH support in certain setups) and update the wiki. luite On Mon, Sep 9, 2013 at 4:55 PM, Edsko de Vries edskodevr...@gmail.commailto:edskodevr...@gmail.com wrote: Simon, I talked to Luite this morning and I think we can come up with a design that includes the enumeration we prefer, with a single use of Dynamic in DynFlags -- it involves splitting off a PackageState module from Packages so that DynFlags doesn't depend on the entirely of Packages anymore (which would then, transitively, mean that it depends on Hooks and hence on a large part of ghc), but I think that should be doable. I'm working on that now. Edsko On Mon, Sep 9, 2013 at 3:51 PM, Simon Peyton-Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: Edsko I'm very short of time right now. I think you understand the issues here. Can you do a round or two with Luite and emerge with a design that you both think is best? As I said earlier I'm uncomfortable with doing design work so late in the cycle, and I feel that I don't have time to study the various alternatives properly in the next four days. But since you tell me it's crucial for GHCJS, I suppose that a possible compromise is this. We release a GHC with some design for hooks, but specifically say that the hook design is evolving and may well change with the next version. And then you two, with Thomas and other interested parties, work together to evolve a design that everyone is happy with. Does that sound ok? Simon From: Luite Stegeman [mailto:stege...@gmail.commailto:stege...@gmail.com] Sent: 07 September 2013 22:04 To: Simon Peyton-Jones Cc: Thomas Schilling; Edsko de Vries; ghc-devs Subject: Re: GHC 7.8 release status * Why aren't you using Data.Dynamic for the hook things? You are precisely doing dynamic typing after all. (Moreover I want to change Data.Dynamic so that it says data Dynamic where Dyn :: Typeable a = a - Dynamic and you want to take advantage of this. Ah the goal is to avoid the Typeable constraint on the hooked function, and to identify what things are actually hooks. Wrapping it in a newtype also achieves the first goal and does make the design a bit simpler. No need for these strange data DsForeignsHook = DsForeignsHook things, or for the Hook type family. Simple! But it means that hooks are no longer recognisable by their type, they're just some Typeable (the type families approach would at least prevent users from
Re: GHC 7.8 release status
Just my 02c: I feel the GHC API is allowed to be less stable and a little more in-flux than most things. We've never particularly advertised stability here anyway, so having a design that evolves a little is reasonable, IMO. Perhaps it being in the release will help drive more feedback, earlier. I think we should at least get a full code review in, of course, and address any outstanding technical concerns (like DLL splitting.) I'll schedule this for later this week with Edsko and Luite, if nobody has objections. On Mon, Sep 9, 2013 at 9:55 AM, Edsko de Vries edskodevr...@gmail.com wrote: Simon, I talked to Luite this morning and I think we can come up with a design that includes the enumeration we prefer, with a single use of Dynamic in DynFlags -- it involves splitting off a PackageState module from Packages so that DynFlags doesn't depend on the entirely of Packages anymore (which would then, transitively, mean that it depends on Hooks and hence on a large part of ghc), but I think that should be doable. I'm working on that now. Edsko On Mon, Sep 9, 2013 at 3:51 PM, Simon Peyton-Jones simo...@microsoft.com wrote: Edsko I’m very short of time right now. I think you understand the issues here. Can you do a round or two with Luite and emerge with a design that you both think is best? As I said earlier I’m uncomfortable with doing design work so late in the cycle, and I feel that I don’t have time to study the various alternatives properly in the next four days. But since you tell me it’s crucial for GHCJS, I suppose that a possible compromise is this. We release a GHC with some design for hooks, but specifically say that the hook design is evolving and may well change with the next version. And then you two, with Thomas and other interested parties, work together to evolve a design that everyone is happy with. Does that sound ok? Simon From: Luite Stegeman [mailto:stege...@gmail.com] Sent: 07 September 2013 22:04 To: Simon Peyton-Jones Cc: Thomas Schilling; Edsko de Vries; ghc-devs Subject: Re: GHC 7.8 release status · Why aren’t you using Data.Dynamic for the hook things? You are precisely doing dynamic typing after all. (Moreover I want to change Data.Dynamic so that it says data Dynamic where Dyn :: Typeable a = a - Dynamic and you want to take advantage of this. Ah the goal is to avoid the Typeable constraint on the hooked function, and to identify what things are actually hooks. Wrapping it in a newtype also achieves the first goal and does make the design a bit simpler. No need for these strange “data DsForeignsHook = DsForeignsHook” things, or for the Hook type family. Simple! But it means that hooks are no longer recognisable by their type, they're just some Typeable (the type families approach would at least prevent users from accidentally inserting wrong hooks, even though they would still be able to make bogus instances on purpose) · The design *must* list all the hooks that GHC uses and their types. There’s no point in adding a hook that GHC doesn’t call! It appears to be difficult to define all hooks in one module or have them in one record because of dependencies and the DLL split on Windows. Re-exporting everything from a single module can be done, but would offer no guarantees about completeness. With the type families design, everything that's an instance of Hook is a hook, although the definitions are scattered throughout the GHC source. The Dynamic design would just have to rely on a consistent naming convention. Would listing the hooks in comments (in the Hooks module) and on the wiki be a reasonable way to document them? I've uploaded a new patch, using Dynamic, although I'm not sure if it's an improvement over the original one: - patch: https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-dynamic.patch - updated hooksDemo: https://gist.github.com/luite/6478973 It also adds hscParse' and tcRnModule' exports for Edsko's use case (I think that makes it somewhat more flexible than exporting another version of hscFileFrontend, since it allows users to write a hook that does something between parsing and typechecking or one that overrides one of these phases) luite ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin - PGP: 4096R/0x91384671 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: GHC 7.8 release status
Edsko I'm very short of time right now. I think you understand the issues here. Can you do a round or two with Luite and emerge with a design that you both think is best? As I said earlier I'm uncomfortable with doing design work so late in the cycle, and I feel that I don't have time to study the various alternatives properly in the next four days. But since you tell me it's crucial for GHCJS, I suppose that a possible compromise is this. We release a GHC with some design for hooks, but specifically say that the hook design is evolving and may well change with the next version. And then you two, with Thomas and other interested parties, work together to evolve a design that everyone is happy with. Does that sound ok? Simon From: Luite Stegeman [mailto:stege...@gmail.com] Sent: 07 September 2013 22:04 To: Simon Peyton-Jones Cc: Thomas Schilling; Edsko de Vries; ghc-devs Subject: Re: GHC 7.8 release status * Why aren't you using Data.Dynamic for the hook things? You are precisely doing dynamic typing after all. (Moreover I want to change Data.Dynamic so that it says data Dynamic where Dyn :: Typeable a = a - Dynamic and you want to take advantage of this. Ah the goal is to avoid the Typeable constraint on the hooked function, and to identify what things are actually hooks. Wrapping it in a newtype also achieves the first goal and does make the design a bit simpler. No need for these strange data DsForeignsHook = DsForeignsHook things, or for the Hook type family. Simple! But it means that hooks are no longer recognisable by their type, they're just some Typeable (the type families approach would at least prevent users from accidentally inserting wrong hooks, even though they would still be able to make bogus instances on purpose) * The design *must* list all the hooks that GHC uses and their types. There's no point in adding a hook that GHC doesn't call! It appears to be difficult to define all hooks in one module or have them in one record because of dependencies and the DLL split on Windows. Re-exporting everything from a single module can be done, but would offer no guarantees about completeness. With the type families design, everything that's an instance of Hook is a hook, although the definitions are scattered throughout the GHC source. The Dynamic design would just have to rely on a consistent naming convention. Would listing the hooks in comments (in the Hooks module) and on the wiki be a reasonable way to document them? I've uploaded a new patch, using Dynamic, although I'm not sure if it's an improvement over the original one: - patch: https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-dynamic.patch - updated hooksDemo: https://gist.github.com/luite/6478973 It also adds hscParse' and tcRnModule' exports for Edsko's use case (I think that makes it somewhat more flexible than exporting another version of hscFileFrontend, since it allows users to write a hook that does something between parsing and typechecking or one that overrides one of these phases) luite ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release status
· **Why aren’t you using Data.Dynamic for the hook things? You are precisely doing dynamic typing after all. (Moreover I want to change Data.Dynamic so that it says data Dynamic where Dyn :: Typeable a = a - Dynamic and you want to take advantage of this. Ah the goal is to avoid the Typeable constraint on the hooked function, and to identify what things are actually hooks. Wrapping it in a newtype also achieves the first goal and does make the design a bit simpler. No need for these strange “data DsForeignsHook = DsForeignsHook” things, or for the Hook type family. Simple! But it means that hooks are no longer recognisable by their type, they're just some Typeable (the type families approach would at least prevent users from accidentally inserting wrong hooks, even though they would still be able to make bogus instances on purpose) ** **· **The design **must** list all the hooks that GHC uses and their types. There’s no point in adding a hook that GHC doesn’t call! It appears to be difficult to define all hooks in one module or have them in one record because of dependencies and the DLL split on Windows. Re-exporting everything from a single module can be done, but would offer no guarantees about completeness. With the type families design, everything that's an instance of Hook is a hook, although the definitions are scattered throughout the GHC source. The Dynamic design would just have to rely on a consistent naming convention. Would listing the hooks in comments (in the Hooks module) and on the wiki be a reasonable way to document them? I've uploaded a new patch, using Dynamic, although I'm not sure if it's an improvement over the original one: - patch: https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks-dynamic.patch - updated hooksDemo: https://gist.github.com/luite/6478973 It also adds hscParse' and tcRnModule' exports for Edsko's use case (I think that makes it somewhat more flexible than exporting another version of hscFileFrontend, since it allows users to write a hook that does something between parsing and typechecking or one that overrides one of these phases) luite ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: GHC 7.8 release status
Maybe not, but you'll have to move fast. · Make a branch (Iavor can do that) · Update the wiki page describing the design: http://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindsWithoutData You can demote any design alternatives that you discarded, putting them in an appendix at the end. · Update documentation in the user manual · Make sure you have tests in the testsuite How fast can you do that? Simon From: Trevor Elliott [mailto:awesomelyawes...@gmail.com] Sent: 04 September 2013 18:30 To: Iavor Diatchki; Simon Peyton-Jones Subject: Re: GHC 7.8 release status Hi Simon, We had talked during your Galois visit about the changes that Iavor and I had made to -XDataKinds, allowing different syntax when introducing a new kind. Have we missed the window to make it into the 7.8 release? Thanks! --trevor On Wed, Sep 4, 2013 at 10:27 AM, Iavor Diatchki iavor.diatc...@gmail.commailto:iavor.diatc...@gmail.com wrote: -- Forwarded message -- From: Simon Peyton-Jones simo...@microsoft.commailto:simo...@microsoft.com Date: Wed, Sep 4, 2013 at 6:52 AM Subject: GHC 7.8 release status To: Nicolas Frisby nicolas.fri...@gmail.commailto:nicolas.fri...@gmail.com, Pedro Magalhães (drei...@gmail.commailto:drei...@gmail.com) drei...@gmail.commailto:drei...@gmail.com, Richard Eisenberg (e...@cis.upenn.edumailto:e...@cis.upenn.edu) e...@cis.upenn.edumailto:e...@cis.upenn.edu, Geoffrey Mainland (mainl...@cs.drexel.edumailto:mainl...@cs.drexel.edu) mainl...@cs.drexel.edumailto:mainl...@cs.drexel.edu, Iavor Diatchki iavor.diatc...@gmail.commailto:iavor.diatc...@gmail.com, Austin Seipp ase...@pobox.commailto:ase...@pobox.com, Edsko de Vries ed...@well-typed.commailto:ed...@well-typed.com, Ryan Newton (rrnew...@gmail.commailto:rrnew...@gmail.com) rrnew...@gmail.commailto:rrnew...@gmail.com, Luite Stegeman stege...@gmail.commailto:stege...@gmail.com, Thomas Schilling nomin...@googlemail.commailto:nomin...@googlemail.com, David Luposchainsky dluposchain...@googlemail.commailto:dluposchain...@googlemail.com Cc: ghc-devs@haskell.orgmailto:ghc-devs@haskell.org ghc-devs@haskell.orgmailto:ghc-devs@haskell.org Friends The 7.8 release is imminent. This email is to ask abou the status of your contributions. In each case could you update the wiki with the current state of play, and your intentions, including dates. That is, don't put your reply in email: it on the status page below; though by all means send email too! Summary here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 Also : What is missing from the list that should be done? * Patrick Palka: status of ghc -make -j? * Nick: status of your three items? * Pedro/Richard: is all the Typeable stuff, and gcast and friends, finished? * Geoff: what about the new Template Haskell story? * Iavor: when do you think you can merge? * Austin: what about ARMv7? * Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be jolly soon. At the moment I don't even know the motivation or design, let alone implementation. Could you make a wiki page explaining the proposed design? Is it really important to do this for 7.8? * Dynamic GHCi. I have no idea who is driving this, or how important it is. * Ryan: atomic stuff. All merged? * AMP warnings: David Luposchainsky is driving this. Thanks! Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC 7.8 release status
Hi Luite, Would we be able to adapt this to get generalized Template Haskell support for GHC iOS/cross compilation? Cheers Luke On Wed, Sep 4, 2013 at 6:09 PM, Luite Stegeman stege...@gmail.com wrote: I've updated the wiki page, expanding the descriptions and adding code from the actual implementation: http://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks An demo program that uses all hooks here: https://gist.github.com/luite/6444273 (I've listed the users (or proposers) of every hook, and how they use it, Thomas / Edsko, can you check that they indeed do what you need?) The patch is here: https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks.patch In addition to defining the heterogeneous map and the hooks themselves, extra exports have been added to make it possible for users to actually make a hook implementation without copying most of the module's source code. The demo program implements all hooks to check this. Also the GHCJS patch is here: https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch It adds the following: - in DynFlags an extra WayCustom constructor to add a custom 'tag' to generated files (GHCJS builds multiple architectures to support Template Haskell among other things, one with the 'js' tag) - in ForeignCall the JavaScriptCallConv calling convention - in Platform an ArchJavaScript architecture - `foreign import javascript' support in the parser and lexer - The JavaScriptFFI extension that enables the `foreign import javascript' syntax, only supported on ArchJavaScript (So using it on a regular GHC would always result in a compile error saying that it's unsupported on the user's platform) luite On Thu, Sep 5, 2013 at 12:17 AM, Thomas Schilling nomin...@googlemail.com wrote: I started a wiki page at: http://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks Luite: could you please fill in the hooks that your latest patch defines? On 4 Sep 2013, at 19:40, Simon Peyton-Jones simo...@microsoft.com wrote: I do need more than a patch, please, please. A wiki page explaining the design, as seen by the user (of the GHC API), the problems it solves, and the use-cases it enables, would be most helpful. Simon | -Original Message- | From: Thomas Schilling [mailto:nomin...@googlemail.com] | Sent: 04 September 2013 17:26 | To: Simon Peyton-Jones; Luite Stegeman | Cc: Nicolas Frisby; Pedro Magalhães (drei...@gmail.com); Richard | Eisenberg (e...@cis.upenn.edu); Geoffrey Mainland | (mainl...@cs.drexel.edu); Iavor Diatchki; Austin Seipp; Edsko de Vries; | Ryan Newton (rrnew...@gmail.com); David Luposchainsky; ghc- | d...@haskell.org | Subject: Re: GHC 7.8 release status | | | On 4 Sep 2013, at 15:52, Simon Peyton-Jones simo...@microsoft.com | wrote: | | Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be | jolly soon. At the moment I don't even know the motivation or design, | let alone implementation. Could you make a wiki page explaining the | proposed design? Is it really important to do this for 7.8? | | Yes, it is quite important to get this into 7.8. Not having these | features in GHC makes it very difficult for people to adopt GHCJS. One | could argue that GHCJS is not yet production-ready anyway and users that | want to try it can figure out building GHC from source to use it, but | this doesn't quite apply. | | 1. GHCJS targets a wider audience than users brave enough to compile | GHC from source. In addition, the next chance to get these features into | GHC is in a year from now, so when GHCJS becomes more mature then this | will be a major hurdle for adoption. | | 2. These changes are also required for IDE tools which really mustn't | require users to build a custom version of GHC. | | | Luite's design is actually very flexible. It simply allows GHC API | users to provide functions that are called instead of (or in addition | to) existing functions in GHC. Instead of calling, say, genHardCode, | the driver now looks up whether the user has specified a hook for | genHardCode and calls that instead. | | Currently we only specify a small number of hooks that are sufficient | for our use cases. Future releases of GHC can be extended to include | more hooks, if that is needed. | | Hooks are stored as an untyped map inside the DynFlags (to avoid issues | with circular dependencies). Each hook is looked up using a single- | constructor type and type families are used to make this type safe. | There is one use of unsafeCoerce to avoid having to make every hook | function an instance of Typeable. | | Unlike CorePlugins, it is only a GHC API feature, and users cannot | specify plugins to be added via command line options. If we can come up | with a good design, then we could add this in GHC 7.10, but it is not | necessary at this point. | | Luite: Do you have
