mirror of
https://github.com/digital-asset/daml.git
synced 2024-09-20 01:07:18 +03:00
03a03957d9
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
|
||
|---|---|---|
| .. | ||
| daml-extension | ||
| daml-lf-ast | ||
| daml-lf-proto | ||
| daml-lf-reader | ||
| daml-lf-tools | ||
| daml-lf-verify | ||
| daml-licenses | ||
| damlc | ||
| ghcide | ||
| hie-core | ||
| lsp-tests | ||
| repl-service | ||
| scenario-service | ||
| README.md | ||
DAML Compiler
This directory contains several libraries used by and the executable for the DAML compiler.
Libraries
daml-lf-ast: The DAML-LF AST and type checker.