4 ms·

I agree with you! It's not really that bad. The two biggest problems for me are the lack of namespaces/modules like you said, and the default dynamic scope (wit

I agree with you! It's not really that bad. The two biggest problems for me are the lack of namespaces/modules like you said, and the default dynamic scope (with the ability to enable lexical scoping). They're both basically just ergonomic issues at this point, with prefixing names and always setting lexical scoping being cultural norms.

gosukiwi 4y ago
I don't know Emacs Lisp but didn't RMS just said in his talk that they changed the default to lexical scoping?
- klibertp 4y ago
  Really? (Didn't have the time to listen to the talk.) I'd like to know if it was somehow measured, ie. how much of the Elisp code is still not adjusted to use lexical scoping and how much of such code would break by switching to lexical scoping. You can still opt-in to dynamic scoping by using defvar (and it's been a standard practice since forever), so the only scenario where old code would break would be where a called function accesses local variables from the calling function, like you would do in TCL with upvalue. I suspect that's a pretty small percentage of all the Elisp code in the wild; plus, this would be caught by the byte compiler, without the need to run the offending code. In any case: the change of the default is welcome, though not very important, as we've all already got used to putting `lexical-binding: t` at the top of every Elisp file :)
klibertp 4y ago
> They're both basically just ergonomic issues Yes! Prefixing names as a way of emulating namespaces generally works well enough. We could get modules support the same way JS used to have them, ie. as hashes of closures. Or we could use something like the `nameless` package, which rewrites the code to add a prefix to definitions automatically. Yet nobody seems to be doing either: it's just too much of a pain with too small a gain. The situation would be different if we got first-class module support in the language, but if we're going to only emulate it anyway, then namespacing with prefixes is just the easiest way to do it that is still "good enough". Still, Racket-like modules would be great to have, can't deny that :-)

gosukiwi 4y ago

I don't know Emacs Lisp but didn't RMS just said in his talk that they changed the default to lexical scoping?

klibertp 4y ago
Really? (Didn't have the time to listen to the talk.) I'd like to know if it was somehow measured, ie. how much of the Elisp code is still not adjusted to use lexical scoping and how much of such code would break by switching to lexical scoping. You can still opt-in to dynamic scoping by using defvar (and it's been a standard practice since forever), so the only scenario where old code would break would be where a called function accesses local variables from the calling function, like you would do in TCL with upvalue. I suspect that's a pretty small percentage of all the Elisp code in the wild; plus, this would be caught by the byte compiler, without the need to run the offending code. In any case: the change of the default is welcome, though not very important, as we've all already got used to putting `lexical-binding: t` at the top of every Elisp file :)

klibertp 4y ago

> They're both basically just ergonomic issues Yes! Prefixing names as a way of emulating namespaces generally works well enough. We could get modules support the same way JS used to have them, ie. as hashes of closures. Or we could use something like the `nameless` package, which rewrites the code to add a prefix to definitions automatically. Yet nobody seems to be doing either: it's just too much of a pain with too small a gain. The situation would be different if we got first-class module support in the language, but if we're going to only emulate it anyway, then namespacing with prefixes is just the easiest way to do it that is still "good enough". Still, Racket-like modules would be great to have, can't deny that :-)