The bigger problem is that because blocks are implemented as closures, using a block in a while loop will (eventually) cause a stack overflow. There are a few ways around that, the most natural to this design being implementation of Tail Call Optimization. Except tail call optimization can only be done when I know the closure call is in tail position. And since conditionals are done in-language, the compiler can't tell. I asked a question on stack exchange about it and... did not get help really. The academics don't care about the implementation and the pragmatists don't care about the theory.
Oh, and the error reporting is horrific and there are no debugging symbols yet. Sorry.
Anyways, here is the test program for milestone 1 - basic booleans, if statements and while loops - all defined in-language with only enum declaration, function declaration, void/unit-type, specialization and closures built into the language itself:
bool :> enum { true, false } if (condition: bool) (positive: ~>void) => void { } if (condition: bool) (positive: ~>void) else (negative: ~>void) => void { negative; } if (condition: bool.true) (positive: ~>void) => void { positive; } if (condition: bool.true) (positive: ~>void) else (negative: ~>void) => void { positive; } (lhs: bool) equals (rhs: bool) => bool { return false; } (lhs: bool.true) equals (rhs: bool.true) => bool { return true; } (lhs: bool.false) equals (rhs: bool.false) => bool { return true; } while (condition: ~>bool) (body: ~>void) => void { if condition { body; while condition body; }; } entrypoint => void { while true equals true print "."; }Which in turn compiles to CIL (yes, CIL lets you define functions with spaces in the name):
I'm not sure what the next steps will be quite yet. I expect it will be implementing ints with proper order of operations in-language. Depending on the approach, I may first move this stuff into built-ins to help improve performance and structure of the built code. I also might get distracted by the lack of general equality and push generics in to support that, or some fancy ill-conceived idea like usual.
But keeping things simple has worked fairly well so far (and cs.stackexchange less so). A good lesson to remember.
No comments:
Post a Comment