RFC: provide patch-level information at __GLASGOW_HASKELL__

Herbert Valerio Riedel hvr at gnu.org
Thu Apr 10 08:55:47 UTC 2014


Hello,

I know this has come up various times. So this is mostly an attempt to
see what the current position is on this topic:

The current scheme is documented as

,----
| The value of __GLASGOW_HASKELL__ for a major release x.y.z is the
| integer xyy (if y is a single digit, then a leading zero is added, so
| for example in version 6.8.2 of GHC we would have
| __GLASGOW_HASKELL__==608).
`----

This has lead to confusion in the past, e.g. the following two values

 __GLASGOW_HASKELL__ == 702

 __GLASGOW_HASKELL__ == 704

were sometimes confused (by me at least) to mean 7.0.2 and 7.0.4
respectively. And sometimes when writing conditionals, it also happened
that '__GLASGOW_HASKELL__ >= 722' was written to mean >= 7.2.2.

Moreover, when GHC 7.2.2 came out, it would have been
useful to be able to discriminate 7.2.1 vs 7.2.2 easily, as some
SafeHaskell properties changed between 7.2.1 and 7.2.2.

Therefore, I'd propose to extend this constant by a patch-level digit
for future GHC versions (starting with 7.10.1), i.e.

__GLASGOW_HASKELL__ == 7090   -- 7.9 branch

__GLASGOW_HASKELL__ == 7100   -- 7.10.1 release candidates
__GLASGOW_HASKELL__ == 7101   -- 7.10.1
__GLASGOW_HASKELL__ == 7102   -- 7.10.2

__GLASGOW_HASKELL__ == 7121   -- 7.12.2

NB: this ensures that __GLASGOW_HASKELL__ retains its ordering
relation. There's just a steeper jump from 7.8.1 to 7.10.1, but existing
code using conditionals such as

#if (__GLASGOW_HASKELL__ >= 708) && (__GLASGOW_HASKELL__  < 709)

for currently existing GHC versions will continue to work as expected.

Alternative ideas:

 - Define a __GLASGOW_HASKELL_PATCHLEVEL__ containing only the
   patch-level number.

   (c.f. GNU GCC's __GNUC_PATCHLEVEL__ constant)

   This one might have the least impact, as its existence can be ignored
   safely, and we could even use this starting with GHC 7.8.2 with low
   risk of affecting users.

 - define a __MIN_VERSION_GHC__(x,y,z) macro in the style of
   Cabal's MIN_VERSION_<pkgname>() macros
 
   While this has the most structure, this has also the issue of
   backward compatibility, as for earlier GHC versions you'd have to
   check for the existence of the macro before using it to avoid
   compile-time errors.


Cheers,
  hvr


More information about the ghc-devs mailing list