Named contracts about nickel HOT 3 CLOSED

A bit more background on this. There are two problems in Nix:

Values don't have names

This is primarily annoying for error messages / documentation. For example, in

let
  someContract = contract { ... };
in someContract

the name someContract is lost. (Attrsets know the names of their attributes, but after selecting an attribute, the resulting value doesn't know where it came from.) So if you use the contract in some way, e.g.

myPackage = { implements someContract; ... }; # whatever the syntax is

then you can't show in the user interface that myPackage implements "someContract". Indeed it would be equivalent to inline the definition of someContract:

myPackage = { implements contract { ... }; ... };

No top-level declarations

Nix only has values. It doesn't have a concept of file/module-level declarations of functions/types/contracts/... But values don't have an identity, so the only way to compare them is by comparing their contents. This could be a problem with multiple inheritance of contracts, e.g.

basePackage = contract { /* options like "name", "phases", "srcs", ... */ };
pythonPackage = contract { extends basePackage; ... };
rustPackage = contract { extends basePackage; ... };
# A package that uses both Python and Rust:
myPackage = { implements pythonPackage; implements rustPackage; ... };

So here myPackage inherits basePackage via two different paths. But if basePackage doesn't have an identity, it's not clear that pythonPackage and rustPackage extend the same basePackage. Again, inlining gives

pythonPackage = contract { extends contract { /* options like "name", "phases", "srcs", ... */ }; ... };
rustPackage = contract { extends contract { /* options like "name", "phases", "srcs", ... */ }; ... };
# A package that uses both Python and Rust:
myPackage = { implements pythonPackage; implements rustPackage; ... };

so myPackage has conflicting definitions of name etc. Now, we could merge identical definitions, but it's not clear that option definitions are always comparable (e.g. function values are probably not comparable). Also, contracts should be able to set options in the contracts that they extend (e.g. rustPackage might want to add to the phases option in basePackage), which means they should be "executed" only once even if they inherited via multiple paths.

So this suggests that contracts shouldn't be values, but top-level declarations, and we should have nominal rather than structural typing.

from nickel.

This is an old issue, but I think the recent machinery of Nickel could alleviate the original issue without introducing either nominal typing or named contract.

Values don't have names

Error messages and documentation show the original contract annotation (very similar to a type annotation), which uses the original name of the contract. Contract application remembers the position of this annotation which is showed in error messages (and documentation - e.g. nickel query - simply uses the annotation directly). As of now, it doesn't seem to be a specific problem we encountered in practice.

No top-level declarations

I would rename this one as avoid re-applying a base contract several time. Right now it is indeed an issue we have encountered, although now that we have array merging, it only happens where there's a function defined inside a contract, which seems to be much rarer. One solution, for which we already have the machinery, is to reuse the contract equality check (it's an incomplete check used by the typechecker, but which is able up to some depth to determine that two contracts are equal because they are structurally the same or because the point to the same code in the original AST). This could be used to avoid double applications and the associated issues. The downside is that contract equality is necessarily incomplete (and in practice we want the check to be quick, there will probably be false negative), so this is more fragile.

from nickel.

I don't think we will further explore named contracts. We now have contract deduplication, as explained in the last comment.

The question of top-level declaration for modules, contracts, interfaces etc. might still be relevant, but it's a different (and cross-cutting) concern that would mandate its own separate discussion.

from nickel.