| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Now duplex-list is fully non-generic and only works with characters. But
we'll fix that in a bit..
|
| |
|
|
|
|
| |
With our new type checks it's no longer possible to expand traces
generated directly in the sandbox. So now there's yet another test that
we can't run in the sandbox/ app. Yet.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Already I'm finding type errors in the programming environment.
|
| |
|
|
| |
This came last because we had to ensure all primitives are covered.
|
| | |
|
| | |
|
| | |
|
| | |
|