I agree with Roman. I think just adding a new PATCHLEVEL macro is the way to go and complementary to the existing setup, without confusing things. On Thu, Apr 10, 2014 at 6:18 AM, Roman Cheplyaka wrote:

I've never needed this so far, but if this gets implemented, I'm in favour of a separate __GLASGOW_HASKELL_PATCHLEVEL__ macro.

As you say, the existing scheme is somewhat non-intuitive. But having two schemes simultaneously carries an even bigger mental overhead. And it's too easy to forget that the scheme has changed when testing for newer ghc versions.

Roman

* Herbert Valerio Riedel [2014-04-10 10:55:47+0200]

...

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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

---

ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

+1 ! On Thu, Apr 10, 2014 at 6:33 PM, Edward Kmett wrote:

+1 on the PATCHLEVEL variant. (for that matter, +1 on the other if it is all I can get!)

I've wanted something like this for a long time.

-Edward

On Thu, Apr 10, 2014 at 9:57 AM, Austin Seipp wrote:

...

I agree with Roman. I think just adding a new PATCHLEVEL macro is the way to go and complementary to the existing setup, without confusing things.

On Thu, Apr 10, 2014 at 6:18 AM, Roman Cheplyaka wrote:

...

I've never needed this so far, but if this gets implemented, I'm in favour of a separate __GLASGOW_HASKELL_PATCHLEVEL__ macro.

As you say, the existing scheme is somewhat non-intuitive. But having two schemes simultaneously carries an even bigger mental overhead. And it's too easy to forget that the scheme has changed when testing for newer ghc versions.

Roman

* Herbert Valerio Riedel [2014-04-10 10:55:47+0200]

...

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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

---

ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Regards,

Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

On 2014-04-11 at 10:38:00 +0200, Simon Marlow wrote: [...]

We could add a __GLASGOW_HASKELL_PATCHLEVEL__ macro, but I'd like to understand more about why people need this, and whether we should be more careful about what we do in patchlevel releases.

What about the use-case when you want to workaround a compiler bug that existed for GHC==7.6.1 but which was fixed for GHC>=7.6.2 (and thus doesn't need the workaround anymore)?