* I wildguess a condition that makes it easier for CL to accommodate this syntax without incredible overhead, is the fact that they do not have first class continuations (but only escape continuations which mean N-step procedure return), so they don't have the question "which dynamic variable assignment should apply in which continuation".
That's correct. The traditional implementations are:
"deep binding": a global alist holding all the bindings of all dynamic variables which is pushed when a let or lambda that binds dynamic variables is entered, and that is popped when it exits
"shallow binding": either a similar setup but with the current value cached in the symbol representing the variable at run time, or a setup with one alist per variable.
Neither of these methods works correctly in the presence of call/cc or threads. Threads are only semi-standardized in CL: <
https://trac.common-lisp.net/bordeaux-threads/wiki/ApiDocumentation>. If you use this library, you still have to deal with either the "reinitialize local bindings" or the "copy local bindings" strategy of the underlying application: the "share bindings with the parent thread" strategy is hidden (all per #lisp).
John Cowan
http://vrici.lojban.org/~cowan cowan@ccil.orgIt's like if you meet an really old, really rich guy covered in liver
spots and breathing with an oxygen tank, and you say, "I want to be
rich, too, so I'm going to start walking with a cane and I'm going to
act crotchety and I'm going to get liver disease. --Wil Shipley