Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
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/
On Wed, May 6, 2015 at 1:18 PM, Johannes Waldmann
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.
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 Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
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
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 Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
2015-05-06 22:18 GMT+02:00 Johannes Waldmann
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.
Il giorno 06/mag/2015, alle ore 23:07, Sven Panne
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.
Hi all, I'm following the discussion from the outside but I'm wondering if you have considered the following idea. From what I understand the current problem with using the system's cpp is inconsistency between different compilers, is it? Then why don't you _import_ the clang's preprocessor into GHC source tree and use that? As you probably know clang is not only a compiler, but a set of libraries to handle C/C++ code. AFAIK linking only the lexer module (which is responsible for the preprocessor) and its direct dependencies, which at the end amount to libLLVMCore and the C++ standard library, shouldn't be too much size overhead (ymmv). The license is also ok, since it's a BSD-something. To also address the issue of how the preprocessor handles Haskell tokens in macros, if you import the source someone could make a patch to add an option to make the preprocessor less strict (but I'm sure to have seen already something to opt for a lax semantics when the preprocessor is used standalone, need to check that). If done well and promised to be maintained, I think the patch could also be accepted mainstream (it's not the first time an LLVM project accepts GHC specific patches, see the support for its call convention in the code generator). Greetings, Nicola
On 2015-05-07 at 08:42:52 +0200, Nicola Gigante wrote: [...]
More seriously: We don't want to break hundreds of packages on Hackage
[...]
I'm following the discussion from the outside but I'm wondering if you have considered the following idea.
From what I understand the current problem with using the system's cpp is inconsistency between different compilers, is it?
Yes... and historically, large amounts of *existing* code on Hackage were written against GCC cpp's traditional-mode, and when Apple pushed a large amount of users/developers to use the Clang toolchain, packages started becoming compatible w/ Clang's cpp (and for the record, Clang-cpp's lack of a "proper" traditional-mode has not only caused problems for GHC, see e.g. https://wiki.freebsd.org/PortsAndClang/CppIssues)
Then why don't you _import_ the clang's preprocessor into GHC source tree and use that?
That's an interesting thought. I've added your suggestion to the wiki proposal-page as a sub-variant of "plan 1" (or does it rather constitute a new plan of its own?) However, without effectively convincing clang's cpp implementation to emulate more of gcc's -traditional mode, this would most likely break old package versions available on Hackage that still work perfectly fine now w/ gcc-cpp (but not clang-cpp), as clang-cpp divergence from gcc-cpp (which was till then the defacto-standard for how -XCPP was expected to behave) is the reason we're having this discussion now in the first place.
As you probably know clang is not only a compiler, but a set of libraries to handle C/C++ code. AFAIK linking only the lexer module (which is responsible for the preprocessor) and its direct dependencies, which at the end amount to libLLVMCore and the C++ standard library, shouldn't be too much size overhead (ymmv). The license is also ok, since it's a BSD-something.
To also address the issue of how the preprocessor handles Haskell tokens in macros, if you import the source someone could make a patch to add an option to make the preprocessor less strict (but I'm sure to have seen already something to opt for a lax semantics when the preprocessor is used standalone, need to check that). If done well and promised to be maintained, I think the patch could also be accepted mainstream (it's not the first time an LLVM project accepts GHC specific patches, see the support for its call convention in the code generator).
Personally, I'm much more motivated to work on improving Haskell-code than to maintain a 3rd party C/C++-based preprocessor component. So I'm afraid that unless we find this "someone" who is willing to provide the willpower and time to bend Clang's preprocessor library to GHC's needs (which foremost would mean to maximize compatibility w/ *existing* code on Hackage using -XCPP, assuming that's a good heuristic for also maximizing compatibility w/ code *not* on Hackage) And judging from past discussions such as http://comments.gmane.org/gmane.comp.compilers.clang.scm/67381 I'm skeptical that Clang's cpp (whose token-based parsing seems to be in conflict with character-based parsing which is more suited for traditional-mode non-C semantics) Cheers, hvr
participants (7)
-
amindfv＠gmail.com -
David Kraeutmann -
Evan Laforge -
Herbert Valerio Riedel -
Johannes Waldmann -
Nicola Gigante -
Sven Panne