about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 2304Kartik K. Agaram2015-10-281-2/+2
| | | | | I no longer have any null types! That raises confidence that I'm on the right track.
* 2302 - restarting test_all_layers from a layerKartik K. Agaram2015-10-281-0/+1
|
* 2301 - test_all_layers fixesKartik K. Agaram2015-10-283-11/+11
|
* 2300 - remove callcc.mu from docs until it returnsKartik K. Agaram2015-10-282-54/+0
|
* 2299 - check types of ingredients in callsKartik K. Agaram2015-10-2812-64/+108
| | | | | | | | | | Still very incomplete: a) we perform the check at runtime b) tests for edit and sandbox apps no longer work; we can't fix them until we get type parameters in both containers and recipes (because list and list operations need to become generic).
* 2298Kartik K. Agaram2015-10-281-1/+1
|
* 2297Kartik K. Agaram2015-10-286-22/+27
|
* 2296 - record ingredient types on call stackKartik K. Agaram2015-10-282-0/+3
| | | | | As we perform type-checking earlier we'll delete these checks. But start with type-checking at run-time.
* 2295 - drop first-class recipes and continuationsKartik K. Agaram2015-10-287-380/+9
| | | | Making life too complex at this time.
* 2294Kartik K. Agaram2015-10-286-13/+35
| | | | Bah, sick of CALL and continuations.
* 2293Kartik K. Agaram2015-10-276-22/+43
|
* 2292Kartik K. Agaram2015-10-272-5/+5
|
* 2291 - parsing property treesKartik K. Agaram2015-10-273-9/+50
|
* 2290Kartik K. Agaram2015-10-271-10/+7
|
* 2289Kartik K. Agaram2015-10-271-11/+3
| | | | | | | | | | | | | | | | 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.
* 2288Kartik K. Agaram2015-10-272-3/+6
| | | | | | | 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).
* 2287 - new lexing rulesKartik K. Agaram2015-10-271-5/+14
| | | | | Now we always consider words to be terminated at () and {}. We also always skip commas.
* 2286Kartik K. Agaram2015-10-273-3/+4
|
* 2285Kartik K. Agaram2015-10-261-2/+3
| | | | Still trying to come up with clean lexing rules.
* 2284Kartik K. Agaram2015-10-263-15/+15
|
* 2283 - represent each /property as a treeKartik K. Agaram2015-10-2619-94/+150
|
* 2282Kartik K. Agaram2015-10-265-53/+59
| | | | | Switch format for tracing reagents in preparation for trees rather than arrays of properties.
* 2281Kartik K. Agaram2015-10-262-25/+24
|
* 2280Kartik K. Agaram2015-10-262-4/+4
|
* 2279Kartik K. Agaram2015-10-261-1/+1
|
* 2278Kartik K. Agaram2015-10-261-2/+2
|
* 2277 - reagents now have a tree of typesKartik K. Agaram2015-10-2522-237/+337
|
* 2276Kartik K. Agaram2015-10-251-1/+1
|
* 2275Kartik K. Agaram2015-10-251-0/+1
|
* 2274Kartik K. Agaram2015-10-252-3/+7
|
* 2273 - start expanding the type systemKartik K. Agaram2015-10-253-7/+118
| | | | | | | | | | | | | | 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.
* 2272Kartik K. Agaram2015-10-192-3/+18
|
* 2271 - bugfix: traces cross-contaminating errorsKartik K. Agaram2015-10-199-17/+62
| | | | | | | | | | | | | | | | | | 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.
* 2270Kartik K. Agaram2015-10-124-5/+5
| | | | Thanks Caleb Couch.
* 2269Kartik K. Agaram2015-10-091-1/+12
| | | | Another bugfix. Thanks Jack and Caleb Couch.
* 2268 - bugfix in 'mu sandbox'Kartik K. Agaram2015-10-092-1/+16
| | | | | We still can't have decent tests in this variant. Thanks Jack and Caleb Couch.
* 2267Kartik K. Agaram2015-10-092-2/+2
| | | | | Introducing a new 'newlayer' tag like 'todo', to record places where a nascent new layer might be starting to bud off.
* 2266 - drop experiment with genericsKartik K. Agaram2015-10-072-125/+1
|
* 2263Kartik K. Agaram2015-10-071-1/+1
|
* 2262 - strengthen some type checksKartik K. Agaram2015-10-076-26/+55
|
* 2261Kartik K. Agaram2015-10-062-6/+2
|
* 2260 - start tracing by depth rather than labelKartik K. Agaram2015-10-0616-77/+61
| | | | Now we can collect all traces, just modulating the depth.
* 2259Kartik K. Agaram2015-10-061-7/+7
|
* 2258 - separate warnings from errorsKartik K. Agaram2015-10-0639-460/+507
| | | | | | | 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.
* 2257Kartik K. Agaram2015-10-061-1/+6
|
* 2256Kartik K. Agaram2015-10-061-0/+4
|
* 2255 - bug in detecting non-integersKartik K. Agaram2015-10-061-1/+8
| | | | Thanks Caleb Couch.
* 2254Kartik K. Agaram2015-10-052-34/+34
|
* 2253 - start reorganizing tracesKartik K. Agaram2015-10-052-34/+1
|
* 2252Kartik K. Agaram2015-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-15 07:53:22 +0000