about summary refs log tree commit diff stats
path: root/034call.cc
Commit message (Collapse)AuthorAgeFilesLines
* 2311Kartik K. Agaram2015-10-291-3/+3
|
* 2299 - check types of ingredients in callsKartik K. Agaram2015-10-281-1/+8
| | | | | | | | | | 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).
* 2297Kartik K. Agaram2015-10-281-3/+8
|
* 2296 - record ingredient types on call stackKartik K. Agaram2015-10-281-0/+1
| | | | | 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-281-6/+1
| | | | Making life too complex at this time.
* 2294Kartik K. Agaram2015-10-281-1/+6
| | | | Bah, sick of CALL and continuations.
* 2271 - bugfix: traces cross-contaminating errorsKartik K. Agaram2015-10-191-3/+15
| | | | | | | | | | | | | | | | | | 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.
* 2258 - separate warnings from errorsKartik K. Agaram2015-10-061-7/+7
| | | | | | | 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.
* 2239Kartik K. Agaram2015-10-041-1/+5
|
* 2233 - basic checks for non-primitive recipesKartik K. Agaram2015-10-011-7/+8
| | | | This came last because we had to ensure all primitives are covered.
* 2226 - standardize warning formatKartik K. Agaram2015-10-011-1/+1
| | | | | | | | 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?
* 2095Kartik K. Agaram2015-08-281-1/+0
| | | | | | | | | | | | Finally terminate the experiment of keeping debug prints around. I'm also going to give up on maintaining counts. What we really need is two kinds of tracing: a) For tests, just the domain-specific facts, organized by labels. b) For debugging, just transient dumps to stdout. b) only works if stdout is clean by default. Hmm, I think this means 'stash' should be the transient kind of trace.
* 1910 - bugfix: unrecognized recipe with resultKartik K. Agaram2015-07-311-2/+18
| | | | Thanks Britt Crawford.
* 1868 - start using naked literals everywhereKartik K. Agaram2015-07-281-11/+11
| | | | First step to reducing typing burden. Next step: inferring types.
* 1849Kartik K. Agaram2015-07-251-1/+1
|
* 1848 - core instructions now check for ingredientsKartik K. Agaram2015-07-251-1/+1
| | | | Also standardized warnings.
* 1844 - explicitly end each trace lineKartik K. Agaram2015-07-251-1/+1
| | | | | | | | | More verbose, but it saves trouble when debugging; there's never something you thought should be traced but just never came out the other end. Also got rid of fatal errors entirely. Everything's a warning now, and code after a warning isn't guaranteed to run.
* 1777 - consistent terminology: 'product'Kartik K. Agaram2015-07-131-1/+1
|
* 1724 - first stab at printing interactive resultsKartik K. Agaram2015-07-081-0/+1
|
* 1723Kartik K. Agaram2015-07-081-4/+1
| | | | | Some reorg before we start plumbing 'reply' from 'run-interactive' to return a string containing the results.
* 1721 - hide warnings inside interactive routinesKartik K. Agaram2015-07-081-1/+5
| | | | | | | | | | We will need many other forms of isolation for these. For starters we're going to have to replace most asserts with warnings that can be traced so that the environment doesn't crash because of illegal code typed into it. New test is still failing. Just getting it to fail right was hard enough.
* 1702 - experiment: start using 'ordinal' in namesKartik K. Agaram2015-07-041-4/+4
| | | | | | | It comes up pretty early in the codebase, but hopefully won't come up in the mu level until we get to higher-order recipes. Potentially intimidating name, but such prime real estate with no confusing overloadings in other projects!
* 1698Kartik K. Agaram2015-07-031-0/+120