it would be appreciated! :P. Functional programming helps because usually it is the last thing you wrote that is wrong, but occasionally I'm completely puzzled by error messages (only to find out that one of my comments started with a : rather than a ;.
Hmm. Anyway it looks like it might be useful to subtype function closures into continuation and non-continuation functions (as an aside it would probably be useful also for optimizations: when a continuation function exits, it can't be called and its closure can be immediately freed or reused, unless we use 'ccc: and even so we could just copy the continuation into a non-continuation closure).
Then when a backtrace is requested we simply scan through the stack for continuation-type functions, and scan through their closures for continuation-types, and so on until we end up on a closure without any continuation-type functions.
While scanning the stack you have to pay attention to not include functional arguments as if they were called functions. To give descriptive names to functions I would transform every lambda expression in a named function, e.g. :
(def f (x) x) --> (set f (fn (x) x)) --> (set f (__named '(f x) (x) x))
and for anonymous functions:
(fn (a b) (+ a b)) --> (__named '(fn (a b)) (a b) (+ a b))
> While scanning the stack you have to pay attention to not include functional arguments as if they were called functions.
Which is why I was proposing to subtype closures into continuations and non-continuations. Normal functions that are passed around are non-continuations, while continuation closures are created during CPS-conversion. Of course we probably need to add code in 'ccc which would probably copy a continuation closure into a non-continuation version of the closure.
