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.
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
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
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
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
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
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
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.
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
I'm fully on board with cleaning up the story around package keys, so +1 on
the mission, but I have very few preferences on the particulars.
-Edward
On Fri, May 1, 2015 at 1:06 PM, Edward Z. Yang <ezyang(a)cs.stanford.edu>
wrote:
> In GHC 7.10, we changed the internal representation of names to
> be based on package keys (base_XXXXXX) rather than package IDs
> (base-4.7.0.1), however, we forgot to update the Template Haskell
> API to track these changes. This lead to some bugs in TH
> code which was synthesizing names by using package name and
> version directly, e.g. https://ghc.haskell.org/trac/ghc/ticket/10279
>
> We now propose the following changes to the TH API in order to
> track these changes:
>
> 1. Currently, a TH NameG contains a PkgName, defined as:
>
> newtype PkgName = PkgName String
>
> This is badly misleading, even in the old world order, since
> these needed version numbers as well. We propose that this be
> renamed to PkgKey:
>
> newtype PkgKey = PkgKey String
> mkPackageKey :: String -> PackageKey
> mkPackageKey = PkgKey
>
> 2. Package keys are somewhat hard to synthesize, so we also
> offer an API for querying the package database of the GHC which
> is compiling your code for information about packages. So,
> we introduce a new abstract data type:
>
> data Package
> packageKey :: Package -> PkgKey
>
> and some functions for getting packages:
>
> searchPackage :: String -- Package name
> -> String -- Version
> -> Q [Package]
>
> reifyPackage :: PkgKey -> Q Package
>
> We could add other functions (e.g., return all packages with a
> package name).
>
> 3. Commonly, a user wants to get the package key of the current
> package. Following Simon's suggestion, this will be done by
> augmenting ModuleInfo:
>
> data ModuleInfo =
> ModuleInfo { mi_this_mod :: Module -- new
> , mi_imports :: [Module] }
>
> We'll also add a function for accessing the module package key:
>
> modulePackageKey :: Module -> PkgKey
>
> And a convenience function for accessing the current module:
>
> thisPackageKey :: Q PkgKey
> thisPackageKey = fmap (modulePackageKey . mi_this_mod) qReifyModule
>
> thisPackage :: Q Package
> thisPackage = reifyPackage =<< thisPackageKey
>
> Discussion period: 1 month
>
> Thanks,
> Edward
>
>
