3 ms·

There was some discussion[0] about this a few months ago... (where I was involved & sparked the discussion), and the conclusion was that SBCL & C interop is not

There was some discussion[0] about this a few months ago... (where I was involved & sparked the discussion), and the conclusion was that SBCL & C interop is not as good for emacs. SBCL doesn’t allow lisp functions to be called from C without crossing the conversion line two times, which would be inefficient (esp. since the C functions are written in C for fast speed). I personally think that even with the overhead, adopting SBCL would be an overall improvement, but I’m not maintaining emacs so... [0] https://lists.gnu.org/archive/html/help-gnu-emacs/2019-05/msg00027.html https://lists.gnu.org/archive/html/help-gnu-emacs/2019-05/ms... and the thread following

guenthert 7y ago
I have a hard time following that line of argument. I'd think much of the C code has been written a quarter century ago "for speed". Computers are orders of magnitudes faster these days, so we can waste a few cycles here and there. I wouldn't think it sensible to require Emacs to be fluid on computers slower than e.g. an original Raspberry Pi, which is much faster than the early Unix workstations the C code was written for. Said that, while I personally might prefer an efficient implementation of a well documented and standardized variant of Lisp, Emacs Lisp is arguably easier to learn and more appealing to those who just want to customize the editor, which I'd presume it the vast majority of users.
- sillysaurusx 7y ago
  Not only that, but the runtime semantics are different. ‘foo isn’t a function in CL. But in emacs lisp, it might be. It’s not just a pedantic destination either. ‘(do-foo do-bar) is far easier to write than (list #’do-foo #’do-bar). And you can pass it around more easily. These are all things users want and need. Emacs lisp probably wasn’t designed as a lisp. It was probably designed to be a configuration language, and lisp happened to be the most flexible way of designing it. That’s why stuff like lexical scoping or compiler semantics took a back seat (as it should in this case). Look, I love lisp. You’d be hard pressed to find someone more fanatical about lisp. But CL is... well. CL is CL. You can make it into a config language, but even basics like (require ‘foo) leaves much to be desired. Emacs Lisp is fundamentally simple; most people just don’t take the time to learn the design, and they dismiss it due to the long identifiers and global scope. But the global scope is the power. The global namespace matters. A lot.
  - lispm 7y ago
    > ‘foo isn’t a function in CL. But in emacs lisp, it might be. In Common Lisp it might be. CL-USER 72 > (funcall (first '(sin cos)) pi) 1.2246063538223773D-16 In Common Lisp all symbols denoting functions can be called via FUNCALL and APPLY. Thus one can also pass symbols for functions to higher order functions like MAPCAR: CL-USER 73 > (mapcar 'sin '(12 34 56)) (-0.53657294 0.5290827 -0.521551) CL-USER 75 > (mapcar (lambda (f arg) (funcall f arg)) '(sin cos tan) '(1.3d0 1.4d0 1.5d0)) (0.963558185417193D0 0.16996714290024104D0 14.101419947171719D0) CL-USER 76 > (mapcar 'funcall '(sin cos tan) '(1.3d0 1.4d0 1.5d0)) (0.963558185417193D0 0.16996714290024104D0 14.101419947171719D0) A restriction of Common Lisp is that local lexical functions can't be called via symbols. But anything defined by DEFUN, DEFMETHOD, DEFGENERIC uses symbols as names and those can be used by FUNCALL and APPLY. > basics like (require ‘foo) leaves much to be desired. REQUIRE isn't much used in Common Lisp in the last decades. Individual implementations may still support it as a calling interface to some more complex machinery to locate code. Much of the current code uses ASDF to describe and load code files.
    - sillysaurusx 7y ago
      Heh. You’re right of course. Thank you for correcting me. I was going to retract most of my criticism due to being blatantly mistaken. But, the namespace thing is actually the part that seems like it would cause the most friction for CL as a configuration language. Specifically: in emacs lisp, if you write ‘foo-frobber, you know it’s probably from the package ‘foo, and that it’s a frobber. Whether it’s a function or a variable can often be inferred correctly from context. Whereas in CL, isn’t the norm to use the package system everywhere? (Perhaps I am mistaken about this as well.) So you can’t just pass ‘foo-frobber to arbitrary packages and expect it to work. For example, (intern “foo-frobber”) returns a symbol. (Or does it? Now I’m second guessing everything I thought I remembered about CL.) But can you just pass that plain old symbol between packages without having to explicitly indicate its origin? Hmmm... now that I’ve talked through the problem, perhaps the namespace issue isn’t such a big deal. Maybe the friction was moreso ASDF’s peculiarities rather than the fundamental behaviors of CL.
mark_l_watson 7y ago
I am not arguing that converting Emacs to Common Lisp is a good idea, but it would seem that much less low level C code would be required. Also, the startup time for compiled and packaged SBCL applications is very fast because loading a prepared Lisp image file is very fast.

guenthert 7y ago

I have a hard time following that line of argument. I'd think much of the C code has been written a quarter century ago "for speed". Computers are orders of magnitudes faster these days, so we can waste a few cycles here and there. I wouldn't think it sensible to require Emacs to be fluid on computers slower than e.g. an original Raspberry Pi, which is much faster than the early Unix workstations the C code was written for. Said that, while I personally might prefer an efficient implementation of a well documented and standardized variant of Lisp, Emacs Lisp is arguably easier to learn and more appealing to those who just want to customize the editor, which I'd presume it the vast majority of users.

sillysaurusx 7y ago
Not only that, but the runtime semantics are different. ‘foo isn’t a function in CL. But in emacs lisp, it might be. It’s not just a pedantic destination either. ‘(do-foo do-bar) is far easier to write than (list #’do-foo #’do-bar). And you can pass it around more easily. These are all things users want and need. Emacs lisp probably wasn’t designed as a lisp. It was probably designed to be a configuration language, and lisp happened to be the most flexible way of designing it. That’s why stuff like lexical scoping or compiler semantics took a back seat (as it should in this case). Look, I love lisp. You’d be hard pressed to find someone more fanatical about lisp. But CL is... well. CL is CL. You can make it into a config language, but even basics like (require ‘foo) leaves much to be desired. Emacs Lisp is fundamentally simple; most people just don’t take the time to learn the design, and they dismiss it due to the long identifiers and global scope. But the global scope is the power. The global namespace matters. A lot.
- lispm 7y ago
  > ‘foo isn’t a function in CL. But in emacs lisp, it might be. In Common Lisp it might be. CL-USER 72 > (funcall (first '(sin cos)) pi) 1.2246063538223773D-16 In Common Lisp all symbols denoting functions can be called via FUNCALL and APPLY. Thus one can also pass symbols for functions to higher order functions like MAPCAR: CL-USER 73 > (mapcar 'sin '(12 34 56)) (-0.53657294 0.5290827 -0.521551) CL-USER 75 > (mapcar (lambda (f arg) (funcall f arg)) '(sin cos tan) '(1.3d0 1.4d0 1.5d0)) (0.963558185417193D0 0.16996714290024104D0 14.101419947171719D0) CL-USER 76 > (mapcar 'funcall '(sin cos tan) '(1.3d0 1.4d0 1.5d0)) (0.963558185417193D0 0.16996714290024104D0 14.101419947171719D0) A restriction of Common Lisp is that local lexical functions can't be called via symbols. But anything defined by DEFUN, DEFMETHOD, DEFGENERIC uses symbols as names and those can be used by FUNCALL and APPLY. > basics like (require ‘foo) leaves much to be desired. REQUIRE isn't much used in Common Lisp in the last decades. Individual implementations may still support it as a calling interface to some more complex machinery to locate code. Much of the current code uses ASDF to describe and load code files.
  - sillysaurusx 7y ago
    Heh. You’re right of course. Thank you for correcting me. I was going to retract most of my criticism due to being blatantly mistaken. But, the namespace thing is actually the part that seems like it would cause the most friction for CL as a configuration language. Specifically: in emacs lisp, if you write ‘foo-frobber, you know it’s probably from the package ‘foo, and that it’s a frobber. Whether it’s a function or a variable can often be inferred correctly from context. Whereas in CL, isn’t the norm to use the package system everywhere? (Perhaps I am mistaken about this as well.) So you can’t just pass ‘foo-frobber to arbitrary packages and expect it to work. For example, (intern “foo-frobber”) returns a symbol. (Or does it? Now I’m second guessing everything I thought I remembered about CL.) But can you just pass that plain old symbol between packages without having to explicitly indicate its origin? Hmmm... now that I’ve talked through the problem, perhaps the namespace issue isn’t such a big deal. Maybe the friction was moreso ASDF’s peculiarities rather than the fundamental behaviors of CL.

mark_l_watson 7y ago

I am not arguing that converting Emacs to Common Lisp is a good idea, but it would seem that much less low level C code would be required. Also, the startup time for compiled and packaged SBCL applications is very fast because loading a prepared Lisp image file is very fast.