about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* 2251Kartik K. Agaram2015-10-051-1/+17
| | | | | | 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.
* 2250Kartik K. Agaram2015-10-051-3/+48
|
* 2249 - start of type ingredients or genericsKartik K. Agaram2015-10-051-10/+79
| | | | | *Extremely* ugly. I need to use better variable names around new waypoints.
* 2248Kartik K. Agaram2015-10-051-9/+6
|
* 2247 - type-check products of non-primitive recipesKartik K. Agaram2015-10-0512-91/+114
| | | | | | | | 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.
* 2246Kartik K. Agaram2015-10-051-1/+1
|
* 2245Kartik K. Agaram2015-10-051-4/+1
|
* 2244Kartik K. Agaram2015-10-052-9/+9
|
* 2243Kartik K. Agaram2015-10-052-1/+3
|
* 2242Kartik K. Agaram2015-10-052-3/+54
|
* 2241 - back to type-checking get-addressKartik K. Agaram2015-10-055-10/+32
| | | | | Now duplex-list is fully non-generic and only works with characters. But we'll fix that in a bit..
* 2240 - drop the failing test in 'mu sandbox'Kartik K. Agaram2015-10-041-45/+1
| | | | | | 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.
* 2239Kartik K. Agaram2015-10-041-1/+5
|
* 2238 - dump recipes after tanglingKartik K. Agaram2015-10-042-0/+10
|
* 2237Kartik K. Agaram2015-10-042-2/+2
|
* 2236 - all tests passing except one in 'mu sandbox'Kartik K. Agaram2015-10-042-15/+17
|
* 2235Kartik K. Agaram2015-10-021-4/+4
|
* 2234 - check type of get's productKartik K. Agaram2015-10-024-20/+53
| | | | Already I'm finding type errors in the programming environment.
* 2233 - basic checks for non-primitive recipesKartik K. Agaram2015-10-012-8/+14
| | | | This came last because we had to ensure all primitives are covered.
* 2232Kartik K. Agaram2015-10-0116-129/+435
|
* 2231Kartik K. Agaram2015-10-011-0/+1
|
* 2230Kartik K. Agaram2015-10-011-11/+17
|
* 2229Kartik K. Agaram2015-10-011-0/+6
|
* 2228 - index-checking for arraysKartik K. Agaram2015-10-011-23/+47
|
* 2227 - offset-checking for containersKartik K. Agaram2015-10-014-42/+88
|
* 2226 - standardize warning formatKartik K. Agaram2015-10-0133-175/+186
| | | | | | | | Always show recipe name where error occurred. But don't show internal 'interactive' name for sandboxes, that's just confusing. What started out as warnings are now ossifying into errors that halt all execution. Is this how things went with C and Unix as well?
* 2225Kartik K. Agaram2015-10-014-63/+91
|
* 2224Kartik K. Agaram2015-09-301-3/+3
|
* 2223Kartik K. Agaram2015-09-302-20/+32
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-07-01 15:11:05 +0000