I've been working on this slowly over several weeks, but it's too hard
to support 0 as the null value for addresses. I constantly have to add
exceptions for scalar value corresponding to an address type (now
occupying 2 locations). The final straw is the test for 'reload':
x:num <- reload text
'reload' returns an address. But there's no way to know that for
arbitrary instructions.
New plan: let's put this off for a bit and first create support for
literals. Then use 'null' instead of '0' for addresses everywhere. Then
it'll be easy to just change what 'null' means.
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?
Be more disciplined about tagging 2 different concepts in the codebase:
a) Use the phrase "later layers" to highlight places where a layer
doesn't have the simplest possible self-contained implementation.
b) Use the word "hook" to point out functions that exist purely to
provide waypoints for extension by future layers.
Since both these only make sense in the pre-tangled representation of
the codebase, using '//:' and '#:' comments to get them stripped out of
tangled output.
(Though '#:' comments still make it to tangled output at the moment.
Let's see if we use it enough to be worth supporting. Scenarios are
pretty unreadable in tangled output anyway.)
Standardize quotes around reagents in error messages.
I'm still sure there's issues. For example, the messages when
type-checking 'copy'. I'm not putting quotes around them because in
layer 60 I end up creating dilated reagents, and then it's a bit much to
have quotes and (two kinds of) brackets. But I'm sure I'm doing that
somewhere..
I'm dropping all mention of 'recipe' terminology from the Readme. That
way I hope to avoid further bike-shedding discussions while I very
slowly decide on the right terminology with my students.
I could be smarter in my error messages and use 'recipe' when code uses
it and 'function' otherwise. But what about other words like ingredient?
It would all add complexity that I'm not yet sure is worthwhile. But I
do want separate experiences for veteran programmers reading about Mu on
github and for people learning programming using Mu.
All my attempts at staging this change failed with this humongous commit
that took all day and involved debugging three monstrous bugs. Two of
the bugs had to do with forgetting to check the type name in the
implementation of shape-shifting recipes. Bug #2 in particular would
cause core tests in layer 59 to fail -- only when I loaded up edit/! It
got me to just hack directly on mu.cc until I figured out the cause
(snapshot saved in mu.cc.modified). The problem turned out to be that I
accidentally saved a type ingredient in the Type table during
specialization. Now I know that that can be very bad.
I've checked the traces for any stray type numbers (rather than names).
I also found what might be a bug from last November (labeled TODO), but
we'll verify after this commit.
We don't yet actually maintain the refcount. That's next.
Hardest part of this was debugging the assume-console scenarios in layer
85. That took some detailed manual diffing of traces (because the output
of diff was no good).
New tracing added in this commit add 8% to .traces LoC. Commented out
trace() calls (used during debugging) make that 45%.
This is the one major refinement on the C programming model I'm planning
to introduce in mu. Instead of Rust's menagerie of pointer types and
static checking, I want to introduce just one new type, and use it to
perform ref-counting at runtime.
So far all we're doing is updating new's interface. The actual
ref-counting implementation is next.
One implication: I might sometimes need duplicate implementations for a
recipe with allocated vs vanilla addresses of the same type. So far it
seems I can get away with just always passing in allocated addresses;
the situations when you want to pass an unallocated address to a recipe
should be few and far between.
I added one test to check that divide can return a float, then hacked at
the rippling failures across the entire entire codebase until all tests
pass. Now I need to look at the changes I made and see if there's a
system to them, identify other places that I missed, and figure out the
best way to cover all cases. I also need to show real rather than
encoded values in the traces, but I can't use value() inside reagent
methods because of the name clash with the member variable. So let's
take a snapshot before we attempt any refactoring. This was non-trivial
to get right.
Even if I convince myself that I've gotten it right, I might back this
all out if I can't easily *persuade others* that I've gotten it right.
All primitives now always write to all their products. If a product is
not used that's fine, but if an instruction seems to expect too many
products mu will complain.
In the process, many primitives can operate on more than two ingredients
where it seems intuitive. You can add or divide more than two numbers
together, copy or negate multiple corresponding locations, etc.
There's one remaining bit of ugliness. Some instructions like
get/get-address, index/index-address, wait-for-location, these can
unnecessarily load values from memory when they don't need to.
Useful vim commands:
%s/ingredients\[\([^\]]*\)\]/ingredients.at(\1)/gc
%s/products\[\([^\]]*\)\]/products.at(\1)/gc
.,$s/\[\(.\)]/.at(\1)/gc
Kartik Agaram