billhails/cekf

Low level (C) implementation of a CEK machine with an additional "F" failure continuation supporting amb

cekf's Issues

Improve Arithmetic

• General overhaul.
• move to libgmp?
• trig functions.
• Pre-compute constant values at compile time.
• allow numeric (not symbolic) arithmetic expressions in patterns.
• allow unpacking of numerator and denominator variables in patterns.
  • special case: a / b because there is a canonical form (via gcd).
  • match would fail if the actual argument is not integer or rational.
  • b would be bound to 1 if the argument was an integer.
  • can't allow arbitrary ops and combinations because i.e. (a + 2) * b
    can't uniquely determine a and b, and a ** 2 would require a
    to be bound to the square root of the actual argument.
• allow unpacking of the real and imaginary parts of a complex number in patterns.
  • another special case: a + b, b would be bound to 0i if the actual
    argument is not complex.

overhaul runtime stack manipulation

depends on #83

• Probably first do some profiling to verify that performance is hampered by all of the stack copying that goes on when reinstating continuations etc. I can't see how it isn't though.
• Investigate options for only, or mostly only, manipulating pointers to stacks instead. call/cc will complicate this of course, because continuations are re-usable.

Much better error reporting

some progress already made with the ParserInfo struct but cant_happen is being used everywhere for conditions that are just errors in the input.

Fail on detecting a non-exhaustive pattern match

This will need to be at least opt-out, maybe some special comment or directive to tell the TPMC to allow them for specific functions.

error function

should be like print but then exits.

Curried binary operators

As with Haskell, (2+) etc.

Aliases

alias string = list(char) is the main driver.

Replace the CEKFs support code with generated code

The run-time engine of this project is some of the earliest code, and the tooling for code generation wasn't there at that time. Now the code-generation is more mature it would be good to replace all that hand-written boilerplate with generated code, reducing the maintenance overhead and gaining access to extra features that the CG provides.

UTF8 and `wchar_t`

• Would play nicely with strings being lists of char.
• Store the Unicode code points internally.
• Combining characters need special handling.

Macro support

see MACROS for initial ideas

overhaul ANF conversion

The ANF conversion code is messy and potentially has bugs, which are likely adding unnecessary let bindings which will significantly slow down the run-time. The current plan is to write the ANF conversion in F Natural itself, then convert that to C. Problem is that the ANF examples to hand are written in scheme using CPS, making conversion from F Natural to C non-trivial.

More numbers

NaN etc.

User defined operators

• With precedence and associativity.
• infix 55 left >>= fn(l, r) { ... }
• prefix 45 $ fn(a) { ... }
• suffix 60 ! factorial

The main thing to figure out is scoping, it should be relatively easy to add these to a parser but they may also need to be removed when they go out of scope.

Unpacking function return values

Tuples only, a tuple returned from a function should be directly unpackable without requiring a switch, i.e.

#(a, b) = somefunc();

Over-application

i.e. fn (a) { fn (b) { a + b } }(2, 3)

best left until after #84