Hi Eric, On Wed, Jan 29, 2014 at 3:20 AM, Erik de Castro Lopo <mle...@mega-nerd.com> wrote: > Mathieu Boespflug wrote: > >> thank you for the good points you raise. I'll try and address each of >> them as best I can below. >> >> > 0) I think you could actually implement this proposal as a userland >> > library, >> > at least as you've described it. Have you tried doing so? >> >> Indeed, this could be done without touching the compiler at all. > > We had this response really early on in this discussion. > > Quite honestly I think that should have been the end of the discussion.
The response you quote above comes in context, which includes the sentence you also quote below. In another email, the problems we face with a pure TH implementation are labeled as 1a), 1b), 2). We'd be very happy if you could show us how to solve those problems using TH alone in a way that does not impact user friendliness and static checking of invariants in any way. > The existing GHC release already have a huge workload getting releases > out the door and adding to that workload without adding manpower and > resources would be a bad idea. > > You really should try doing this as a library outside of GHC and if GHC > needs a few small additional features, they can be added. > >> The `static e` form could as well be a piece of Template Haskell, but >> making it a proper extension means that the compiler can enforce more >> invariants and be a bit more helpful to the user. > > Once it works outside GHC and has proven useful, then it might be worthwhile > add small specific, easily testable/maintainable features to GHC to support > what goes on on your library. I for one very much agree with all the principles state above. But the wider context of the discussion is that we already have such a TH userland solution today, implemented in packages distributed-static and distributed-process. We already have several users, including in the industry (to my knowledge Parallel Scientific for over a year, Tweag I/O for a couple of months, probably others...). The proposal to go ahead and implement an idea that was first presented in the original Cloud Haskell paper was borne out of frustration with the existing approach based on remote tables, which are very error prone in practice, and the operational experience that I, Facundo, Tim and others have had showing that making the semantics of distributed computation depend on *all* modules across several packages being compiled with the right incantation of compiler flags without any kind of static checking is a problem, especially for beginners. Is there something in the proposed extension that leads you to believe that is neither small nor specific, or that it would not be easily testable, or maintainable? If so, we could amend it accordingly. Best, Mathieu _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
