Re: [Haskell-cafe] RFC: Native -XCPP Proposal
Based on two different occasions with two different companies (one related to an acquisition and one to an OEM agreement), my experience is exactly as laid out by Lars. A LGPL license will raise concerns by the legal team and it will delay the process because it comes with a certain level of risk that they may or may not want to take. And good luck trying to find a precise reason why LGPL is fine or it isn't in all cases: the reality is a bit more complicated and with a few more shades of grey. Having said that, in both occasions, the LGPL dependencies were, ultimately, not an impediment to continuing negotiations. They were definitely a friction, though. On Wed, May 27, 2015 at 5:41 PM, Lars Kuhtz hask...@kuhtz.eu wrote: The issue that GMP is LGPL licensed came up a couple of times in discussions at PivotCloud. Before each product release developers were requested to provided a list of all third party dependencies along with their licenses. This was given to the folks who deal with the legal stuff. If they spoted anything with (L)GPL in it, they had general concerns. Also someone also had heard some rumors on the web about issues with GMP and GHC (like for instance this thread in the mailing list archives :-) ) adding to the uncertainty. Some time back I was even asked to build GHC without GMP, which, at least at that time, wasn’t fun to do; though we never used that build. As a more general and not directly related remark: when I was working at Microsoft there were rules how to deal with open source software based on the style of the license. At least in my group anything with (L)GPL was simply a no-go without any further discussion about details. From this experience I think that if we want to make adaption of Haskell easy we may avoid (L)GPL when possible. If we can’t avoid it, well, probably it wouldn’t be a disaster neither. On May 27, 2015, at 2:00 PM, Carter Schonwald carter.schonw...@gmail.com wrote: could you be concrete about the specific challenges and experiences you've had, and with what organizations? Its very hard to evaluate the veracity of what youre saying otherwise! was using GCC an issue at this organization too? because that would be a real problem! 'cause tis GPLV3 rather than LGPL! :) On Wed, May 27, 2015 at 4:21 PM, Lars Kuhtz hask...@kuhtz.eu wrote: Carter, your explanation why the usage of LGPL is perfectly fine in most scenarios involves technical as well as legal details. My point is, that it is not a technical, probably not even a legal issue. I completely agree with you that it is a business problem. But it makes adaptation of GHC in a business more difficult if it creates business problems. Decisions are made most efficiently when there are rules of thumb. Such a rule is that BSD or MIT style licenses are not problematic. But if a GPL style license shows up some special treatment is needed. And a solution requires a detailed communication between two groups of persons who usually don't deal directly with each other and speak very different languages. This problem can be solved, and we actually solved it, and we use GHC. But it is annoying and it tends to come up again regularly. For a small company which considers adopting Haskell it would be best if that decision was a purely technical decision. With LGPL style libraries in the mix it isn’t a purely technical decision any more. Lars On May 27, 2015, at 12:11 PM, Carter Schonwald carter.schonw...@gmail.com wrote: Lars, which users have an issue? could you please be concrete? Because I frankly think you are being a bit vague. gmp on linux platforms is dynamically linked, so it has absolutely zero implications there. For those wanting to deploy a proprietary appplication on windows or OSX, they merely need to either a) bundle the dylib with the application and suitable install scripting to adjust the load paths. (or build the integer simple version of GHC and navigate choosing dependencies that depend on integer-gmp specifically being installed ) any other problems with industrial usage and libgmp are artifacts of dealing with business or legal staff that have not been educated about how intellectual property law works. Which is business problem rather than a haskell problem. On Wed, May 27, 2015 at 1:12 PM, Lars Kuhtz hask...@kuhtz.eu wrote: 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... I think it’s unfortunate if industrial usage of GHC is supported only through legacy code-paths. I think non-technical arguments do matter here. It is about explanations. Convincing a company to use Haskell can be already quite a challenge. Additional legal issues don’t make that easier. The gmp dependency is causing already enough trouble for industrial users. Let’s
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
Hi Lars, I'm really not sure that the community has the resources to spare to reimplement non-trivial pieces of *standalone (non-library)* software to address perceived but ethereal business problems that are based on lack of understanding about how IP law works as both you and Carter point out. Especially if there are no strong technical reasons to shun the existing implementation, which is perfectly good quality. Does the above cited compromise... 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. ... sound fair to you? Best, Mathieu On 27 May 2015 at 22:21, Lars Kuhtz hask...@kuhtz.eu wrote: Carter, your explanation why the usage of LGPL is perfectly fine in most scenarios involves technical as well as legal details. My point is, that it is not a technical, probably not even a legal issue. I completely agree with you that it is a business problem. But it makes adaptation of GHC in a business more difficult if it creates business problems. Decisions are made most efficiently when there are rules of thumb. Such a rule is that BSD or MIT style licenses are not problematic. But if a GPL style license shows up some special treatment is needed. And a solution requires a detailed communication between two groups of persons who usually don't deal directly with each other and speak very different languages. This problem can be solved, and we actually solved it, and we use GHC. But it is annoying and it tends to come up again regularly. For a small company which considers adopting Haskell it would be best if that decision was a purely technical decision. With LGPL style libraries in the mix it isn’t a purely technical decision any more. Lars On May 27, 2015, at 12:11 PM, Carter Schonwald carter.schonw...@gmail.com wrote: Lars, which users have an issue? could you please be concrete? Because I frankly think you are being a bit vague. gmp on linux platforms is dynamically linked, so it has absolutely zero implications there. For those wanting to deploy a proprietary appplication on windows or OSX, they merely need to either a) bundle the dylib with the application and suitable install scripting to adjust the load paths. (or build the integer simple version of GHC and navigate choosing dependencies that depend on integer-gmp specifically being installed ) any other problems with industrial usage and libgmp are artifacts of dealing with business or legal staff that have not been educated about how intellectual property law works. Which is business problem rather than a haskell problem. On Wed, May 27, 2015 at 1:12 PM, Lars Kuhtz hask...@kuhtz.eu wrote: 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... I think it’s unfortunate if industrial usage of GHC is supported only through legacy code-paths. I think non-technical arguments do matter here. It is about explanations. Convincing a company to use Haskell can be already quite a challenge. Additional legal issues don’t make that easier. The gmp dependency is causing already enough trouble for industrial users. Let’s not just add another licensing issue. Lars ___ 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: [Haskell-cafe] RFC: Native -XCPP Proposal
Lars, which users have an issue? could you please be concrete? Because I frankly think you are being a bit vague. gmp on linux platforms is dynamically linked, so it has absolutely zero implications there. For those wanting to deploy a proprietary appplication on windows or OSX, they merely need to either a) bundle the dylib with the application and suitable install scripting to adjust the load paths. (or build the integer simple version of GHC and navigate choosing dependencies that depend on integer-gmp specifically being installed ) any other problems with industrial usage and libgmp are artifacts of dealing with business or legal staff that have not been educated about how intellectual property law works. Which is business problem rather than a haskell problem. On Wed, May 27, 2015 at 1:12 PM, Lars Kuhtz hask...@kuhtz.eu wrote: 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... I think it’s unfortunate if industrial usage of GHC is supported only through legacy code-paths. I think non-technical arguments do matter here. It is about explanations. Convincing a company to use Haskell can be already quite a challenge. Additional legal issues don’t make that easier. The gmp dependency is causing already enough trouble for industrial users. Let’s not just add another licensing issue. Lars ___ 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: [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... I think it’s unfortunate if industrial usage of GHC is supported only through legacy code-paths. I think non-technical arguments do matter here. It is about explanations. Convincing a company to use Haskell can be already quite a challenge. Additional legal issues don’t make that easier. The gmp dependency is causing already enough trouble for industrial users. Let’s not just add another licensing issue. Lars ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
The issue that GMP is LGPL licensed came up a couple of times in discussions at PivotCloud. Before each product release developers were requested to provided a list of all third party dependencies along with their licenses. This was given to the folks who deal with the legal stuff. If they spoted anything with (L)GPL in it, they had general concerns. Also someone also had heard some rumors on the web about issues with GMP and GHC (like for instance this thread in the mailing list archives :-) ) adding to the uncertainty. Some time back I was even asked to build GHC without GMP, which, at least at that time, wasn’t fun to do; though we never used that build. As a more general and not directly related remark: when I was working at Microsoft there were rules how to deal with open source software based on the style of the license. At least in my group anything with (L)GPL was simply a no-go without any further discussion about details. From this experience I think that if we want to make adaption of Haskell easy we may avoid (L)GPL when possible. If we can’t avoid it, well, probably it wouldn’t be a disaster neither. On May 27, 2015, at 2:00 PM, Carter Schonwald carter.schonw...@gmail.com wrote: could you be concrete about the specific challenges and experiences you've had, and with what organizations? Its very hard to evaluate the veracity of what youre saying otherwise! was using GCC an issue at this organization too? because that would be a real problem! 'cause tis GPLV3 rather than LGPL! :) On Wed, May 27, 2015 at 4:21 PM, Lars Kuhtz hask...@kuhtz.eu mailto:hask...@kuhtz.eu wrote: Carter, your explanation why the usage of LGPL is perfectly fine in most scenarios involves technical as well as legal details. My point is, that it is not a technical, probably not even a legal issue. I completely agree with you that it is a business problem. But it makes adaptation of GHC in a business more difficult if it creates business problems. Decisions are made most efficiently when there are rules of thumb. Such a rule is that BSD or MIT style licenses are not problematic. But if a GPL style license shows up some special treatment is needed. And a solution requires a detailed communication between two groups of persons who usually don't deal directly with each other and speak very different languages. This problem can be solved, and we actually solved it, and we use GHC. But it is annoying and it tends to come up again regularly. For a small company which considers adopting Haskell it would be best if that decision was a purely technical decision. With LGPL style libraries in the mix it isn’t a purely technical decision any more. Lars On May 27, 2015, at 12:11 PM, Carter Schonwald carter.schonw...@gmail.com mailto:carter.schonw...@gmail.com wrote: Lars, which users have an issue? could you please be concrete? Because I frankly think you are being a bit vague. gmp on linux platforms is dynamically linked, so it has absolutely zero implications there. For those wanting to deploy a proprietary appplication on windows or OSX, they merely need to either a) bundle the dylib with the application and suitable install scripting to adjust the load paths. (or build the integer simple version of GHC and navigate choosing dependencies that depend on integer-gmp specifically being installed ) any other problems with industrial usage and libgmp are artifacts of dealing with business or legal staff that have not been educated about how intellectual property law works. Which is business problem rather than a haskell problem. On Wed, May 27, 2015 at 1:12 PM, Lars Kuhtz hask...@kuhtz.eu mailto:hask...@kuhtz.eu wrote: 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... I think it’s unfortunate if industrial usage of GHC is supported only through legacy code-paths. I think non-technical arguments do matter here. It is about explanations. Convincing a company to use Haskell can be already quite a challenge. Additional legal issues don’t make that easier. The gmp dependency is causing already enough trouble for industrial users. Let’s not just add another licensing issue. Lars ___ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 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: [Haskell-cafe] RFC: Native -XCPP Proposal
On 24 May 2015, at 14:15, Roman Cheplyaka wrote: 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. I think Herbert meant that -pgmP will also need to continue to be supported. Regards Malcolm ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
Interesting. I'm not completely clear, when you say that your company distributes binaries to third-parties: do you distribute ghc itself? Or just the product that has been built by ghc? Regards, Malcolm On 21 May 2015, at 10:16, Yitzchak Gale wrote: LGPL is well-known and non-acceptable here. Show me some serious case law for Malcolm's customized LGPL and we can start talking. Other than that, explanations are not going to be helpful. Thanks, Yitz On Thu, May 21, 2015 at 4:51 AM, Howard B. Golden howard_b_gol...@yahoo.com wrote: Hi Yitzchak, I believe there are good explanations of open source licenses aimed at lawyers and management. I don't think their fears are well-founded. If you work for a timid company that isn't willing to learn, you should consider going elsewhere. You may be happier in the long run. Respectfully, Howard On May 20, 2015, at 7:39 AM, Yitzchak Gale g...@sefer.org wrote: 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
On 21 May 2015, at 15:54, Bardur Arantsson wrote: 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. Don't count on it. On our Windows desktop machines, fork/exec costs approximately one third of a second, instead of the expected small number of milliseconds or less. The reasons are unknown, but we suspect a misconfigured anti-virus scanner (and for various company policy reasons we are prohibited from doing the investigation that could confirm or deny this hypothesis). This means that when ghc --make does lots of external things requiring a fork, such as preprocessing, a medium sized project (using many library packages) can take a surprisingly large amount of time (minutes instead of seconds), even for an incremental build where very little code has changed. We think an in-process cpphs could make some of our compilations literally hundreds of times faster. Regards, Malcolm ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
On 05/21/2015 05:36 PM, Malcolm Wallace wrote: On 21 May 2015, at 15:54, Bardur Arantsson wrote: 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. Don't count on it. On our Windows desktop machines, fork/exec costs approximately one third of a second, instead of the expected small number of milliseconds or less. The reasons are unknown, but we suspect a misconfigured anti-virus scanner (and for various company policy reasons we are prohibited from doing the investigation that could confirm or deny this hypothesis). Yeah, that sounds... broken. Regards, ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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: [Haskell-cafe] RFC: Native -XCPP Proposal
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
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
Hi Wren, Incidentally, if we really want to pursue the get rid of CPP by building it into the GHC distro... In recent years there've been a number of papers on variational lambda-calculi[1] which essentially serve to embed flag-based preprocessor conditionals directly into the language itself. One major benefit of this approach is that the compiler can then typecheck *all* variations of the code, rather than only checking whichever particular variation we happen to be compiling at the time. This is extremely useful for avoiding bitrot in the preprocessor conditionals. ...If we were to try and obviate the dependency on CPP, variational typing seems like a far more solid approach than simply reinventing the preprocessing wheel yet again. (The downside, of course, is making the Haskell spec significantly more complex.) I think even more beneficial than type checking all cases is the easier support for any Haskell tooling operating with the Haskell source if all cases are part of the AST. Greetings, Daniel ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
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
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
On 8 May 2015, at 00:06, Richard A. O'Keefe wrote: I think it's important that there be *one* cpp used by Haskell. fpp is under 4 kSLOC of C, and surely Haskell can do a lot better. FWIW, cpphs is about 1600 LoC today. Regards, Malcolm ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
Hi, 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. (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! Cheers Christian On 08.05.2015 08:07, Malcolm Wallace wrote: On 8 May 2015, at 00:06, Richard A. O'Keefe wrote: I think it's important that there be *one* cpp used by Haskell. fpp is under 4 kSLOC of C, and surely Haskell can do a lot better. FWIW, cpphs is about 1600 LoC today. Regards, Malcolm ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
[Gah, wrong From: email address given the list subscriptions, sorry for the duplicates.] 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 ___ 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
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
2015-05-06 16:21 GMT+02:00 Bardur Arantsson s...@scientician.net: +1, I'll wager that the vast majority of usages are just for version range checks. The OpenGL-related packages used macros to generate some binding magic (a foreign import plus some helper functions for each API entry), not just range checks. I had serious trouble when Apple switched to clang, so as a quick fix, the macro-expanded (via GCC's CPP) sources had been checked in. :-P Nowadays the binding is generated from the OpenGL XML registry file, so this is not an issue anymore. If there are packages that require more, they could just keep using the system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd want to see real evidence that that's actually worth the effort/complication. Simply relying on the system CPP doesn't work due to the various differences between GCC's CPP and the one from clang, see e.g. https://github.com/haskell-opengl/OpenGLRaw/issues/18#issuecomment-31428380. Ignoring the problem doesn't make it go away... ;-) Note that we still need CPP to handle the various calling conventions on the different platforms when the FFI is used, so it's not only range checks, see e.g. https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L588. ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
Sven Panne svenpa...@gmail.com writes: 2015-05-06 16:21 GMT+02:00 Bardur Arantsson s...@scientician.net: +1, I'll wager that the vast majority of usages are just for version range checks. The OpenGL-related packages used macros to generate some binding magic (a foreign import plus some helper functions for each API entry), not just range checks. So, metaprogramming. The question that comes to mind -- why suffer such a lousy tool as cpp for metaprogramming? Why *shouldn't* TH fill that role? What can be done about it? -- regards, Косырев Серёга ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] RFC: Native -XCPP Proposal
On Wed, May 6, 2015 at 11:27 AM, Kosyrev Serge _deepf...@feelingofgreen.ru wrote: Why *shouldn't* TH fill that role? What can be done about it? For one, it's difficult to make it available in cross compilers (granted, work is being done on this) and not available on some platforms (ARM has been a problem, dunno if it currently is). For another, I don't think you can currently control things like imports or LANGUAGE pragmas --- and as TH is currently constructed it's not clear that you could do so, or that you could do so in a way that is sane for users. This is not to say that I like cpp --- I'd like it a lot more if it weren't actually using a C preprocessor that is not actually under our control or guaranteed to be compatible with Haskell --- but it does provide a meta in a different dimension than TH does. -- 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: [Haskell-cafe] RFC: Native -XCPP Proposal
On 06-05-2015 16:32, Sven Panne wrote: 2015-05-06 16:21 GMT+02:00 Bardur Arantsson s...@scientician.net: +1, I'll wager that the vast majority of usages are just for version range checks. The OpenGL-related packages used macros to generate some binding magic (a foreign import plus some helper functions for each API entry), not just range checks. I had serious trouble when Apple switched to clang, so as a quick fix, the macro-expanded (via GCC's CPP) sources had been checked in. :-P Nowadays the binding is generated from the OpenGL XML registry file, so this is not an issue anymore. Ok, so it's *not* a counterexample :). If there are packages that require more, they could just keep using the system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd want to see real evidence that that's actually worth the effort/complication. Simply relying on the system CPP doesn't work due to the various differences between GCC's CPP and the one from clang, see e.g. https://github.com/haskell-opengl/OpenGLRaw/issues/18#issuecomment-31428380. Ignoring the problem doesn't make it go away... ;-) No, but is it worth the effort? (As opposed to workarounds, such as just checking in the preprocessed file as you provided an example of.) Note that we still need CPP to handle the various calling conventions on the different platforms when the FFI is used, so it's not only range checks, see e.g. https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L588. Certainly. I'm not saying *everybody* just does range checks, but I'm guessing that it's the majority of CPP users are using it just for that. (I'm not going to be doing any of the work, so this is just armchairing, but this seems like an 80/20 solution would be warranted.) Regards, ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
