That's most of it now - just missing a section on multiplicities, and a
section on the differences from Idris 1.
Ideally, there should also be a much more gentle introduction (basically
doing the same as the first 3 chapters of TypeDD in Idris). But that's
for some other time...
These are still to be updated (as noted in the files), but it needs
doing before any kind of preliminary release. Plan is to refresh the
tutorial and make sure samples work again, then write a more
comprehensive document explaining changes since Idris 1.
These can give valuable information, but since they're not well typed,
we have to rebuild as close an approximation as we can before passing it
to the case tree compiler. We can do this in a type-directed way, but
ignoring whether any of the arguments are convertible, and not trying to
solve any of the implicits. If this fails, it doesn't use the impossible
case, otherwise it uses it to find the missing cases in the resulting
case tree.
This includes:
* Removing `%access` directives and inlining their visibility modifiers
* Fixing irrelevance annotations
* Including some standard libraries
The result is still not idris2 ready:
1. Incompatibility with the new Laziness mechanism, as it's missing
some previous laziness/codata bindings
2. Some standard library functions moved around, and are now found in
`Data.Nat`, that doesn't exist in Idris1
Since the totality checker isn't plugged in yet, these do nothing
functionally, but they do add appropriate totality annotations all the
way up to the internal `TT` representation.
Design choices:
1. default totality annotations are session-local, so should be reset
between files.
2. the default default is `PartialOK`.
3. we won't annotate a definition with `PartialOK` unless the user
inserts one themselves, relying on the previous point (2).
This looks for an .ipkg file in a parent directory before loading the
given file, and loads it relative to the .ipkg's source directory, with
the options specified in the .ipkg.
The intention is to save all the editor modes having to do the same
thing, and especially makes it possible for the new vim mode to work
with ipkgs.
If the name is given (rather than, say, computed) update it so that it's
the data type name being defined - so ambiguities are resolved
immediately. Fixes#192
Pass through the types of the interface parameters to the top level
method types, because there might be information in there that we can't
otherwise infer. Fixes#188
This means we can say 'let x = foo' and have foo not be applied to its
implicit arguments, meaning that 'x' can be instantiated at whatever
implicits it needs through the scope.
