[Haskell-cafe] RFC: "Native -XCPP" Proposal

[Niklas Larsson]

If the intention is to use cpphs as a library, won't the license affect every program built with the GHC API? That seems to be a high price to pay.


----- Ursprungligt meddelande -----
Från: "Herbert Valerio Riedel" <hvriedel at gmail.com>
Skickat: ‎2015-‎05-‎08 11:02
Till: "Christian Maeder" <c.maeder at jacobs-university.de>
Kopia: "Malcolm Wallace" <Malcolm.Wallace at cs.york.ac.uk>; "glasgow-haskell-users at haskell.org" <glasgow-haskell-users at haskell.org>; "libraries at haskell.org" <libraries at haskell.org>; "ghc-devs at haskell.org" <ghc-devs at haskell.org>; "haskell-cafe" <haskell-cafe at haskell.org>
Ämne: Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal

Hello Christian,

(I've re-CC'ed haskell-cafe, assuming this wasn't deliberate)

On 2015-05-08 at 09:50:46 +0200, Christian Maeder wrote:
> using cpphs is the right way to go!
>
> Rewriting it from scratch may be a good exercise but is (essentially) a
> waste of time.
>
> However, always asking Malcolm to get source changes into cpphs would
> be annoying.
>
> Therefore it would be great if the sources were just part of the ghc
> sources (under git).
>
> Another "problem" might be the dependency "polyparse" that is currently
> not part of the core libraries.

A scheme was actually discussed privately to address this:

We certainly don't want to expose cpphs/polyparse (and text!) as new
packages in GHC's global pkg-db. Which we'd end up, if we handled cpphs
as the other exposed boot libraries.

Therefore we'd only use the few relevant modules from cpphs/polyparse as
"other-modules" (i.e. internal hidden dependencies -- i.e. we wouldn't
use cpphs/polyparse's .cabal files) compiled into GHC, but not
exposed. We'd either create a new Git submodule to hold our "fork" of
cpphs/polyparse, or just add it somewhere inside ghc.git

> (I guess that replacing polyparse by something else would also be a nice
> exercise.)
>
> So (for me) the only question is, if Malcolm is willing to transfer
> control over cpphs to the haskell-community (or ghc head) - of course
> with due acknowledgements!

I don't think this will be necessary, as we don't need the
cpphs-upstream to mirror each modifications immediately. The benefit of
the scheme described above is that we'd be somewhat decoupled from cpphs'
upstream, and can freely experiment in our "fork", and can sync up with
Malcolm from time to time to merge improvements in both directions.

-- hvr
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150508/64308d80/attachment.html>