3 ms·

Unless I'm getting the wrong end of the stick, this appears to use dynamic, rather than lexical scope for the special non-stack-unwinding exception handler bloc

by mjw 15y ago

Unless I'm getting the wrong end of the stick, this appears to use dynamic, rather than lexical scope for the special non-stack-unwinding exception handler blocks. To me non-lexical scope is quite confusing, especially if you're proposing adding it to a language (eg Java) which is otherwise lexically scoped. IIRC lexical scope is generally preferred these days by language designers, and Common Lisp is one of the few languages which supports dynamic scope alongside lexical.

riffraff 15y ago
I believe it may be a kind of dynamic lookup, but I'm not sure separating stack unwinding from erro signaling needs it. Also my2c: I'm not sure dynamic scope it's completely passé these days. In general, it is mostly the idea of "leaving control to the user instead of the used" which has been reappearing in the form of AOP and COP. In a sense, it is also what monkey patching is about in some OO languages, being enabled by the only surviving dynamic lookup, the "self" one.
- mjw 15y ago
  Fair enough -- I forgot about 'self' being dynamically scoped, which is an interesting point. Perhaps it's no coincidence that I have a particular dislike for the scoping rules around Javascript's "this" keyword, as they're perhaps even more dynamically scoped than in other OO languages. http://lambda-the-ultimate.org/node/3166 http://lambda-the-ultimate.org/node/3166 was my reference though, with at least some seeing the PL design debate as being settled in favour of lexical scope. Although some dissent in the comments there.
tomp 15y ago
Yes, it isn't lexical scoping, it's dynamic, but that is the same way as exception handlers are scoped currently.
- mjw 15y ago
  Are they though? in which language? I was under the impression that the traditional 'catch' block has the stack unwound for it back to a frame with the same lexical scope as the associated 'try'...
  - tomp 15y ago
    Dynamic bindings are characterized by being bound not by the nearest preceding code at compile-time, but by the nearest preceding code at run-time. Therefore, the way I understand it, the important bit is not the relationship between a try and a catch, but between the throw and the catch. You could imagine throw as a call of the function last_catch(Exception e), which is dynamically bound by one of the "parent" functions (functions below on the stack).
deleted 15y ago
[deleted]

by mjw 15y ago

riffraff 15y ago

I believe it may be a kind of dynamic lookup, but I'm not sure separating stack unwinding from erro signaling needs it. Also my2c: I'm not sure dynamic scope it's completely passé these days. In general, it is mostly the idea of "leaving control to the user instead of the used" which has been reappearing in the form of AOP and COP. In a sense, it is also what monkey patching is about in some OO languages, being enabled by the only surviving dynamic lookup, the "self" one.

mjw 15y ago
Fair enough -- I forgot about 'self' being dynamically scoped, which is an interesting point. Perhaps it's no coincidence that I have a particular dislike for the scoping rules around Javascript's "this" keyword, as they're perhaps even more dynamically scoped than in other OO languages. http://lambda-the-ultimate.org/node/3166 http://lambda-the-ultimate.org/node/3166 was my reference though, with at least some seeing the PL design debate as being settled in favour of lexical scope. Although some dissent in the comments there.

tomp 15y ago

Yes, it isn't lexical scoping, it's dynamic, but that is the same way as exception handlers are scoped currently.

mjw 15y ago
Are they though? in which language? I was under the impression that the traditional 'catch' block has the stack unwound for it back to a frame with the same lexical scope as the associated 'try'...
- tomp 15y ago
  Dynamic bindings are characterized by being bound not by the nearest preceding code at compile-time, but by the nearest preceding code at run-time. Therefore, the way I understand it, the important bit is not the relationship between a try and a catch, but between the throw and the catch. You could imagine throw as a call of the function last_catch(Exception e), which is dynamically bound by one of the "parent" functions (functions below on the stack).

deleted 15y ago

[deleted]