| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>.
|
| | |
|
| |
|
|
|
| |
Still seeing repeated null refinements. Maybe my approach to fixing
those errors is fundamentally broken.
|
| | |
|
| |
|
|
|
| |
Introducing a new 'newlayer' tag like 'todo', to record places where a
nascent new layer might be starting to bud off.
|
| |
|
|
| |
Now we can collect all traces, just modulating the depth.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Already I'm finding type errors in the programming environment.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
How the heck was this working until now?
There must be redundant moves. And was I clobbering test data?
|
| |
|
|
| |
Thanks Jack and Caleb Couch for the idea.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Layer 2 provides an almost fully functioning interactive editor:
$ ./mu edit/00[12]* -- abcdef
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Starting on making the basic programming environment oblivious to
warnings. That should come later.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|