RFC: "Native -XCPP" Proposal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
45 messages Options
123
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?

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

Re: RFC: "Native -XCPP" Proposal

Alan & Kim Zimmerman
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.

Alan

On Wed, May 6, 2015 at 3:03 PM, Mikhail Glushenkov <[hidden email]> wrote:
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.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


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

Re: RFC: "Native -XCPP" Proposal

Bardur Arantsson-2
In reply to this post by Alan & Kim Zimmerman
On 06-05-2015 15:05, Alan & Kim Zimmerman 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.
>

+1, I'll wager that the vast majority of usages are just for version
range checks.

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.

Regards,

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

Re: RFC: "Native -XCPP" Proposal

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

Re: 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

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

Re: 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

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

Re: RFC: "Native -XCPP" Proposal

Brandon Allbery
In reply to this post by Herbert Valerio Riedel-3
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

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

Re: RFC: "Native -XCPP" Proposal

Howard B. Golden
In reply to this post by Herbert Valerio Riedel-3
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

... with the hope that TH is the future?


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

Re: RFC: "Native -XCPP" Proposal

Johannes Waldmann-2
In reply to this post by Herbert Valerio Riedel-3
There is maybe another option: do what csharp does.

Define a reduced "preprocessor" (for conditional compilation,
but without macro expansion) as part of the language.
(cf. https://msdn.microsoft.com/en-us/library/ed8yd1ha.aspx )

They must have have had good reasons for doing it this way.

- J.W.

PS: I was trying to add a proper reference (to the language spec)
but this seems hard. It is Section 9.5 of ECMA-334.
For viewing the newer specs, it seems you need to have MS-Word or
VS installed. See also http://stackoverflow.com/questions/13467103/
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Evan Laforge
On Wed, May 6, 2015 at 1:18 PM, Johannes Waldmann
<[hidden email]> wrote:
> There is maybe another option: do what csharp does.
>
> Define a reduced "preprocessor" (for conditional compilation,
> but without macro expansion) as part of the language.
> (cf. https://msdn.microsoft.com/en-us/library/ed8yd1ha.aspx )

Rust is also doing this, but they have their own syntax, not CPP.  I
think they'll save themselves some hassle this way.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

David Kraeutmann
In reply to this post by Johannes Waldmann-2
I like this idea. If we need macro expansion, we can do that (and should
be doing it) more formally and safer using TH.
Ideally conditional compilation should be also done using TH, but it
might be overkill for some use cases.

On 5/6/2015 10:18 PM, Johannes Waldmann wrote:

> There is maybe another option: do what csharp does.
>
> Define a reduced "preprocessor" (for conditional compilation,
> but without macro expansion) as part of the language.
> (cf. https://msdn.microsoft.com/en-us/library/ed8yd1ha.aspx )
>
> They must have have had good reasons for doing it this way.
>
> - J.W.
>
> PS: I was trying to add a proper reference (to the language spec)
> but this seems hard. It is Section 9.5 of ECMA-334.
> For viewing the newer specs, it seems you need to have MS-Word or
> VS installed. See also http://stackoverflow.com/questions/13467103/
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

amindfv
My 2¢ would be that being backwards-compatible is more important than TH integration (if that's even possible). Even if we do the rust/c# way, I think we should use existing syntax. Cpp should really feel like a necessary evil, not like a central part of the language. Inelegance is a virtue.

Tom


El May 6, 2015, a las 16:27, David Kraeutmann <[hidden email]> escribió:

> I like this idea. If we need macro expansion, we can do that (and should
> be doing it) more formally and safer using TH.
> Ideally conditional compilation should be also done using TH, but it
> might be overkill for some use cases.
>
> On 5/6/2015 10:18 PM, Johannes Waldmann wrote:
>> There is maybe another option: do what csharp does.
>>
>> Define a reduced "preprocessor" (for conditional compilation,
>> but without macro expansion) as part of the language.
>> (cf. https://msdn.microsoft.com/en-us/library/ed8yd1ha.aspx )
>>
>> They must have have had good reasons for doing it this way.
>>
>> - J.W.
>>
>> PS: I was trying to add a proper reference (to the language spec)
>> but this seems hard. It is Section 9.5 of ECMA-334.
>> For viewing the newer specs, it seems you need to have MS-Word or
>> VS installed. See also http://stackoverflow.com/questions/13467103/
>> _______________________________________________
>> Haskell-Cafe mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
> _______________________________________________
> Haskell-Cafe mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: RFC: "Native -XCPP" Proposal

Sven Panne-2
In reply to this post by Johannes Waldmann-2
2015-05-06 22:18 GMT+02:00 Johannes Waldmann
<[hidden email]>:
> There is maybe another option: do what csharp does.
>
> Define a reduced "preprocessor" (for conditional compilation,
> but without macro expansion) as part of the language.
> (cf. https://msdn.microsoft.com/en-us/library/ed8yd1ha.aspx )

I'd like to repeat that this is *not* a full solution IMHO, everybody
doing cross-platform FFI bindings needs macro expansion to handle the
differences in calling conventions. Of course this can be done by
duplicating all "foreign imports" etc. for every calling convention
involved, but this is not really a solution to actual needs.

> They must have have had good reasons for doing it this way.

"Doing things differently" has always been a tradition for certain
companies... ;-)

More seriously: We don't want to break hundreds of packages on
Hackage, the only thing we really need is a well-defined CPP-like
preprocessor, so integrating e.g. cpphs somehow seems to be the right
way IMHO. If it's not cpphs, I wouldn't mind, the main point is that
it's the same on all platforms and handles basically *all* things CPP
can.

TH is nice, but I'm not sure if it can handle 100% of the CPP use
cases, and remember: There are Haskell implementations out there which
don't support TH.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
123