RFC: provide patch-level information at __GLASGOW_HASKELL__
Austin Seipp
austin at well-typed.com
Thu Apr 10 13:57:26 UTC 2014
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 <roma at ro-che.info> 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 <hvr at gnu.org> [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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
--
Regards,
Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
More information about the ghc-devs
mailing list