- I simplified the type checker to a prover using solely antecedents and consequents. Both are stored in a list, giving quadratic behavior. It should become O(n x log(n)) here.
- In order to avoid quadratic, or worse, behavior I tried to avoid alpha conversion on lambda terms during substitution. There have been/are too many bugs because of that. Should solve this.
- I don't inline yet. I should do this at some point.
- The method invocations are compiled down to combinators. Case statements are a linear collection of tests, that means linear behavior on lookups. Not sure this is a problem actually.
- Everything not essential graph rewriting is done through FFI (libffi) where all functions are loaded from dynamic libraries (libdl). Every FFI call is evaluated each time. FFI is slow already, I could/should add memoization here.
- FFI calls are dynamic in nature leading to runtime failures when types are not matched. Should look into swig to automate the glue.
- I should allow unary arguments to FFI, now it is assumed all FFI symbols refer to functions.
- I wonder how combinators will work out long-time. There might be just too much copying - should think over how spurious copying can be avoided.
- I need serialization. This should be simple and obvious if all data is treated as trees.
- I started on a simple ReST parser for documentation which I intend to be part of the compiler.
- I should prove the type system correct?
Sunday, December 20, 2009
After a number of changes, some small, some large, the to ml compiled compiler accepts its own system file again. It also cleanly compiles simple programs to C (fac, list manipulations). Various thoughts: