I've been saying for a while[1][2][3] that adding extra abstractions makes
things harder for newcomers, and adding new notations doubly so. And then
I notice this DSL in my own backyard. Makes me feel like a hypocrite.
[1] https://news.ycombinator.com/item?id=13565743#13570092
[2] https://lobste.rs/s/to8wpr/configuration_files_are_canary_warning
[3] https://lobste.rs/s/mdmcdi/little_languages_by_jon_bentley_1986#c_3miuf2
The implementation of the DSL was also highly hacky:
a) It was happening in the tangle/ tool, but was utterly unrelated to tangling
layers.
b) There were several persnickety constraints on the different kinds of
lines and the specific order they were expected in. I kept finding bugs
where the translator would silently do the wrong thing. Or the error messages
sucked, and readers may be stuck looking at the generated code to figure
out what happened. Fixing error messages would require a lot more code,
which is one of my arguments against DSLs in the first place: they may
be easy to implement, but they're hard to design to go with the grain of
the underlying platform. They require lots of iteration. Is that effort
worth prioritizing in this project?
On the other hand, the DSL did make at least some readers' life easier,
the ones who weren't immediately put off by having to learn a strange syntax.
There were fewer quotes to parse, fewer backslash escapes.
Anyway, since there are also people who dislike having to put up with strange
syntaxes, we'll call that consideration a wash and tear this DSL out.
---
This commit was sheer drudgery. Hopefully it won't need to be redone with
a new DSL because I grow sick of backslashes.
I've extracted it into a separate binary, independent of my Mu prototype.
I also cleaned up my tracing layer to be a little nicer. Major improvements:
- Realized that incremental tracing really ought to be the default.
And to minimize printing traces to screen.
- Finally figured out how to combine layers and call stack frames in a
single dimension of depth. The answer: optimize for the experience of
`browse_trace`. Instructions occupy a range of depths based on their call
stack frame, and minor details of an instruction lie one level deeper
in each case.
Other than that, I spent some time adjusting levels everywhere to make
`browse_trace` useful.
Generalize commit 4089 to arbitrary closures, and not just the current
'space' or call frame. Now we should be treating spaces just like any
other data structure, and reclaiming all addresses inside them when we
need to.
The cost: all spaces must now specify what recipe generated them (so
they know how to interpret the array of locations) using the /names
property.
We can probably make this ergonomic with a little 'type inference'. But
at least things are safe now.
There seems to be some chance of speed-up when I inline these functions.
However, it's not a clear enough signal to justify improving the `build`
script to handle the `inline` keyword.
Current timing experiments:
Before After
ubuntu 1GB 9:22,8:48,8:51,9:16,9:17,8:36,9:05 8:55,8:41,8:15,8:27,8:29,8:54,9:29
OS X 8GB 4:05,4:00,4:18,4:09,3:40,3:51,3:56 3:58,3:52,4:01,4:13,4:16,4:31,4:13
It's always confusing when `break` refers to a `switch` but `continue`
refers to the loop around the `switch`. But we've done ugly things like
this and `goto` for expedience. However, we're starting to run into cases
where we now need to insert code at every `continue` or `continue`-mimicking
`goto` inside the core interpreter loop. Better to make the loop single-entry-single-exit.
Common things to run after every instruction will now happen inside the
`finish_instruction` function rather than at the `finish_instruction` label.
Always show instruction before any transforms in error messages.
This is likely going to make some errors unclear because they *need* to
show the original instruction. But if we don't have tests for those
situations did they ever really work?
Kartik Agaram
Stephen Malina