On Thu, Mar 05, 2026 at 12:48:58PM +0100, Henning Thielemann wrote:
> > The general principle (albeit one that is not necessarily widely
> > understood or well advertised) is that package APIs should not depend on
> > flag assignments, for precisely the reason you outline:
>
> I think that condition is satisfied here: The API of tls is independent from
> whether mlkem calls crypton or cryponite.
>
> So in principle things should work if `tls` uses `crypton`, and `mlkem` uses
> `cryptonite`, as Cabal might choose as default.
Sadly, things don't turn out that way. Various functions in the MLKEM
API carry type class constraints like `MonadRandom r`, ... where the
MonadRandom in question is either the one from `cryptonite` or
`crypton`, and so not the same API as far as the type system is
concerned.
In paricular, when `tls` (using `crypton`) tries to provide a
`MonadRandom r`, it is the *wrong* one when `mlkem` is built with
`cryptonite` and the code fails to compile.
Bottom line, the two variants of `mlkem` don't end up offering the same
API (distinct type signatures, that only look the same).
So either forking `mlkem` or a major version bump seem to be the
sensible choices. I hope Olivier can be convinced to go the version
bump route.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
ghc-devs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
