billhails / cekf Goto Github PK

• 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.

see MACROS for initial ideas

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

#(a, b) = somefunc();

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.

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

best left until after #84

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.

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

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.

As with Haskell, (2+) etc.

should be like print but then exits.

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

• 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.

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.

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

NaN etc.