For easier reading, here's the same thing in Arc (untested):
(= here* '(no-befores-or-afters . nil))
(= orig-ccc ccc)
; This overwrites the original.
(def ccc (body)
(let here here*
(orig-ccc:fn (cont)
;; With multiple value return
;(body:fn results
; reroot.here
; (apply cont results))
; Without
(body [do reroot.here
cont._])
)))
(def dynamic-wind (before during after)
(let here here*
(reroot:cons (cons before after) here)
;; With multiple value return
;(call-with-values during
; (fn results
; reroot.here
; (apply values results)))
; Without
(do1 (during)
reroot.here)
))
(def reroot (there)
(unless (is here* there)
(reroot cdr.there)
(let ((before . after) . ignored-parent) there
(= car.here* (cons after before))
(= cdr.here* there)
(= car.there 'no-befores-or-afters)
(= cdr.there nil)
(= here* there)
(before)))))
This is exactly the same technique I mentioned in the other thread. The language originally doesn't support dynamic-wind, but this code hides the original 'ccc and replaces it with one that manually traverses a global stack of 'dynamic-wind handlers. Good to know this is called Hanson-Lamping. :-p
If the language has built-in exceptions, this particular implementation isn't friendly with them. It doesn't do anything to intercept them! ^_^ To repair this in Arc, we would replace (do1 ...) with (after ...) above.
On the other hand, a language that defines 'dynamic-wind this way can implement exceptions in terms of the replaced 'ccc.
Thanks for that... The Scheme version has even more parentheses and was much harder to understand. I'm starting to see how the algorithm works, and I'll see if this comes out cleaner than the kludge I came up with and incorporated into Arcueid 0.0.5. What I plan to do is restore the very simple continuation invocation it used to have, then wrap it up that way. Exceptions are of course simple enough to implement by using ccc, and implementing them on top of the ccc that supports dynamic-wind should provide us with exceptions that support dynamic-wind as well.
By the way, I haven't seen the orig-cc:fn idiom before. So even a special form like fn works with ssyntax. So I suppose it would not do to just expand it into ((compose orig-cc fn) ...), and we have to actually make it a real function composition.
"So I suppose it would not do to just expand it into ((compose orig-cc fn) ...), and we have to actually make it a real function composition."
Not so. If you look at line 29 in ac.scm you'll see this:
; the next three clauses could be removed without changing semantics
; ... except that they work for macros (so prob should do this for
; every elt of s, not just the car)
((eq? (xcar (xcar s)) 'compose) (ac (decompose (cdar s) (cdr s)) env))
((eq? (xcar (xcar s)) 'complement)
(ac (list 'no (cons (cadar s) (cdr s))) env))
((eq? (xcar (xcar s)) 'andf) (ac-andf s env))
For those not familiar with the Arc compiler, what it's doing is basically these transformations:
If you wish for compose, complement, and andf to work on macros and special forms like fn, your compiler will need to do a similar transformation. The catch is that this transformation only works in functional position:
(map no:do (list 1 2 3 nil nil)) ;; doesn't work
It's all very hacky and whatnot, macros aren't very clean at all in Arc. The other catch is that it hardcodes the symbols 'compose, 'complement, and 'andf, but my Nu compiler fixes that.
The complex interactions are actually all natural consequences of a language that doesn't even have dynamic wind and exceptions in the first place. Because with 'ccc, people can and probably will build these systems themselves, multiple times, in ways that break each other and threaten to fragment the community... ultimately leading to their standardization. IMO, a procedural language with 'ccc is a dubious start if the 100-year goal is a simpler language than Scheme.
