| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
| |
As we perform type-checking earlier we'll delete these checks. But start
with type-checking at run-time.
|
| |
|
|
| |
Making life too complex at this time.
|
| |
|
|
| |
Bah, sick of CALL and continuations.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Make it easy to skip distracting valgrind errors when debugging more
obvious errors in early layers. Just throw a 'test' at the end of
build_and_test_until commands to not run valgrind (and make it a regular
test run).
|
| |
|
|
|
| |
Now we always consider words to be terminated at () and {}.
We also always skip commas.
|
| | |
|
| |
|
|
| |
Still trying to come up with clean lexing rules.
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were several places where we push a call on to a routine without
incrementing call-stack depth, which was used to compute the depth at
which to trace an instruction. So sometimes you ended up one depth lower
than you started a call with. Do this enough times and instructions that
should be traced at level 100 end up at level 0 and pop up as errors.
Solution: since call-stack depth is only used for tracing, include it in
the trace stream and make sure we reset it along with the trace stream.
Then catch all places where we forget to increment call-stack depth and
make sure we catch such places in the future.
When I first ran into this with Caleb I thought there must be some way
that we're writing some output into the warnings result. I didn't
recognize that the spurious output as part of the trace, just at the
wrong level.
|
| |
|
|
| |
Thanks Caleb Couch.
|
| |
|
|
| |
Another bugfix. Thanks Jack and Caleb Couch.
|
| |
|
|
|
| |
We still can't have decent tests in this variant.
Thanks Jack and Caleb Couch.
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
Thanks Caleb Couch.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I can't easily use generic containers without needing some syntax for
generic recipes:
push:number a:number, l:list:number
which would be implemented as:
T <- next-type
a:T <- next-ingredient
etc.
Another concern: how to represent map<string, list<number>>?
map::address:array:character::list:number
where the '::' is just silently turned into ':'.
Agh, all this is so baroque. All this while I've been trying to avoid
getting into language design. All I want is some lightweight way to
avoid security holes and memory corruption. But now it seems like I need
facets to control compile-time activities and so on.
|
| |
|
|
|
|
| |
Unbelievable that this hitherto-unanticipated test passed so easily.
Even though I'm simply bolting on special cases in an ad hoc manner,
this isn't too shabby.
|
| | |
|
| |
|
|
|
| |
*Extremely* ugly. I need to use better variable names around new
waypoints.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|