| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
When skipping past some text (usually whitespace, but also commas and
comments) I need to always be aware of whether it's ok to switch to the
next line or not.
|
| |
|
|
|
|
| |
Another gotcha uncovered in the process of sorting out the previous
commit: I keep using eof() but forgetting that there are two other
states an istream can get into. Just never use eof().
|
| |
|
|
|
|
|
| |
I ran into this when edit/ couldn't handle spaces after curly brackets,
even though .mu files could. Turns out edit/ loads code using
istringstreams rather than ifstreams, and you can't putback a different
character than you read from an istringstream. Craptastic gotcha..
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now dilated reagent parsing is much simpler.
We still can't parse nested hashes. We may never need that. For now the
syntax model is:
program = collection of top levels
top-level contains a list of lines
lines may be instructions
instructions have reagents
reagents can be in compressed or dilated syntax (or literal strings)
property values inside reagents can be s-expression trees
We balance {} inside top-levels, [] inside strings, and () inside
property values.
|
| | |
|
| | |
|
| |
|
|
|
| |
Switch format for tracing reagents in preparation for trees rather than
arrays of properties.
|
| | |
|
| | |
|
| | |
|
|
|
Current plan:
parsing {x: foo, y: bar} syntax for reagents
parsing s-expr syntax for properties
supporting reverse instructions (<-)
parsing s-expr syntax for recipe headers (recipe number number -> number)
static dispatch
generic functions
type-checking higher-order functions
type of delimited continuations? need more type information
First step is done, and the second partially so.
|