* feat: overwrite existing interface implementations
This commit alters the behavior of interfaces so that implementations
with the same type signature will overwrite previous implementations
with that signature--before this was a runtime error.
Previously, if a user defined two distinctly named implementations of an
interface that shared a type, Carp would panic and error at runtime if
the interface was called and resolved to the type, since it couldn't
decide which implementation to use from the type alone. After this
commit, we instead issue a warning and overwrite existing
implementations of the same type, so that defining:
```
(defn foo [] 0)
(implements zero foo)
```
will replace `Int.zero` in the `zero` interface's implementation path
list and won't result in a runtime error--instead `foo` will be called
when `zero` is called in a context in which it returns an int:
```
[WARNING] An implementation of the interface zero with type (Fn [] Int)
already exists: Int.zero. It will be replaced by the implementation:
foo.
This may break a bunch of upstream code!
```
test/interface.carp also has a concrete illustration of this case.
* chore: address hlint suggestions
* fix: don't print overridden interface implementations in info
This commit updates our handling of interface overrides to remove
interfaces from the implements meta of a function that was overridden by
a new implementation.
Similarly, this refactors primitiveInfo to prevent printing binders that
do not actually implement an interface.
* refactor: incorporate @TimDeve's error message suggestion
Constrained interfaces require little change to core carp. In rare cases
(illustrated in test/interfaces.carp) we need to make our functions
slightly more specific. This weakens inference slightly, but in my
opinion is a reasonable case of weakness and not a fault of the type
system.
Exceptional cases that were typed `a-> a` that is, cases that relied on
the previous typing errors related to interfaces, as might be expected,
no longer work (as is the case for the higher-order use of fmap in
examples/functor.carp).
Aside from that, nothing changes.
These tests just check some basic assumptions about the way interfaces
are implemented using the `implements` primitive
- They can be implemented with functions of any name.
- They can be implemented retroactively.
- `Implements` declarations can precede definitions.
