RFC: "Native -XCPP" Proposal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RFC: "Native -XCPP" Proposal

Herbert Valerio Riedel-3
Hello *,

As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
currently relies on the system's C-compiler bundled `cpp` program to
provide a "traditional mode" c-preprocessor.

This has caused several problems in the past, since parsing Haskell code
with a preprocessor mode designed for use with C's tokenizer has caused
already quite some problems[1] in the past. I'd like to see GHC 7.12
adopt an implemntation of `-XCPP` that does not rely on the shaky
system-`cpp` foundation. To this end I've created a wiki page

  https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp

to describe the actual problems in more detail, and a couple of possible
ways forward. Ideally, we'd simply integrate `cpphs` into GHC
(i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be
discussed and debated since affects the overall-license of the GHC
code-base, which may or may not be a problem to GHC's user-base (and
that's what I hope this discussion will help to find out).

So please go ahead and read the Wiki page... and then speak your mind!


Thanks,
  HVR


[1]: ...does anybody remember the issues Haskell packages (& GHC)
     encountered when Apple switched to the Clang tool-chain, thereby
     causing code using `-XCPP` to suddenly break due to subtly
     different `cpp`-semantics?

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Jan Stolarek
One thing to keep in mind is that while cpphs will solve some problems of system-cpp, it will also
bring problems of its own. I, for one, have run into problems with it when installing Agda. There
is a very long thread here:

https://lists.chalmers.se/pipermail/agda/2014/006975.html

and twice as more on my private inbox. We've reached no conclusion about the cause and the only
solution was to use system-cpp.

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."

Janek

[1] http://projects.haskell.org/cpphs/

Dnia środa, 6 maja 2015, Herbert Valerio Riedel napisał:

> Hello *,
>
> As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
> currently relies on the system's C-compiler bundled `cpp` program to
> provide a "traditional mode" c-preprocessor.
>
> This has caused several problems in the past, since parsing Haskell code
> with a preprocessor mode designed for use with C's tokenizer has caused
> already quite some problems[1] in the past. I'd like to see GHC 7.12
> adopt an implemntation of `-XCPP` that does not rely on the shaky
> system-`cpp` foundation. To this end I've created a wiki page
>
>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
>
> to describe the actual problems in more detail, and a couple of possible
> ways forward. Ideally, we'd simply integrate `cpphs` into GHC
> (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be
> discussed and debated since affects the overall-license of the GHC
> code-base, which may or may not be a problem to GHC's user-base (and
> that's what I hope this discussion will help to find out).
>
> So please go ahead and read the Wiki page... and then speak your mind!
>
>
> Thanks,
>   HVR
>
>
> [1]: ...does anybody remember the issues Haskell packages (& GHC)
>      encountered when Apple switched to the Clang tool-chain, thereby
>      causing code using `-XCPP` to suddenly break due to subtly
>      different `cpp`-semantics?
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Austin Seipp-5
In reply to this post by Herbert Valerio Riedel-3
On Wed, May 6, 2015 at 6:08 AM, Herbert Valerio Riedel
<[hidden email]> wrote:

> Hello *,
>
> As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
> currently relies on the system's C-compiler bundled `cpp` program to
> provide a "traditional mode" c-preprocessor.
>
> This has caused several problems in the past, since parsing Haskell code
> with a preprocessor mode designed for use with C's tokenizer has caused
> already quite some problems[1] in the past. I'd like to see GHC 7.12
> adopt an implemntation of `-XCPP` that does not rely on the shaky
> system-`cpp` foundation. To this end I've created a wiki page
>
>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
>
> to describe the actual problems in more detail, and a couple of possible
> ways forward. Ideally, we'd simply integrate `cpphs` into GHC
> (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be
> discussed and debated since affects the overall-license of the GHC
> code-base, which may or may not be a problem to GHC's user-base (and
> that's what I hope this discussion will help to find out).
>
> So please go ahead and read the Wiki page... and then speak your mind!

Thanks for writing this up, btw! It's nice to put the mumblings we've
had for a while down 'on paper'.

>
> Thanks,
>   HVR
>
>
> [1]: ...does anybody remember the issues Haskell packages (& GHC)
>      encountered when Apple switched to the Clang tool-chain, thereby
>      causing code using `-XCPP` to suddenly break due to subtly
>      different `cpp`-semantics?

There are two (major) differences I can list, although I can only
provide some specific examples OTTOMH:

  1) Clang is more strict wrt language specifications. For example,
GCC is lenient and allows a space between a macro identifier and the
parenthesis denoting a parameter list; so saying 'FOO (x, y)' is valid
with GCC (where FOO is a macro), but not with Clang. Sometimes this
trips up existing code, but I've mostly seen it in GHC itself.

  2) The lexing rules for C and Haskell simply are not the same in
general. For example, what should "FOO(a' + b')" parse to? Well, in
Haskell, 'prime' is a valid component from an identifier and in this
case the parse should be "a prime + b prime", but in C the ' character
is identified as beginning the start of a single-character literal,
and a strict preprocessor like Clang's will reject that.

In practice, I think people have mostly just avoided arcane lexer
behaviors that don't work, and the only reason this was never a
problem was because GCC or some variant was always the 'standard' C
compiler GHC could rely on.

> _______________________________________________
> Glasgow-haskell-users mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>

--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Mikhail Glushenkov-2
On 6 May 2015 at 14:25, Austin Seipp <[hidden email]> wrote:
>   2) The lexing rules for C and Haskell simply are not the same in
> general.

One area where this is irritating is that it makes it impossible to
use Haskell multiline strings together with CPP.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Andrés Sicard-Ramírez-2
In reply to this post by Jan Stolarek
I want to emphasize that cpphs is actively maintained as it's pointed
out in https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCp. The
Agda team has found some cpphs bugs which have been *quickly* fixed by
cpphs's author, Malcolm Wallace. Unfortunately I have not been able to
track down the problem mentioned by Janek Stolarek.

On 6 May 2015 at 06:38, Jan Stolarek <[hidden email]> wrote:

> One thing to keep in mind is that while cpphs will solve some problems of system-cpp, it will also
> bring problems of its own. I, for one, have run into problems with it when installing Agda. There
> is a very long thread here:
>
> https://lists.chalmers.se/pipermail/agda/2014/006975.html
>
> and twice as more on my private inbox. We've reached no conclusion about the cause and the only
> solution was to use system-cpp.
>
> 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."
>
> Janek
>
> [1] http://projects.haskell.org/cpphs/
>
> Dnia środa, 6 maja 2015, Herbert Valerio Riedel napisał:
>> Hello *,
>>
>> As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
>> currently relies on the system's C-compiler bundled `cpp` program to
>> provide a "traditional mode" c-preprocessor.
>>
>> This has caused several problems in the past, since parsing Haskell code
>> with a preprocessor mode designed for use with C's tokenizer has caused
>> already quite some problems[1] in the past. I'd like to see GHC 7.12
>> adopt an implemntation of `-XCPP` that does not rely on the shaky
>> system-`cpp` foundation. To this end I've created a wiki page
>>
>>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
>>
>> to describe the actual problems in more detail, and a couple of possible
>> ways forward. Ideally, we'd simply integrate `cpphs` into GHC
>> (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be
>> discussed and debated since affects the overall-license of the GHC
>> code-base, which may or may not be a problem to GHC's user-base (and
>> that's what I hope this discussion will help to find out).
>>
>> So please go ahead and read the Wiki page... and then speak your mind!
>>
>>
>> Thanks,
>>   HVR
>>
>>
>> [1]: ...does anybody remember the issues Haskell packages (& GHC)
>>      encountered when Apple switched to the Clang tool-chain, thereby
>>      causing code using `-XCPP` to suddenly break due to subtly
>>      different `cpp`-semantics?
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
> ---
> Politechnika Łódzka
> Lodz University of Technology
>
> Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
> prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
>
> This email contains information intended solely for the use of the individual to whom it is addressed.
> If you are not the intended recipient or if you have received this message in error,
> please notify the sender and delete it from your system.
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



--
Andrés
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Karel Gardas
In reply to this post by Herbert Valerio Riedel-3

Herbert,

what about to extend plan (1) to also include cpphs as a bundled option
with all cpphs advantages except no more fork/exec as the bundle will be
in a form of binary application and not library?

Shall I add it? I would not like to make a mess from your page...

Thanks,
Karel
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Sven Panne-2
In reply to this post by Mikhail Glushenkov-2
2015-05-06 16:21 GMT+02:00 Bardur Arantsson <[hidden email]>:
> +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.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Brandon Allbery
On Wed, May 6, 2015 at 10:59 AM, Bardur Arantsson <[hidden email]> wrote:
(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.)

Only if you're convinced it will remain 80/20 for the foreseeable future. I do not want to bet on Linux always being gcc (and dislike the One True Platform-ism that line of thought encourages).

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Brandon Allbery
In reply to this post by Sven Panne-2
On Wed, May 6, 2015 at 11:27 AM, Kosyrev Serge <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Stephen Paul Weber
In reply to this post by Herbert Valerio Riedel-3
>As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
>currently relies on the system's C-compiler bundled `cpp` program to
>provide a "traditional mode" c-preprocessor.

Yes.  This is one of my favourite things in GHC-land -- that an existing,
good-enough, standardised, and widely-deployed solution was chosen over
a NiH reinvention of preprocessing.  This allows other Haskell compilers to
support CPP on basically any system (since cpp is so standard) without much
effort, or even if the compiler does not support {-# LANGUAGE CPP -#} the
user can easily run `cpp` over the source files themselves before feeding
the source into the compiler.

Because it is a real `cpp` being used, the developmer must take care to
follow the CPP syntax in the file that will then be transformed into Haskell
by `cpp` in the same way that C, C++, and other developers have to take
extra care (especially around use of # and end-of-line \) when using `cpp`,
but this is the normal state of affairs for a secondary preprocessor step.  
As a benefit, the source code will be processable by standard `cpp`
implementations available for virtually every platform.

In short, the current solution provides a very robust and portable way to do
pre-compile preprocessing, and I like it very much.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Herbert Valerio Riedel-3
On 2015-05-06 at 17:36:05 +0200, Stephen Paul Weber wrote:

>>As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
>>currently relies on the system's C-compiler bundled `cpp` program to
>>provide a "traditional mode" c-preprocessor.
>
> Yes.  This is one of my favourite things in GHC-land -- that an
> existing, good-enough, standardised, and widely-deployed solution was
> chosen over a NiH reinvention of preprocessing.  This allows other
> Haskell compilers to support CPP on basically any system (since cpp is
> so standard) without much effort, or even if the compiler does not
> support {-# LANGUAGE CPP -#} the user can easily run `cpp` over the
> source files themselves before feeding the source into the compiler.
>
> Because it is a real `cpp` being used, the developmer must take care
> to follow the CPP syntax in the file that will then be transformed
> into Haskell by `cpp` in the same way that C, C++, and other
> developers have to take extra care (especially around use of # and
> end-of-line \) when using `cpp`, but this is the normal state of
> affairs for a secondary preprocessor step.  As a benefit, the source
> code will be processable by standard `cpp` implementations available
> for virtually every platform.
>
> In short, the current solution provides a very robust and portable way
> to do pre-compile preprocessing, and I like it very much.

The problem I have with that line of argument is that we're using the
so-called 'traditional mode' of `cpp`[1] for which afaik there is no
written down common specification different implementations commit to
adhere to (well, that's because 'traditional mode' refers to some vague
implementation-specific "pre-standard" cpp semantics).

And how is the developer supposed to take care to follow the
(traditional mode) CPP syntax, if he can't test it easily with all
potentially used (traditional-mode) `cpp`s out there? This already has
led to problems with Clang's cpp vs GCC's cpp.

Moreover, I was under the impression that it's only a matter of time
till `traditional mode` support may be dropped from C compiler
toolchains. Otoh, we can't use an ISO C spec conforming c-preprocessor,
as that would conflict even more heavily w/ Haskell's grammar to the
point of being inpractical.

 [1]: https://gcc.gnu.org/onlinedocs/cpp/Traditional-Mode.html
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Brandon Allbery
In reply to this post by Stephen Paul Weber
On Wed, May 6, 2015 at 11:36 AM, Stephen Paul Weber <[hidden email]> wrote:
Yes.  This is one of my favourite things in GHC-land -- that an existing, good-enough, standardised, and widely-deployed solution was chosen over a NiH reinvention of preprocessing

I have to assume my irony detector is broken as well. Or maybe I should just assume that "all the world's Linux with gcc" is assumed to be forever true and forever reliable by "all right-thinking people" so let's just sweep the nonissue under the rug because it can oh so obviously never be a real issue....

Because I had to face this back a couple decades ago, when my employer ported an application written in a 4GL (database language) to SCO Unix. The 4GL assumed cpp was the ever reliable pcc one and broke very badly when SCO used one integrated into its lexer (making it even more tightly wedded to C syntax than clang's). Eventually we replaced its cpp with a wrapper that ran m4 and redid everything else in m4's syntax.

Which is why I was always a bit worried about ghc relying on cpp, was unsurprised when clang caused issues, and am rather annoyed that there are people who believe that they can just ignore it because REAL users will always be on Linux with gcc and all them furriners using weird OSes like OS X and FreeBSD can safely be ignored with their not-the-One-True-OS-and-compiler platforms.

Additional historical note that I assume True Believers will ignore as meaningless: X11 used to make the same assumption that cpp was always and forever guaranteed to be friendly to non-C and this still shows at times in things like xrdb resource databases. They did accept the inevitable and (mostly) stop abusing it that way, and are now moving away from imake which likewise assumes it's safe to use cpp on Makefiles. (And yes, I encounter the same inability to comprehend or accept change there.)

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Jan Stolarek
In reply to this post by Andrés Sicard-Ramírez-2
> I want to emphasize that cpphs is actively maintained as it's pointed
> out in https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCp. The
> Agda team has found some cpphs bugs which have been *quickly* fixed by
> cpphs's author, Malcolm Wallace.
Yes. It was not my intention to imply in any way that cpphs suffers from maintanance issues.

> Unfortunately I have not been able to track down the problem mentioned by Janek Stolarek.
Yes, and that's what gets me worried. I suppose the problem was somehow related to my locale
settings although we were unable to track down the cause. I also recall someone else reported
being affected by the same problem. So, until that problem is solved I would say it is a blocker
as it would essentialy make development of GHC impossible for some people.

Janek


>
> On 6 May 2015 at 06:38, Jan Stolarek <[hidden email]> wrote:
> > One thing to keep in mind is that while cpphs will solve some problems of
> > system-cpp, it will also bring problems of its own. I, for one, have run
> > into problems with it when installing Agda. There is a very long thread
> > here:
> >
> > https://lists.chalmers.se/pipermail/agda/2014/006975.html
> >
> > and twice as more on my private inbox. We've reached no conclusion about
> > the cause and the only solution was to use system-cpp.
> >
> > 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."
> >
> > Janek
> >
> > [1] http://projects.haskell.org/cpphs/
> >
> > Dnia środa, 6 maja 2015, Herbert Valerio Riedel napisał:
> >> Hello *,
> >>
> >> As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension
> >> currently relies on the system's C-compiler bundled `cpp` program to
> >> provide a "traditional mode" c-preprocessor.
> >>
> >> This has caused several problems in the past, since parsing Haskell code
> >> with a preprocessor mode designed for use with C's tokenizer has caused
> >> already quite some problems[1] in the past. I'd like to see GHC 7.12
> >> adopt an implemntation of `-XCPP` that does not rely on the shaky
> >> system-`cpp` foundation. To this end I've created a wiki page
> >>
> >>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp
> >>
> >> to describe the actual problems in more detail, and a couple of possible
> >> ways forward. Ideally, we'd simply integrate `cpphs` into GHC
> >> (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be
> >> discussed and debated since affects the overall-license of the GHC
> >> code-base, which may or may not be a problem to GHC's user-base (and
> >> that's what I hope this discussion will help to find out).
> >>
> >> So please go ahead and read the Wiki page... and then speak your mind!
> >>
> >>
> >> Thanks,
> >>   HVR
> >>
> >>
> >> [1]: ...does anybody remember the issues Haskell packages (& GHC)
> >>      encountered when Apple switched to the Clang tool-chain, thereby
> >>      causing code using `-XCPP` to suddenly break due to subtly
> >>      different `cpp`-semantics?
> >>
> >> _______________________________________________
> >> Glasgow-haskell-users mailing list
> >> [hidden email]
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> >
> > ---
> > Politechnika Łódzka
> > Lodz University of Technology
> >
> > Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
> > Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez
> > pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
> >
> > This email contains information intended solely for the use of the
> > individual to whom it is addressed. If you are not the intended recipient
> > or if you have received this message in error, please notify the sender
> > and delete it from your system.
> > _______________________________________________
> > ghc-devs mailing list
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



---
Politechnika Łódzka
Lodz University of Technology

Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.

This email contains information intended solely for the use of the individual to whom it is addressed.
If you are not the intended recipient or if you have received this message in error,
please notify the sender and delete it from your system.
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Andrés Sicard-Ramírez-2
Hi Janek,

On 6 May 2015 at 14:55, Jan Stolarek <[hidden email]> wrote:
> Yes, and that's what gets me worried. I suppose the problem was somehow related to my locale
> settings although we were unable to track down the cause. I also recall someone else reported
> being affected by the same problem.

AFIK, the only cpphs-Agda open problem is your problem. I would like
to know if anyone else has some problem. If so, I propose to move the
discussion to the Agda developers list ([hidden email]).

Best,

--
Andrés
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Herbert Valerio Riedel-3
In reply to this post by Herbert Valerio Riedel-3
On 2015-05-06 at 18:53:08 +0200, Howard B. Golden wrote:
> At the risk of antagonizing some (most? all?) of you, how about...
>
> -XCPP stands for the native CPP
> -XGNUCPP stands for GNU's GCC CPP
> -XClangCPP stands for Clang's CPP
> -XCPPHS stands for CPPHS

Assuming this was a serious suggestion, the benefit is that you could
clearly mark what CPP you want to develop against, but OTOH, we'd lose
backward compat w/ Haskell compilers only knowing about the old -XCPP
but not the other new variants of the language-pragma.

Moreover, there can now be packages that require clang-cpp, while others
require gcc-cpp, and I don't think it can be assumed that both are
available on every GHC installation. So it could cause packages to fail
compiling simply because the respective CPP-flavor is missing.  On the
bright side, this would maybe give us the opportunity to coin the new
term "CPP Hell" =)

Cheers,
  hvr
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Herbert Valerio Riedel
In reply to this post by Jan Stolarek
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Malcolm Wallace-2
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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

wren romano
In reply to this post by Mikhail Glushenkov-2
On Wed, May 6, 2015 at 9:05 AM, Alan & Kim Zimmerman
<[hidden email]> wrote:
> Perhaps it makes sense to scan hackage to find all the different CPP idioms
> that are actually used in Haskell code, if it is a small/well-defined set it
> may be worth writing a simple custom preprocessor.

Conditional imports are far and away the most commonly used idiom.
Second most common, I'd say, is specifying GHC-specific vs
compiler-generic implementations of top-level functions (e.g., using
GHC.Exts.build or not). For both of these it's sufficient to have the
#if construction plus everything needed for the conditional
expressions.

However, while the #if construction covers the vast majority of use
cases, it doesn't cover all of them. Macros are also important. For
example, a number of low-level libraries will use macros for things
like having assertions which are either compiled as runtime checks, or
as nothing, depending on a Cabal flag. Of course, there are plenty of
other places where we want to use macros in low-level code, either to
force inlining, or to have conditional compilation of (non-top-level)
expressions that show up over and over. That these idioms aren't more
common is just because there aren't more people working on such
low-level code.

In theory TH should be able to handle this stuff, but TH is a verbose
sledgehammer for these sorts of problems, and using TH means
restricting yourself to being GHC-only.

--
Live well,
~wren
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Malcolm Wallace-2
In reply to this post by Herbert Valerio Riedel-3

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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

Malcolm Wallace-2
In reply to this post by Malcolm Wallace-2
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
12