Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
On 21/05/15 19:07, Herbert Valerio Riedel wrote: Don't you still have to support -pgmF? I guess so, unfortunately... so we'd have to keep a legacy code-path for external cpp processing around, at least in the short run... It's not just about legacy; -pgmF is used for all sorts of awesome things; literate markdown is one example. Roman signature.asc Description: OpenPGP digital signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
Hi Yitzchak, On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote: [...] Bardur Arantsson wrote: I don't see any need for an option. Just bundle cpphs together with GHC and build/use it as an external program. AFAICT this has absolutely no licensing implications for GHC, derived from GHC or anything compiled with GHC. Agreed, that would work. But I thought that the idea was that we wanted it actually integrated into GHC. That would be the preferred way from a technical standpoint, as it would avoid fork/exec and make it easier to integrate the CPP-phase tighter into the lexer/parser. However, due to the, sadly, mostly non-technical issues brought up, it seems to me that isolating cpphs into a separate process (w/ the option to configure GHC to use some other cpp implementation at your own risk if you need to avoid the cpphs implementation at all costs) would be the compromise acceptable to everyone in the short run while addressing the primary goal to decouple the default-configuration of GHC from the fragile system-cpp semantics. NB: Nothing's been decided yet by GHC HQ PS: As an observation, http://packdeps.haskellers.com/reverse/cpphs shows that cpphs is already used by popular packages like hlint and haskell-src-exts (and thus an indirect build-dep of the haskell-suite project). Therefore, if LGPL+SLE is unacceptable in some work-environments, it may require some vigilance to keep track where cpphs may sneak into as a build-dependency... I'm surprised there's still such resistance given the ubiquity of Linux distributions made up of numerous (L)GPLed components, IMHO it's kinda like tilting at windmills... Cheers, hvr ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
On 05/21/2015 12:31 PM, Herbert Valerio Riedel wrote: Hi Yitzchak, On 2015-05-21 at 11:25:46 +0200, Yitzchak Gale wrote: [...] Bardur Arantsson wrote: I don't see any need for an option. Just bundle cpphs together with GHC and build/use it as an external program. AFAICT this has absolutely no licensing implications for GHC, derived from GHC or anything compiled with GHC. Agreed, that would work. But I thought that the idea was that we wanted it actually integrated into GHC. That would be the preferred way from a technical standpoint, as it would avoid fork/exec and make it easier to integrate the CPP-phase tighter into the lexer/parser. fork/exec is almost certainly going to be negligable compared to the overall compile time anyway. It's not like GHC is fast enough for it to matter. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Performance isn't (my) motivation for avoiding fork/exec (and the equivalent on Win32) but rather avoiding the added complexity of marshalling/IPC with fork/exec, as opposed to simply calling into a native Haskell function and crossing process boundaries and having to deal with the various things that can go wrong with the additional moving parts you encounter when controlling an external process. So this would IMO simplify code paths, and moreover I'd expect opportunities to actually make the Haskell cpphs API richer (in case it isn't already) and more tailored to GHC's lexer/parser pipeline and error-reporting. Don't you still have to support -pgmF? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
On 2015-05-21 at 18:02:57 +0200, Brandon Allbery wrote: On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel hvrie...@gmail.com wrote: Performance isn't (my) motivation for avoiding fork/exec (and the equivalent on Win32) but rather avoiding the added complexity of marshalling/IPC with fork/exec, as opposed to simply calling into a native Haskell function and crossing process boundaries and having to deal with the various things that can go wrong with the additional moving parts you encounter when controlling an external process. So this would IMO simplify code paths, and moreover I'd expect opportunities to actually make the Haskell cpphs API richer (in case it isn't already) and more tailored to GHC's lexer/parser pipeline and error-reporting. Don't you still have to support -pgmF? I guess so, unfortunately... so we'd have to keep a legacy code-path for external cpp processing around, at least in the short run... ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
On 2015-05-21 at 16:54:11 +0200, Bardur Arantsson wrote: [...] That would be the preferred way from a technical standpoint, as it would avoid fork/exec and make it easier to integrate the CPP-phase tighter into the lexer/parser. fork/exec is almost certainly going to be negligable compared to the overall compile time anyway. It's not like GHC is fast enough for it to matter. Performance isn't (my) motivation for avoiding fork/exec (and the equivalent on Win32) but rather avoiding the added complexity of marshalling/IPC with fork/exec, as opposed to simply calling into a native Haskell function and crossing process boundaries and having to deal with the various things that can go wrong with the additional moving parts you encounter when controlling an external process. So this would IMO simplify code paths, and moreover I'd expect opportunities to actually make the Haskell cpphs API richer (in case it isn't already) and more tailored to GHC's lexer/parser pipeline and error-reporting. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
The license issue is a real concern for any company using GHC to develop a product whose binaries they distribute to customers. And it is concern for GHC itself, if we want GHC to continue to be viewed as a candidate for use in industry. The real issue is not whether you can explain why this license is OK, or whether anyone is actually going to the trouble of building GHC without GMP. The issue is the risk of a *potential* legal issue and its potential disastrous cost as *perceived* by lawyers and management. A potential future engineering cost, no matter how large and even if only marginally practical, is perceived as manageable and controllable, whereas a poorly understood potential future legal threat is perceived as an existential risk to the entire company. With GMP, we do have an engineering workaround to side-step the legal problem entirely if needed. Whereas if cpphs were to be linked into GHC with its current license, I would be ethically obligated to report it to my superiors, and the response might very well be: Then never mind, let's do the simple and safe thing and just rewrite all of our applications in Java or C#. Keeping the license as is seems to be important to Malcolm. So could we have an option to build GHC without cpphs and instead use it as a stand-alone external program? That would make the situation no worse than GMP. Thanks, Yitz ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
On 05/20/2015 03:39 PM, Yitzchak Gale wrote: [--snip--] Keeping the license as is seems to be important to Malcolm. So could we have an option to build GHC without cpphs and instead use it as a stand-alone external program? That would make the situation no worse than GMP. I don't see any need for an option. Just bundle cpphs together with GHC and build/use it as an external program. AFAICT this has absolutely no licensing implications for GHC, derived from GHC or anything compiled with GHC. Regards, ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
Yes, this is what I am asking. Is the LGPL so dangerous to your business, that you have taken the steps necessary to build a special GHC using integer-simple instead of integer-gmp? Or are the lawyers happy simply for the option to be available, but unexercised? (If the latter, then I could suggest that ghc using cpphs by default, but allowing the option of a different preprocessor, might suffice?) Regards, Malcolm On 19 May, 2015,at 02:51 PM, Niklas Larsson metanik...@gmail.com wrote: Hi! GMP is optional, anyone who cares about the license can build with integer-simple. Regards, Niklas Från: malcolm.wallace Skickat: 2015-05-19 13:11 Till: Lars Kuhtz Kopia: ghc-devs@haskell.org Ämne: Re: [Haskell-cafe] RFC: Native -XCPP Proposal How does your company deal with the Integer type, whose standard implementation in ghc is via the LGPL'd Gnu multi-precision routines? Regards, Malcolm On 18 May, 2015,at 09:19 PM, Lars Kuhtz hask...@kuhtz.eu wrote: I work for PivotCloud. We use Haskell/GHC in our production system on the server side and on the client side. My experience is that any license that contains the string GPL can cause problems in an corporate context, no matter if it actually is a legal issue or not. Folks who are responsible for making decisions about legal implications of the usage of third party software don't always have experience with open source software. Also they are often not familiar with the technical details of derived work, different types of linking, or the subtleties of distinguishing between build-, link-, and run-time dependencies in modern software engineering pipelines. So, any mentioning of LGPL (or similar) potentially causes overhead in the adaption. Regards, Lars On 5/7/15 11:10 PM, Malcolm Wallace wrote: Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace malcolm.wall...@me.com wrote: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: If that's a problem for you, contact me to make other arrangements. Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
I'm unclear why cpphs needs to be made a dependency of the GHC API and included as a lib. Could you elaborate? (in the wiki page possibly) Currently, GHC uses the system preprocessor, as a separate process. Couldn't we for GHC 7.12 keep to exactly that, save for the fact that by default GHC would call the cpphs binary for preprocessing, and have the cpphs binary be available in GHC's install dir somewhere? fork()/execvce() is cheap. Certainly cheaper than the cost of compiling a single Haskell module. Can't we keep to this separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep most license tainting concerns that way. On 8 May 2015 at 11:39, Herbert Valerio Riedel hvrie...@gmail.com wrote: Hello, On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: 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. Yes, every program linking the `ghc` package would be affected by LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page: | - As a practical consequence of the //LGPL with static-linking-exception// | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts** | (i.e. the LGPL+SLE covered modules) of the GHC code-base, | **then there is no requirement to ship (or make available) any source code** | together with the binaries, even if other parts of the GHC code-base | were modified. However, don't forget we already have this issue w/ integer-gmp, and with that the LGPL is in full effect (i.e. w/o a static-linkage-exception!) In that context, the suggestion was made[1] to handle the cpphs-code like the GMP code, i.e. allow a compile-time configuration in the GHC build-system to build a cpphs-free (and/or GMP-free) GHC for those parties that need to avoid any LGPL-ish code whatsoever in their toolchain. Would that address this concern? [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SV: [Haskell-cafe] RFC: Native -XCPP Proposal
Hello, On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: 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. Yes, every program linking the `ghc` package would be affected by LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page: | - As a practical consequence of the //LGPL with static-linking-exception// | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts** | (i.e. the LGPL+SLE covered modules) of the GHC code-base, | **then there is no requirement to ship (or make available) any source code** | together with the binaries, even if other parts of the GHC code-base | were modified. However, don't forget we already have this issue w/ integer-gmp, and with that the LGPL is in full effect (i.e. w/o a static-linkage-exception!) In that context, the suggestion was made[1] to handle the cpphs-code like the GMP code, i.e. allow a compile-time configuration in the GHC build-system to build a cpphs-free (and/or GMP-free) GHC for those parties that need to avoid any LGPL-ish code whatsoever in their toolchain. Would that address this concern? [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
