This is (for once) not a breaking changes, instead backends will need to opt in to this change, using the utilities in Compiler.NoMangle. See the js backend for an example of how to do this.
This is the first step to being able to use idris to create libraries usable by other languages.
* [ new ] :doc for keywords
* [ doc ] for visibility
* [ more ] fixing help text, sentence for "mutual"
* [ doc ] for if then else
* [ doc ] for implicit arguments
* [ doc ] import
* [ cleanup ] doc for data
* [ doc ] for record
* [ doc ] for forall quantifier
* [ doc ] for `in' keyword
* [ doc ] for parameters block
* [ fix ] missing fence
* [ doc ] for where and mutual blocks
* [ doc ] for namespace blocks
* [ doc ] for with/proof
* [ doc ] for do blocks
* [ doc ] for rewrite
* [ doc ] for let binding
* [ doc ] for case...of and interfaces
* [ doc ] for fixity
* [ refactor ] user proper int types for Constant
* [ cleanup ] declare standalone TTC implementations for BitsN/IntN
Rather than doing the casting inline, have the (en/de)coding all
side by side in one place
* [ cleanup ] remove duplicated code
Co-authored-by: Guillaume ALLAIS <guillaume.allais@ens-lyon.org>
* so much experimentation
* tests that show preliminary evidence the new stuff is working.
* small amount of cleanup
* more cleanup of various troubleshooting code.
* new test case added.
* only log unreachable indices if there are any.
* when traversing deeper simply skip over defaults since they have already been reviewed.
* Remove fallback clause that the changes in this PR correctly identified as unreachable.
* tidying up more.
* move some common functions to a new Core.Case.Util module.
* refer to case builder and case tree under new parent module.
* update imports to look for CaseTree in new submodule.
* update api ipkg
* remove unneeded application operators.
* remove or comment out unreachable default clauses caught by the changes in this PR.
* a bit of code documentation and renaming for clarity.
* bump previous version in CI.
* fix API usage of Util module.
* Add issue 1079 test cases.
* forgot to add new test cases file.
* remove commented-out lines by request of RefC author.
* Use a SortedSet instead of nubbing a list.
* update new case tree import.
* Update src/Core/Case/Util.idr
Co-authored-by: G. Allais <guillaume.allais@ens-lyon.org>
* remove function with nothing to offer above and beyond a differently named copy of the same code.
* replace a large tuple with a record; discover not all of the tuple's fields were needed.
* fix shadowing warning.
Co-authored-by: G. Allais <guillaume.allais@ens-lyon.org>
This is for compiled evaluation at compile-time, for full normalisation. You can try it by setting the evaluation mode to scheme (that is, :set eval scheme at the REPL). It's certainly an order of magnitude faster than the standard evaluator, based on my playing around with it, although still quite a bit slower than compilation for various reasons, including:
* It has to evaluate under binders, and therefore deal with blocked symbols
* It has to maintain enough information to be able to read back a Term from the evaluated scheme object, which means retaining things like types and other metadata
* We can't do a lot of the optimisations we'd do for runtime evaluation particularly setting things up so we don't need to do arity checking
Also added a new option evaltiming (set with :set evaltiming) to display how long evaluation itself takes, which is handy for checking performance.
I also don't think we should aim to replace the standard evaluator, in general, at least not for a while, because that will involve rewriting a lot of things and working out how to make it work as Call By Name (which is clearly possible, but fiddly).
Still, it's going to be interesting to experiment with it! I think it will be a good idea to use it for elaborator reflection and type providers when we eventually get around to implementing them.
Original commit details:
* Add ability to evaluate open terms via Scheme
Still lots of polish and more formal testing to do here before we can
use it in practice, but you can still use ':scheme <term>' at the REPL
to evaluate an expression by compiling to scheme then reading back the
result.
Also added 'evaltiming' option at the REPL, which, when set, displays
how long normalisaton takes (doesn't count resugaring, just the
normalisation step).
* Add scheme evaluation mode
Different when evaluating everything, vs only evaluating visible things.
We want the latter when type checking, the former at the REPL.
* Bring support.rkt up to date
A couple of missing things required for interfacing with scheme objects
* More Scheme readback machinery
We need these things in the next version so that the next-but-one
version can have a scheme evaluator!
* Add top level interface to scheme based normaliser
Also check it's available - currently chez only - and revert to the
default slow normaliser if it's not.
* Bring Context up to date with changes in main
* Now need Idris 0.5.0 to build
* Add SNF type for scheme values
This will allow us to incrementally evaluate under lambdas, which will
be useful for elaborator reflection and type providers.
* Add Quote for scheme evaluator
So, we can now get a weak head normal form, and evaluate the scope of
a binder when we have an argument to plug in, or just quote back the
whole thing.
* Add new 'scheme' evaluator mode at the REPL
Replacing the temporary 'TmpScheme', this is a better way to try out the
scheme based evaluator
* Fix name generation for new UN format
* Add scheme evaluator support to Racket
* Add another scheme eval test
With metavariables this time
* evaltiming now times execution too
This was handy for finding out the difference between the scheme based
evaluator and compilation. Compilation was something like 20 times
faster in my little test, so that'd be about 4-500 times faster than the
standard evaluator. Ouch!
* Fix whitespace errors
* Error handling when trying to evaluate Scheme
* Update version numbers and bootstrap scheme
* Use wall clock time for search timeouts
That was always the intention in any case, rather than the process time.
Instead of having UN & RF (& Hole in the near future & maybe even
more later e.g. operator names) we have a single UN constructor
that takes a UserName instead of a String.
UserName is (for now)
```idris
data UserName : Type where
Basic : String -> UserName -- default name constructor e.g. map
Field : String -> UserName -- field accessor e.g. .fst
Underscore : UserName -- no name e.g. _
```
This is extracted from the draft PR #1852 which is too big to easily
debug. Once this is working, I can go back to it.
* Move Context into its own file
Just the core definition - this is so that we have access to it in
Core.Core, for inclusion in error messages, to save normalisation of
terms in errors until we actually show them.
* Normalise errors on display, not when they arise
This can save a lot of time in ambiguity resolution if the errors are
complicated, because the errors might never be displayed if it's in an
abandoned branch.
This involves lifting 'Context' out of Core.Context, because we need to
store it in Error, which is needed by Core, which in turn is needed in
Core.Context.
Also moved a couple of test caes from ttimp to idris2, so that the
errors get rendered properly and won't need updating unnecessarily. In
fact all of the ttimp tests - which were just part of the initial
scaffolding - are probably now subsumed by the idris2 tests.
* Add new coverage001 test files
* Split Normalise into three files
Evaluation, Quoting, and Conversion checking are distinct steps, and I'm
about to add some variations to quoting so better to reorganise a bit.
* Add a Quote mode that limits size of result
Sometimes normalising an expression is a good idea because it makes
things smaler, and sometimes it isnt, because it doesn't. We can't tell
in advance which situation we're in, but we can try speculatively
normalising something. This is good for case types and hole types - we
generally want the normal form, but if that's expensive, we should stop.
So, quote is now able to give up if it passes a certain size threshold
for stuck applications. By experimentation, it seems that up to 10
doesn't hurt too much, but beyond that it's better not to normalise at
all.
* Add the new normalise files
* Stub for future 'identity' optimisation
I plan to add this later, but I'm using for now for
NaturalToInteger and IntegerToNatural
* Refactor `%builtin`
fixes#1799
- automatically optimise all Natural shaped things
- NaturalToInteger and IntegerToNatural now use
new `Identity` flag (internal use only for now)
which signals the function is identity at runtime
* Use NaturalToInteger and IntegerToNatural for Nat and Fin
Also define show fin in terms of finToInteger, for speed
* Fix name handling for %builtin
* [ tests ] fixes + #1799
* remove %builtin from libs
Add back after next version
* Use resolved names where convenient
To be able to modify `Data.IOArray` as proposed in #1677.
Currently `Data.IOArray` cannot be modified because compiler need
to be built with previous compiler. This PR removes compiler
dependency on `Data.IOArray`.
If all branches in a case block are a lambda, lift the lambda out. In
many cases, this can save creating a closure then evaluating it
immediately, because the function is already applied to the extra
argument.
This happens in particular with IO based code, where the extra argument
is the world token. One place where this transformation has a big effect
is 'evalRef' so the evaluator is now a bit faster (about 20% on the
small benchmark I tried it on - but no guarantees that's going to happen
on other examples!)
Now reporting an error if we can't find a package that satisfies the
constraints. The version number field can still be a string (as it used
to be) but will give a deprecation warning - and the old style version
string wasn't used anyway.
Version constraints can have an upper and/or lower bound, which can be
inclusive or not.
Until yesterday I did not know Idris2 accesses environment variables.
Mentioning them in `--help` would educate other users.
Not all descriptions make sense, I tried my best to guess them.
Output is: [link](https://gist.github.com/stepancheg/7d1dff344a0dd35b9d07fb4a417ecb32).
