about summary refs log tree commit diff stats
path: root/076continuation.cc
Commit message (Collapse)AuthorAgeFilesLines
* 4231Kartik K. Agaram2018-03-211-0/+3
|
* 4229Kartik K. Agaram2018-03-161-2/+12
| | | | Another bugfix, another improved error message.
* 4226 - example program: exceptionsKartik K. Agaram2018-03-151-3/+21
| | | | | | Pretty klunky; we're violating the type system by prepending an extra result, so functions we want to catch exceptions around have to be header-less and check input types at run-time.
* 4225Kartik K. Agaram2018-03-151-7/+7
|
* 4213Kartik K. Agaram2018-02-201-0/+3
|
* 4179 - experiment: rip out memory reclamationKartik K. Agaram2018-01-031-112/+1
| | | | | | | | | | | | | | | | | | | | | I have a plan for a way to avoid use-after-free errors without all the overheads of maintaining refcounts. Has the nice side-effect of requiring manual memory management. The Mu way is to leak memory by default and build tools to help decide when and where to expend effort plugging memory leaks. Arguably programs should be distributed with summaries of their resource use characteristics. Eliminating refcount maintenance reduces time to run tests by 30% for `mu edit`: this commit parent mu test: 3.9s 4.5s mu test edit: 2:38 3:48 Open questions: - making reclamation easier; some sort of support for destructors - reclaiming local scopes (which are allocated on the heap) - should we support automatically reclaiming allocations inside them?
* 4160 - named marks for delimited continuationsKartik K. Agaram2017-12-151-31/+53
| | | | | Hypothesis: this is needed to build McCarthy's amb operator. https://rosettacode.org/wiki/Amb
* 4159Kartik K. Agaram2017-12-101-1/+28
| | | | | Many continuation examples were failing since commit 4151. Include one of them as a test.
* 4153Kartik K. Agaram2017-12-071-2/+3
|
* 4152Kartik K. Agaram2017-12-071-0/+11
|
* 4151 - specializing calls returning continuationsKartik K. Agaram2017-12-071-0/+19
|
* 4150Kartik K. Agaram2017-12-071-15/+15
|
* 4148Kartik K. Agaram2017-12-071-0/+10
|
* 4132Kartik K. Agaram2017-11-191-4/+2
| | | | | | Simplify the implementation of calling continuations. Since we don't support next-ingredient on continuations, might as well not bother with all that call housekeeping for ingredients.
* 4131Kartik K. Agaram2017-11-191-6/+46
| | | | | | | | | Bugfix: I hadn't been allowing continuations to be copied. Deepens our initial sin of managing the Mu call stack implicitly in the C interpreter. Since the call stack was implicit, continuations had to be implicit as well. Since continuations aren't in Mu's memory, we have to replicate refcounting logic for them.
* 4130Kartik K. Agaram2017-11-191-34/+34
|
* 4127Kartik K. Agaram2017-11-191-9/+9
|
* 4126Kartik K. Agaram2017-11-191-6/+1
|
* 4124Kartik K. Agaram2017-11-191-6/+3
|
* 4118Kartik K. Agaram2017-11-061-0/+1
|
* 4117 - done with delimited continuationsKartik K. Agaram2017-11-061-0/+6
| | | | | At least this particular implementation of them. Let's play with them now for a while, see if they're fully equivalent to shift/reduce.
* 4116 - support calling continuations with argumentsKartik K. Agaram2017-11-061-7/+4
| | | | | | Surprisingly small change, considering how long it took me and how mind-bending it was. 'return-continuation-until-mark' now behaves like both call and return instructions, which made it hard to reason about.
* 4113Kartik K. Agaram2017-11-051-0/+3
|
* 4108Kartik K. Agaram2017-11-051-1/+2
|
* 4107Kartik K. Agaram2017-11-051-0/+36
| | | | Return other values along with the current continuation.
* 4105Kartik K. Agaram2017-11-031-4/+4
|
* 4104Kartik K. Agaram2017-11-031-1/+1
| | | | | Stop hardcoding Max_depth everywhere; we had a default value for a reason but then we forgot all about it.
* 4103 - continuations no longer cause memory corruptionKartik K. Agaram2017-11-031-5/+100
|
* 3994Kartik K. Agaram2017-09-131-5/+5
|
* 3989Kartik K. Agaram2017-09-011-19/+19
|
* 3988Kartik K. Agaram2017-09-011-3/+6
|
* 3986 - bring back delimited continuationsKartik K. Agaram2017-08-301-0/+185
They're back after a long hiatus: commit 2295 in Oct 2015. I'm not convinced anymore that this is actually a correct implementation of continuations. Issues on at least two fronts: a) These aren't safe yet. Since continuations can be called multiple times, we need to disable reclamation of locals inside a continuation. There may be other type- or memory-safety issues. However, delimited continuations at least seem possible to make safe. Undelimited continuations (call/cc) though are permanently out. b) They may not actually be as powerful as delimited continuations. Let's see if I can build 'yield' out of these primitives.