Throw & Catch

I didn't implement exceptions right, yet. Throws and catches are factored out but catches catch the exception local in the term. I looked at call-cc and reset-shift, couldn't decide, and, once again, I am going for my own most straightforward implementation described below.

A ((try E₀ catch E₁) exc) block is roughly translated to (R (λs. E₀ (λx.s (E₁ x))))  which evaluates to ((λs. E₀ (λx. s (E₁ x))) S_k) , where S_k is a control object holding the continuation of the original block. It looks the most like reset-shift I guess. The difference is that, as far as I know, reset-shift is a syntactical addition to lambda calculus, whereas these combinators model roughly the same, but depend on call-by-value evaluation to express a control operator which you can't model directly syntactically using common combinators.

R takes a function f and rewrites to f S_k. S_k takes a value v and rewrites to v, but escapes the local context up to the point R was applied.

I didn't implement it yet. Worried a bit about the shift combinator escaping the local context.

013110: Convinced myself, and implemented it. Since the try part of a try-catch can only evaluate to a value or an exception, the exception handler is either applied, or not, so should be properly discarded.

Food is a nice idea sometimes too.

Combinators, Calls and FFI

I threw away too much code to arrive at something in which I was unable to express certain basic functionality. The good thing was that it cleaned up some badly thought trough lines. I ended up with some small changes in the runtime, and again, I find myself writing some lines to throw away other lines. Write-off: learning.

012610: I added marshalling code, it uses a recursive C routine and probably needs a terabyte memory, but... its there. I could always zip of course. Unmarshalling not there yet. Added a symbol table with linear lookup. Last Optimize?

The only women I love: Amy Winehouse.

Symbol Tables...

Right, you think you can do without, but you can't. If I (un-)marshal code, I need a manner of binding thunks to C functions. So, a symbol table, or I compile a program to a DLL, and abuse the fact that I can reflect on that.

Serious introspection.

Position Based Parsing

I took a one-week trip into QM land, which ended, took a fresh look at my position based parser combinators, and saw that I am going at it the wrong way. A beginners error, if you thread positions along, which you need in position based parsing, it also needs to be returned.

In need of steam.

Open Source...

I gave it some thought. Preferably, I'll go the following route: close source with a few people, and then open source, or half license, it. Then see where it'll stick.

Earliest Deadline Gone to ReST

Its can-read-but-cannot-write time again, unfortunately. The bootstrap compiler should run, but misses marshalling primitives in C. An object file is nothing more than a marshalled simplified AST which passed all semantic checks, so those primitives should be added to arrive at a full bootstrap compiler.

I read a new ParaSail post on tasks, which basically gives an overview of scheduling terminology. I am looking at mutlithreading too. In my case, designing given the current runtime boils down to choosing between alternatives which I can expect give reasonable performance. So I am looking at how to handle memory, what to do explicit and implicit, and how to combine FFI and the environment - possibly combine low-level task primitives with marshalling code.

There is a simple scheme I think will work out nicely, but has two drawbacks, 1) explicit management of memory, and 2) some need for synchronization beyond what I like, or rather, how to implement a join, or signals.  I'll do something simplistic on which I expect different solutions can be build, EDF scheduling is a bit too much at this point, but should be implementable given what I am aiming for.

Needed some rest, so writing on the ReST parser - see if I can get the bootstrap to output documentation before a complete self compile.


011210: Cleaning up again, writing some position based parser combinators. Ugly and slow but sufficient. I don't extract blocks from the source, but the penalty is a large number of redundant positional checks. I should get my hands on: S. Doaitse Swierstra and Pablo R. Azero Alcocer, Fast, Error Correcting Parser Combinators: A Short Tutorial. In Lecture Notes in Computer Science, SOFSEM’99: Theory and Practice of Informatics, volume 1725/2009, page 763. Friday, January 01, 1999. Nice-to-have for the Hi grammar parser I guess.

Back

I had a slow week I guess, looking at code. Bug must be somewhere between eta-expansion and combinator lifting. Must be in the partial evaluator, some sloppy substitution...

011110: What a date! Removed the bug in alpha-conversion, a forgotten one-liner actually. At a pace of one bug a week, I better not have too many. The program print (10, false, "hello world!") now works, which means Currying, method calls, FFI largely works.

All programs have at least one  superfluous instruction and at least one bug. Therefore, it follows by induction that every program can be reduced to one flawed instruction.