5 ms·

How does dynamic scoping make Emacs easier to extend?

by Peaker 15y ago

yoklov 15y ago
In a system with dynamic scoping, you have access to variables which otherwise you might not. If it were written in scheme, it might be more difficult to know how many buffers are currently open or some other text-editory value than it is in emacs lisp. Interestingly, from what I've seen dynamic scoping hasn't hindered emacs lispers at all. They have some sort of variable naming system that is specific enough that confusion is fairly rare (I've never seen anybody talk about variable naming conflicts, at least). For example, the value of the (chosen randomly out of my .emacs) ``ido-auto-merge-work-directories-length'' variable seems unlikely to be changed accidentally. That being said, Scheme/Guile have dynamic fluids which allow for the same sorts of things to be done. Personally, I feel like these would have to be used heavily in order to for a hypothetical lexically-scoped guile-based emacs to work, but maybe thats just because I feel like dynamic scope makes things easier to extend :p (at least, in this sort of program).
- p4bl0 15y ago
  It seems dynamic scoping is not really an issue for Guile to host Emacs Lisp. See the paragraph from the README[1] of the current implementation: flet and flet*: --------------- These constructs behave exactly like let and let*, except that they bind the function slots rather than the value slots, and so make dynamic scoping available for functions, too. To me this sounds like the dynamic scoping issue has already been solved. [1] http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=module/language/elisp/README;hb=HEAD http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=mod...
  - gruseom 15y ago
    No, that's about writing an Elisp compiler in Guile. Yoklov was talking whether Guile itself is as suitable an extension langauge as Elisp.
    - p4bl0 15y ago
      Right but what if this compiler could JIT elisp to the Guile VM? It would use Guile but still be elisp compatible. Am I wrong?
      - gruseom 15y ago
        As far as I know (but I'm not the person to ask), their goal is to swap a new (Guile-based) Elisp implementation into Emacs that is 100% compatible with existing programs. That seems like a sine qua non if their plan is to have any chance.
gruseom 15y ago
How does dynamic scoping make Emacs easier to extend? It gives you easy access to everything that's going on at runtime. For example, many Emacs buffers are read-only or have read-only bits of text (e.g. the prompt in a Slime REPL). If your code tries to change that text you get an error. But there's a trivial idiom for getting around it: (let ((inhibit-read-only t)) (do-the-thing-that-changes-text)) Any code invoked during the execution of this form, such as the system code that enforces read-onlyness, will now behave differently. Because Emacs is dynamically scoped, everything works this way. You don't depend on the author of some module having said in the past, "Someone might want to modify this variable at runtime someday, so I'll declare it to be dynamic." Everything is readable and writeable by default. This is a big deal for Emacs' extensibility. Dynamic scoping isn't good in general, but Emacs has benefited handsomely by making this tradeoff in its own case. There are thousands of useful Elisp modules that interoperate with remarkably little fuss, all extending the same system. Yet the language is dynamically scoped and has zero encapsulation. Most people, I think, would deny that that was possible if it didn't exist. Many people still deny it is possible even though it does!
- Peaker 15y ago
  I don't think dynamic scoping makes it possible -- I think it is used simply because it is there. If it wasn't there, some other solution, just as good (if not better) would be used. When writing e-lisp, I find dynamic scoping limiting, and using lexical-let, especially when I want curried/partial-application, is extremely annoying. For me, extending emacs is harder because of dynamic scoping. It is entirely possible to have code be executed in some sort of "Reader" monad/env, and execute it in a different than default env -- which gives you "dynamic scoping" on whatever input you want, without contaminating every other name. I think almost every negative feature you could possibly implement would find "good use" that defended its existence (Dynamic scoping, $_ in Perl, implementation inheritance, etc).

How does dynamic scoping make Emacs easier to extend?

by Peaker 15y ago

How does dynamic scoping make Emacs easier to extend?

In a system with dynamic scoping, you have access to variables which otherwise you might not. If it were written in scheme, it might be more difficult to know how many buffers are currently open or some other text-editory value than it is in emacs lisp. Interestingly, from what I've seen dynamic scoping hasn't hindered emacs lispers at all. They have some sort of variable naming system that is specific enough that confusion is fairly rare (I've never seen anybody talk about variable naming conflicts, at least). For example, the value of the (chosen randomly out of my .emacs) ``ido-auto-merge-work-directories-length'' variable seems unlikely to be changed accidentally. That being said, Scheme/Guile have dynamic fluids which allow for the same sorts of things to be done. Personally, I feel like these would have to be used heavily in order to for a hypothetical lexically-scoped guile-based emacs to work, but maybe thats just because I feel like dynamic scope makes things easier to extend :p (at least, in this sort of program).

p4bl0 15y ago
It seems dynamic scoping is not really an issue for Guile to host Emacs Lisp. See the paragraph from the README[1] of the current implementation: flet and flet*: --------------- These constructs behave exactly like let and let*, except that they bind the function slots rather than the value slots, and so make dynamic scoping available for functions, too. To me this sounds like the dynamic scoping issue has already been solved. [1] http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=module/language/elisp/README;hb=HEAD http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=mod...
- gruseom 15y ago
  No, that's about writing an Elisp compiler in Guile. Yoklov was talking whether Guile itself is as suitable an extension langauge as Elisp.
  - p4bl0 15y ago
    Right but what if this compiler could JIT elisp to the Guile VM? It would use Guile but still be elisp compatible. Am I wrong?
    - gruseom 15y ago
      As far as I know (but I'm not the person to ask), their goal is to swap a new (Guile-based) Elisp implementation into Emacs that is 100% compatible with existing programs. That seems like a sine qua non if their plan is to have any chance.

gruseom 15y ago

How does dynamic scoping make Emacs easier to extend? It gives you easy access to everything that's going on at runtime. For example, many Emacs buffers are read-only or have read-only bits of text (e.g. the prompt in a Slime REPL). If your code tries to change that text you get an error. But there's a trivial idiom for getting around it: (let ((inhibit-read-only t)) (do-the-thing-that-changes-text)) Any code invoked during the execution of this form, such as the system code that enforces read-onlyness, will now behave differently. Because Emacs is dynamically scoped, everything works this way. You don't depend on the author of some module having said in the past, "Someone might want to modify this variable at runtime someday, so I'll declare it to be dynamic." Everything is readable and writeable by default. This is a big deal for Emacs' extensibility. Dynamic scoping isn't good in general, but Emacs has benefited handsomely by making this tradeoff in its own case. There are thousands of useful Elisp modules that interoperate with remarkably little fuss, all extending the same system. Yet the language is dynamically scoped and has zero encapsulation. Most people, I think, would deny that that was possible if it didn't exist. Many people still deny it is possible even though it does!

Peaker 15y ago
I don't think dynamic scoping makes it possible -- I think it is used simply because it is there. If it wasn't there, some other solution, just as good (if not better) would be used. When writing e-lisp, I find dynamic scoping limiting, and using lexical-let, especially when I want curried/partial-application, is extremely annoying. For me, extending emacs is harder because of dynamic scoping. It is entirely possible to have code be executed in some sort of "Reader" monad/env, and execute it in a different than default env -- which gives you "dynamic scoping" on whatever input you want, without contaminating every other name. I think almost every negative feature you could possibly implement would find "good use" that defended its existence (Dynamic scoping, $_ in Perl, implementation inheritance, etc).