Fix build after GHC known-keys patch (10.1) - #244
Conversation
|
CI keeps failing in my fork on job ghc-i386 seemingly because of a GHCup failure |
konsumlamm
left a comment
konsumlamm
left a comment
There was a problem hiding this comment.
Has there been a CLC proposal for the changes to base? I don't really like that the behaviour depends on the used GHC version, but I guess there is no clean way around that.
| #if __GLASGOW_HASKELL__ >= 1001 | ||
| put KindRepType = putWord8 4 | ||
| put KindRepConstraint = putWord8 5 | ||
| put (KindRepTypeLit sort r) = putWord8 6 >> put sort >> put r | ||
| #else | ||
| put (KindRepTYPE r) = putWord8 4 >> put r | ||
| put (KindRepTypeLit sort r) = putWord8 5 >> put sort >> put r | ||
| #endif |
There was a problem hiding this comment.
What does Binary guarantee in the way of stability of the representation? It seems unfortunate that a serialised KindRep may fail to deserialise if you change the GHC version.
I think this patch could avoid that in most cases, though, by choosing the serialisation scheme to be backwards compatible (see below).
(I'm not sure what KindRepConstraint corresponds to, and if someone had serialised KindRepTYPE r for a strange runtime rep it might be impossible to deserialise in the new version, but I think the common case will be KindRepTYPE (BoxedRep Lifted) and we could make sure that has the same serialisation?)
| #if __GLASGOW_HASKELL__ >= 1001 | |
| put KindRepType = putWord8 4 | |
| put KindRepConstraint = putWord8 5 | |
| put (KindRepTypeLit sort r) = putWord8 6 >> put sort >> put r | |
| #else | |
| put (KindRepTYPE r) = putWord8 4 >> put r | |
| put (KindRepTypeLit sort r) = putWord8 5 >> put sort >> put r | |
| #endif | |
| #if __GLASGOW_HASKELL__ >= 1001 | |
| put KindRepType = putWord8 4 >> putWord8 3 -- was (BoxedRep Lifted) | |
| put KindRepConstraint = putWord8 4 >> putWord8 _ -- not sure what this should be? | |
| #else | |
| put (KindRepTYPE r) = putWord8 4 >> put r | |
| #endif | |
| put (KindRepTypeLit sort r) = putWord8 5 >> put sort >> put r |
There was a problem hiding this comment.
KindRepConstraint corresponds to KindRepApp $tcCONSTRAINT [...] where $tcCONSTRAINT is the ty con automatically generated when compiling the module defining CONSTRAINT
There was a problem hiding this comment.
Okay, so the same thing should in principle work? We just need to adjust the serialised version of KindRepConstraint to match that? (Though I suppose there is a round-trip failure wherein KindRepConstraint would be indistinguishable from KindRepApp $tcCONSTRAINT [...]...)
There was a problem hiding this comment.
but this would already be the case if you previously desugared something as KindRepApp $tcTYPE [...] rather than as KindRepTYPE [...]
There was a problem hiding this comment.
What does
Binaryguarantee in the way of stability of the representation? It seems unfortunate that a serialisedKindRepmay fail to deserialise if you change the GHC version.
There are currently no stability guarantees I'm aware of. The Binary TypeRep instance unfortunately also has this problem. At the end of the day, I doubt that anyone (except maybe GHC) actually uses these instances though.
I think this patch could avoid that in most cases, though, by choosing the serialisation scheme to be backwards compatible (see below).
That would be ideal.
3 participants
Prepares
binaryfor the about-to-land GHC MR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15899