@@ 6,7 6,7 @@ unstructured control flow.
http://www.lispworks.com/documentation/HyperSpec/Body/s_tagbod.htm
## deps
-`com.manigfeald/tagbody {:git/url "https://git.sr.ht/~hiredman/tagbody" :sha "2ed0f6f78c01ad0c01449cbffcf29ab0a92146d2"}}}`
+`com.manigfeald/tagbody {:git/url "https://git.sr.ht/~hiredman/tagbody" :sha "2ed0f6f78c01ad0c01449cbffcf29ab0a92146d2"}`
## Usage
@@ 14,6 14,9 @@ http://www.lispworks.com/documentation/HyperSpec/Body/s_tagbod.htm
(require '[com.manigfeald.tagbody :refer [tagbody go]])
+(defn incf [x v]
+ (var-set x (+ (var-get x) v)))
+
(with-local-vars
[v nil]
(tagbody
@@ 31,19 34,25 @@ http://www.lispworks.com/documentation/HyperSpec/Body/s_tagbod.htm
point-b
(incf v 8))
(var-get v))
+
+;;=> 15
```
## Limitations
tagbody uses java.lang.Throwables to jump around. This can be
-problematic if you catch Throwables. Exception handles are also single
+problematic if you catch Throwables. Exception handlers are also single
threaded, so you cannot go across threads.
The way tagbody currently runs it is limitted to 254 or so expressions
in a tagbody.
Expressions are converted to closures (fns) in a way that no doubt
-interfers with locals clearing.
+interfers with locals clearing. This will also break things like set!
+on mutable deftype fields.
+
+An expression in a tagbody can never be a tail as far as loop/recur is
+concerned.
## Why?