daml/compiler
Martin Huschenbett 7074d92324
Warn about un-upgradability of fancy kinds (#7725)
Haskell allows for promoting types to the kind level with the
`DataKinds` extension. Since DAML-LF has no similar concept (and
frankly speaking should't have one), this does not work well with
data-dependencies. Unfortunately, we need to enable the `DataKinds`
extension by default in `damlc` since our record system and the
`Numeric` type depend on it. Thus, issuing a warning that the
`DataKinds` is not supported with data-dependencies is not an option
and we need more refined warnings.

Most uses of promoted kinds won't even compile to DAML-LF and there's
no need to warn about those since they cause hard failures. However,
we need some limited support for type-level strings and the `Symbol`
kind, for type-level numbers and the `Nat` kind, as well as for some
stuff from `DA.Generics`. Type-level numbers and the `Nat` kind work
reasonable well since we have them in DAML-LF too. The `Symbol` kind,
and the types and kinds from `DA.Generics` are "erased" during
conversion to DAML-LF by replacing them with either a special `Erased`
type or the star kind. Thus, these entities are not restored properly
with data-dependencies. In combination with type classes this leads
easily to instances that for different types in the original code but
are at conflict during interface reconstruction. Long story short,
erased types/kinds and type classes don't work with data-dependencies.

We have a hack to somehow preserve type-level string since we need that
for our record system and the `HasField` type class. I have no desire
to support this hack for arbitrary type classes coming from the user.
Thus, I consider type-level strings to be erased as well here.

This PR adds a warning whenever a user is attempting to define a type
class that involves a kind that will be erased or an instance that
involves a type that will be erased. The warning tells the user that
this does not work with data-dependencies and is hence not upgradable.

There is one caveat: the `HasField` instances produced by the
propressor fall in the category we should warn about as well. Since not
supporting them would make our record system unusable, we need to give
them special treatment in data-dependencies. Thus, warning about them
would be unjustified noise and we explicitly exclude them in the code
producing the warnings.

CHANGELOG_BEGIN
[DAML Compiler] Issue warning when advanced types are with type classes
in a way that is supported by data-dependencies.
CHANGELOG_END
2020-10-19 10:13:51 +02:00
..
daml-extension Remove version header from vscode snippet (#7452) 2020-09-21 16:59:47 +02:00
daml-lf-ast LF: Add ExerciseByKey Update (#7663) 2020-10-14 12:06:36 +02:00
daml-lf-proto LF: Add ExerciseByKey Update (#7663) 2020-10-14 12:06:36 +02:00
daml-lf-reader DEL-8132 extract DAML LF haskell libraries (scripted) (#7246) 2020-09-01 12:09:26 +10:00
daml-lf-tools Use $$ instead of $ for new name prefixes in damlc (#7701) 2020-10-16 12:13:44 +01:00
daml-lf-verify Fix record update evaluation order. (#6590) 2020-07-03 11:25:44 +01:00
daml-licenses Connectify user-facing output (#7624) 2020-10-09 15:45:02 +02:00
damlc Warn about un-upgradability of fancy kinds (#7725) 2020-10-19 10:13:51 +02:00
ghcide Get ghcide from the new upstream repo (#2867) 2019-09-11 08:57:48 +02:00
hie-core Get ghcide from the new upstream repo (#2867) 2019-09-11 08:57:48 +02:00
lsp-tests Deprecate the "daml 1.2" version header. (#7513) 2020-09-29 13:14:59 +00:00
repl-service LF: add PackageInterface a lightweigh Package (#7577) 2020-10-13 12:41:22 +02:00
scenario-service LF: enforce non-empty maintainers in contract key in fetchByKey (#7649) 2020-10-15 12:22:56 +02:00
README.md open-sourcing daml 2019-04-04 09:33:38 +01:00

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.