| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop requiring jump instructions to explicitly provide a ':label' type
for jump targets.
This has been a source of repeated confusion for my students:
a) They'd add the ':label' to the label definition rather than the
jump target (label use)
b) They'd spend time thinking about whether the initial '+' prefix was
part of the label name.
In the process I cleaned up a couple of things:
- the space of names is more cleanly partitioned into labels and
non-labels (clarifying that '_' and '-' are non-label prefixes)
- you can't use label names as regular variables anymore
- you can infer the type of a label just from its name
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
More consistent definitions for jump targets and waypoints.
1. A label is a word starting with something other than a letter or
digit or '$'.
2. A waypoint is a label that starts with '<' and ends with '>'. It has
no restrictions. A recipe can define any number of waypoints, and
recipes can have duplicate waypoints.
3. The special labels '{' and '}' can also be duplicated any number of
times in a recipe. The only constraint on them is that they have to
balance in any recipe. Every '{' must be followed by a matching '}'.
4. All other labels are 'jump targets'. You can't have duplicate jump
targets in a recipe; that would make jumps ambiguous.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Always check if next_word() returned an empty string (if it hit eof).
Thanks Rebecca Allard for running into a crash when a .mu file ends with
'{' (without a following newline).
Open question: how to express the constraint that next_word() should
always check if its result is empty? Can *any* type system do that?!
Even the usual constraint that we must use a result isn't iron-clad: you
could save the result in a variable but then ignore it. Unless you go to
Go's extraordinary lengths of considering any dead code an error.
|
| | |
|
| |
|
|
| |
Bugfix for the "remaining bug" mentioned in commit 3391.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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..
|
| | |
|
| |
|
|
|
|
| |
Long-overdue reorganization to support general 'dilated' reagents up
front. This also allows me to move tests that are really about unrelated
layers out of layers dealing with parsing.
|
| |
|
|
|
|
| |
All code to be tangled at a label should be defined between two calls to
transform_all(). This property is trivially satisfied if a production
run only ever has one call to transform_all().
|
| | |
|
| |
|
|
| |
This should eradicate the issue of 2771.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Delete all the [] that has crept in since 2377 in November.
|
| |
|
|
|
|
|
| |
Start using type names from the type tree rather than the property tree
in most places. Hopefully the only occurrences of
'properties.at(0).second' left are ones where we're managing it. Next we
can stop writing to it.
|
| | |
|
| | |
|
| |
|
|
|
| |
Some more structure to transforms, and flattening of dependencies
between them.
|
| |
|
|
|
| |
I'd not paid any attention to it so far, but I need to do so from now
on.
|
| |
|
|
|
|
|
| |
Commands run:
$ sed -i 's/\([^. (]*\)\.find(\([^)]*\)) != [^.]*\.end()/contains_key(\1, \2)/g' 0[^0]*cc
$ sed -i 's/\([^. (]*\)\.find(\([^)]*\)) == [^.]*\.end()/!contains_key(\1, \2)/g' 0[^0]*cc
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm still seeing all sorts of failures in turning on layer 11 of edit/,
so I'm backing away and nailing down every culprit I run into. First up:
stop accidentally inserting empty objects into maps during lookups.
Commands run:
$ sed -i 's/\(Recipe_ordinal\|Recipe\|Type_ordinal\|Type\|Memory\)\[\([^]]*\)\] = \(.*\);/put(\1, \2, \3);/' 0[1-9]*
$ vi 075scenario_console.cc # manually fix up Memory[Memory[CONSOLE]]
$ sed -i 's/\(Memory\)\[\([^]]*\)\]/get_or_insert(\1, \2)/' 0[1-9]*
$ sed -i 's/\(Recipe_ordinal\|Type_ordinal\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]*
$ sed -i 's/\(Recipe\|Type\)\[\([^]]*\)\]/get(\1, \2)/' 0[1-9]*
Now mu dies pretty quickly because of all the places I try to lookup a
missing value.
|
| |
|
|
|
|
|
|
|
| |
More flailing around trying to come up with the right phase ordering.
I've tried to narrow down each transform's constraints wrt transforms in
previous layers.
One issue that keeps biting me is the Type map containing empty records
because of stray [] operations. That's gotta be important.
|
| |
|
|
|
|
|
| |
A new externality is starting to make its presence felt.
Until I sort this out it's going to be hard to finish making duplex-list
generic.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Once a student has gotten used to recipes and ingredients using the
staged 'next-ingredient' approach there's no reason to avoid
conventional function headers. As an added bonus we can now:
a) check that all 'reply' instructions in a recipe are consistent
b) deduce what to reply without needing to say so everytime
c) start thinking about type parameters for recipes (generic functions!)
|
| | |
|
| |
|
|
|
|
|
| |
At the lowest level I'm reluctantly starting to see the need for errors
that stop the program in its tracks. Only way to avoid memory corruption
and security issues. But beyond that core I still want to be as lenient
as possible at higher levels of abstraction.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This seemingly simple goal uncovered a little nest of bugs: it turns out
I've been awash in ambiguous labels until now. My baseline recipes in
edit.mu were clean, but they introduced duplicate <waypoints> -- and
*those* waypoints contained +jump-targets. Result: duplicate jump
targets, so that I wasn't jumping where I thought I was jumping. Somehow
I happened to be picking one of the alternatives that magically kept
these issues quiescent.
My first plan to fix this was to mangle names of all labels inside
before/after fragments, keep the jump targets private to their fragment.
But the labels also include more waypoints! Mangle those, and I can't
tangle to them anymore.
Solution: harden the convention that jump targets begin with '+' and
waypoints are surrounded by '<>'. Mangle jump targets occurring inside
before/after fragments to keep them private to their lexical fragment,
but *don't* mangle waypoints, which must remain globally accessible.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Finally terminate the experiment of keeping debug prints around. I'm
also going to give up on maintaining counts.
What we really need is two kinds of tracing:
a) For tests, just the domain-specific facts, organized by labels.
b) For debugging, just transient dumps to stdout.
b) only works if stdout is clean by default.
Hmm, I think this means 'stash' should be the transient kind of trace.
|
| |
|
|
|
|
| |
Turns out it is indeed useful to insert code at multiple duplicate
labels within a single (long) recipe. Like handle-keyboard-event in
edit.mu.
|
| |
|
|
| |
However, you can't have duplicate labels within a single recipe.
|
| | |
|
| |
|