Skip to content

v1.7.0-snapshot.20201020.5481.0.03a03957

@hurryabit hurryabit tagged this 20 Oct 20:15
I tried a compiler with these new warnings on a giant codebase and I
turned out they are _extremely_ noisy. There are basically two things we
want to warn about:

1.  Usage of the promoted kinds and types coming from the `DA.Generics`
    module.

    We already have a warning that importing `DA.Generics` will break
    data-dependencies. Adding a warning to every single use site of its
    exports seems rather excessive and doesn't add any new information.

2.  Usage of the `Symbol` kind and type-level strings.

    The `Symbol` kind seems to work better with data-dependencies than I
    expected although it is erased into kind `*` during conversion to
    DAML-LF. This is for two reasons: (1) The only _legal_ way to
    introduce a type variable of kind `Symbol` is by means of the
    `HasField` typeclass (you can technically get your hands on the
    `Symbol` kind directly, but you need work around not being able to
    import the internal module `GHC.Types`). (2) In data-dependencies,
    we reconstruct type variables of kind `*` not as kind `*` but rather
    ask GHC to infer their kinds (via
    [`UserTyVar`](https://hackage.haskell.org/package/ghc-8.10.1/docs/src/GHC.Hs.Types.html#UserTyVar)).
    This means that every type variable that was originally of kind
    `Symbol` will be reconstructed at that kind again since the
    necessary `HasField` constraint will force GHC to infer it.

    I'm totally aware that it looks a lot like this works by accident
    but I'm not completely opposed to making it a feature after the
    fact. Before we make any decisions in this regard though, we should
    decide on what uses of kind `Symbol` we want to make compatible with
    data-dependencies. For instance, functions of types like

        overField: forall x r a. HasField x r a => (a -> a) -> r -> r

    might be something we want to support. We also need to support
    constraints of the form `HasField "abc" ...` with a concrete
    type-level string everywhere. The current implementation would have
    warned about them. Thus, I see two open questions around the
    `Symbol` kind: (1) Do we want to allow `HasField x r a`, where `r`
    is a type variable and _not_ a type-level string, to be a superclass
    constraint? (2) Do we want to allow the same constraint in the
    context of a typeclass instance?

    One thing we should definitely not allow is using the `Symbol` kind
    directly under its name `GHC.Types.Symbol`, which is always in scope
    for our record preprocessor. I will add an error when users try to
    access that kind in a separate PR.

CHANGELOG_BEGIN
[DAML Compiler] The warning about advanced types combined with type
classes in a way that is supported by data-dependencies has been removed
again.
CHANGELOG_END
Assets 2
Loading