(Which was commented out anyway)
Three scheme back ends is enough to maintain, and Gambit does the same
job as chicken (fast startup of the interpreter, generating via C) but
seems to deal with the code Idris generates better.
This more or less follows the rules from ICFP '10 "Scrapping your
inefficient engine" in that it generates new partially evaluated
definitions by evaluating with the statically known arguments, and
caches the results so that they can be reused if the evaluator
encounters them again. Some polish is still needed:
- proper tests
- nice display of residual programs (which will help with proper tests!)
- sensible handling of partial functions (probably a small limit on how
much to evaluate, and fail on encountering it?)
- checking whether evaluation has made progress, and failing if not
Once the above works, we're in a position to start specialising
interfaces, which is the main point of this.
Useful in partial evaluation, because if we erase the inferrable
arguments in an argument to a partially evaluated definition, we can
make something more general. It might also be useful in interactive
editing later, to decide what to display.
Flag definitions as partial evaluation definitions, in which case the
RHS gets evaluated under certain limits (not yet defined...), pausing at
any new specialisable calls to recursively specialise.
Still to do: set appropriate reduction limits depending on
partiality/totality of functions concerned, and introduce transformation
rules for rewriting by already known and cached specialisations.
Generate the initial definition of a specialised function, by applying
the function to its static arguments.
Next step: evaluate the RHS on elaboration.
This isn't strictly right yet (there should be no newline on the last
lie if there was no newline in the input file) but it puts the behaviour
back to what it was before fGetLine was changed to discard it.
This needs revisiting...
