I was failing to specialize calls containing literals. And then I had to
deal with whether literals should map to numbers or characters. (Answer:
both.)
One of the issues that still remains: shape-shifting recipes can't be
called with literals for addresses, even if it's 0.
If a name repeats between ingredients, we raise an error.
If a name repeats across ingredients and products, every call should
share the same name across the corresponding ingredients and products.
And it caught a bug: I mean to always update type names and types in
sync.
The last month or so I've been getting reluctantly but inexorably
converted to the need and value of a type system. First I thought I just
need a minimal but rigorous type system to avoid memory corruption and
security issues. Now I think I also want it to be expressive enough to
be able to express what data different phases in a compiler read and
write, and to be able to designate specific fields as 'fully computed'
so that we can statically check that phases wait until their data is
available.
The phase-ordering problem in a compiler is perhaps the canary in the
coal-mine for a more general problem: even small changes can
dramatically explode the state space if they violate assumptions
previously held about the domain. My understanding of when type pointers
are null and not null is immeasurably more nuanced today than it was a
week ago, but I didn't need the nuance until I introduced generic
functions. That initial draft of a hundred lines bumped me up to a much
larger state space. How to make it more obvious when something happens
that is akin to discovering a new continent, or finding oneself
teleported to Jupiter?
Assumptions can be implicit or explicit. Perhaps a delete of an
assertion should be estimated at 1000 LoC of complexity?
One nice consequence of all my deduction of reply ingredients is that I
can insert the same fragment into recipes with different headers, and
everything works as long as reply instructions are implicitly deduced.
One thing I had to fix to make this work was to move reply-deduction out
of rewrite rules and turn it into a first-class transform, so that it
happens after tangling.
I'm glad to see the back of that hack inside <scroll-down>.
We still can't check ingredient types, and even this is still a run-time
check. We'll need to start tracking recipe signatures at some point.
I've had to introduce a hack called /skiptypecheck. Time to get generics
working.
Always show recipe name where error occurred. But don't show internal
'interactive' name for sandboxes, that's just confusing.
What started out as warnings are now ossifying into errors that halt all
execution. Is this how things went with C and Unix as well?
Front-loads it a bit more than I'd like, but the payoff is that other
recipes will now be able to describe the type checks right next to their
operation.
I'm also introducing a new use of /raw with literals to indicate unsafe
typecasts.
Takes the text to render inside the editor on the commandline:
$ ./mu edit/001-editor.mu -- abcdef
Layer 1 has no interactivity. Just shows the text you pass in on the
commandline, wrapping as you would expect. Press any key to exit.
`render-string` (and `render-code-string`; ugh) should start a new line
after, not before, like everybody else.
I've been meaning to fix this for a long time, but now I have to, to
move the warnings fields out of early layers.
To run just until say layer 6, say this:
$ ./mu test edit/00[0-6]*
The layers are not perfect yet; there might be a few things (like the
warning fields) that need to move to a later layer.
Now you can bring up the programming environment by saying:
$ mu edit
The files under edit aren't yet *layers*, though, they have a few
dependencies that we need to clean up.
Kartik K. Agaram