May 2015 - Libraries - Haskell.org

Re: RFC: "Native -XCPP" Proposal
by Herbert Valerio Riedel 08 May '15

08 May '15

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_pro…

2 1

Proposal: Add "fma" to the RealFloat class
by Levent Erkok 07 May '15

07 May '15

This proposal is very much in the spirit of the earlier proposal on adding new float/double functions; for instance see here: https://mail.haskell.org/pipermail/libraries/2014-April/022667.html "fma" (a.k.a. fused-multiply-add) is one of those functions; which is the workhorse in many HPC applications. The idea is to multiply two floats and add a third with just one rounding, and thus preserving more precision. There are a multitude of applications for this operation in engineering data-analysis, and modern processors come with custom implementations and a lot of hardware to support it natively. I created a ticket along these lines already: https://ghc.haskell.org/trac/ghc/ticket/10364 Edward suggested that the matter should further be discussed here. I think the proposal is rather straightforward, and should be noncontroversial. To wit, we shall add a new method to the RealFloat class: class (RealFrac a, Floating a) => RealFloat a where ... fma :: a -> a -> a -> a The intention is that fma x y z = x * y + z except the multiplication and addition are done infinitely-precisely, and then rounded only once; as opposed to two roundings as one would get with the above implementation. Most modern architectures directly support this operation so we can map it easily; and in case the architecture does not have it available, we can get it via the C-math libraries, where it appears under the names fma (the double version), and fmaf (the float version.) There should be no default definitions; as an incorrect (two-rounding version) would essentially beat the purpose of having fma in the first place. While the name "fma" is well-established in the arithmetic/hardware community and in the C-library, we can also go with "fusedMultiplyAdd," if that is deemed more clear. Discussion period: 2 weeks.

22 49

Re: RFC: "Native -XCPP" Proposal
by Howard B. Golden 07 May '15

07 May '15

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

2 1

Re: RFC: "Native -XCPP" Proposal
by Andrés Sicard-Ramírez 07 May '15

07 May '15

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 <jan.stolarek(a)p.lodz.pl> 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 >> Glasgow-haskell-users(a)haskell.org >> 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 > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Andrés

2 2

Re: RFC: "Native -XCPP" Proposal
by Brandon Allbery 07 May '15

07 May '15

On Wed, May 6, 2015 at 11:36 AM, Stephen Paul Weber < singpolyma(a)singpolyma.net> 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 allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Re: RFC: "Native -XCPP" Proposal
by Herbert Valerio Riedel 07 May '15

07 May '15

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

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Brandon Allbery 07 May '15

07 May '15

On Wed, May 6, 2015 at 11:27 AM, Kosyrev Serge <_deepfire(a)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 allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Brandon Allbery 07 May '15

07 May '15

On Wed, May 6, 2015 at 10:59 AM, Bardur Arantsson <spam(a)scientician.net> 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 allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal
by Sven Panne 07 May '15

07 May '15

2015-05-06 16:21 GMT+02:00 Bardur Arantsson <spam(a)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.

1 0

Ord for partially ordered sets
by Ivan Lazar Miljenovic 05 May '15

05 May '15

What is the validity of defining an Ord instance for types for which mathematically the `compare` function is partially ordered? Specifically, I have a pull request for fgl [1] to add Ord instances for the graph types (based upon the Ord instances for Data.Map and Data.IntMap, which I believe are themselves partially ordered), and I'm torn as to the soundness of adding these instances. It might be useful in Haskell code (the example given is to use graphs as keys in a Map) but mathematically-speaking it is not possible to compare two arbitrary graphs. What are people's thoughts on this? What's more important: potential usefulness/practicality or mathematical correctness? (Of course, the correct answer is to have a function of type a -> a -> Maybe Ordering :p) [1]: https://github.com/haskell/fgl/pull/11 -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com http://IvanMiljenovic.wordpress.com

8 10