They uncovered one bug: in edit/003-shortcuts.mu
<scroll-down> was returning 0 for an address in one place where I
thought it was returning 0 for a boolean.
Now we've eliminated this bad interaction between tangling and punning
literals.
Pretty klunky; we're violating the type system by prepending an extra result,
so functions we want to catch exceptions around have to be header-less
and check input types at run-time.
I have a plan for a way to avoid use-after-free errors without all the
overheads of maintaining refcounts. Has the nice side-effect of
requiring manual memory management. The Mu way is to leak memory by
default and build tools to help decide when and where to expend effort
plugging memory leaks. Arguably programs should be distributed with
summaries of their resource use characteristics.
Eliminating refcount maintenance reduces time to run tests by 30% for
`mu edit`:
this commit parent
mu test: 3.9s 4.5s
mu test edit: 2:38 3:48
Open questions:
- making reclamation easier; some sort of support for destructors
- reclaiming local scopes (which are allocated on the heap)
- should we support automatically reclaiming allocations inside them?
Simplify the implementation of calling continuations. Since we don't
support next-ingredient on continuations, might as well not bother with
all that call housekeeping for ingredients.
Bugfix: I hadn't been allowing continuations to be copied.
Deepens our initial sin of managing the Mu call stack implicitly in the
C interpreter. Since the call stack was implicit, continuations had to
be implicit as well. Since continuations aren't in Mu's memory, we have
to replicate refcounting logic for them.
Surprisingly small change, considering how long it took me and how
mind-bending it was. 'return-continuation-until-mark' now behaves like
both call and return instructions, which made it hard to reason about.
They're back after a long hiatus: commit 2295 in Oct 2015.
I'm not convinced anymore that this is actually a correct implementation
of continuations. Issues on at least two fronts:
a) These aren't safe yet. Since continuations can be called multiple
times, we need to disable reclamation of locals inside a continuation.
There may be other type- or memory-safety issues. However, delimited
continuations at least seem possible to make safe. Undelimited
continuations (call/cc) though are permanently out.
b) They may not actually be as powerful as delimited continuations.
Let's see if I can build 'yield' out of these primitives.
Kartik Agaram