RFC: provide patch-level information at __GLASGOW_HASKELL__

[Carter Schonwald]

+1 !


On Thu, Apr 10, 2014 at 6:33 PM, Edward Kmett <ekmett at gmail.com> 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 <austin at well-typed.com>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 <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/
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140410/ae14c034/attachment.html>