3 ms·

The idea was to replace Emacs's embedded Elisp interpreter with Guile's, not to rewrite Emacs in Guile Scheme.

eadmund 8y ago
Why not just replace Emacs's embedded elisp interpreter with one written in Common Lisp? CLOCC has a basic elisp interpreter already: https://sourceforge.net/p/clocc/hg/ci/default/tree/src/cllib/elisp.lisp https://sourceforge.net/p/clocc/hg/ci/default/tree/src/cllib... Take that, put a little work into it and one could presumably replace the C core of Emacs with Common Lisp.
- melling 8y ago
  Stallman hates Common Lisp. https://www.gnu.org/gnu/rms-lisp.en.html https://www.gnu.org/gnu/rms-lisp.en.html
  - messe 8y ago
    > I implemented Common Lisp once on the Lisp machine, and I'm not all that happy with it. One thing I don't like terribly much is keyword arguments (8). They don't seem quite Lispy to me; I'll do it sometimes but I minimize the times when I do that. > [...] > So we started to make Scheme the standard extensibility language for GNU. Not Common Lisp, because it was too large. I'd hardly say he hates it based solely on that essay.
    - kazinator 8y ago
      Wow, I so agree with that and the (8) footnote: "I don't mind if a very complex and heavyweight function takes keyword arguments. What bothers me is making simple basic functions such as “member” use them." I kept keyword arguments out of TXR Lisp. That is, out of the function call mechanism. It doesn't seem like a good idea to deal with a dictionary like mechanism in function calls. I invented something called "parameter list macros". A parameter list macro can be written which adds keyword argument ability to a function (and such a macro is provided). You can do (lambda (:key a b c -- x y) ...) and now you have keyword parameters x and y. They support the (sym dfl-val present-p) syntax and all. The :key parameter macro implements them via a source transformation. :key is able to rewrite both the parameter list and the body of the function to make this work. One reason Common Lisp programmers use keyword macros is that there is no way to invoke the default value of an optional parameter which precedes another optional parameter to which an argument is being specified. If a function has optional arguments X and Y, the caller cannot default X if it specifies Y. I fixed that in TXR Lisp: the symbol : (colon) can be passed to an optional parameter to activate its default value. So if a binary function f has two optional parameters we can invoke (f : 3) to default the first optional, and specify the second one as 3. This special feature is only supported in function calls, not in macro/destructuring parameter lists. That : symbol also serves as the &optional keyword, separating the required parameters from the optionals. It harmonizes with the consing dot that demarcates the &rest parameter: (lambda (x y : z w . r) ...): x y required, z w optional, r rest. The : symbol is nothing more than the symbol named "" (empty string) in the keyword package. It's provides a very useful third value to the nil and t duo. Common Lisps have this symbol! Unfortunately, they tend to print it funny back at you like :||, and neglect to get any mileage out of its notational convenience. As for those member functions, I provide a memq, memql and memqual that use the three different equalities. The more general member function takes a key and test function, but not as keyword arguments but positional optional parameters. If you want the default test, but custom key: [member foo bar : mykey].
  - reikonomusha 8y ago
    The linked transcript doesn’t seem to indicate he hates it. I read that he just found some parts of CL to not he “lispy”, like keyword arguments.
  - dcooper8 8y ago
    He just thought it was "too big" at the time. That may no longer be the case.
  - mark_l_watson 8y ago
    Thanks, that was a fun read. BTW, I don’t think Richard totally dislikes Common Lisp: years ago I got an email from him about releasing my ancient Springer-Verlag Common Lisp book under the FSF documentation license. Unfortunately I couldn’t do it because I didn’t have the manuscript files.
    - avar 8y ago
      If you own the copyright to the text couldn't you make it known that if someone were to OCR it, clean up the formatting, and publish it that the result could be freely distributed?
      - jacobush 8y ago
        I guess in a fair and honest world, yes because it's legal? But in our actual world, it's also legal but publishers may play dirty and somehow claim rights because you published something based on their edition? Just thinking out loud.
    - lispm 8y ago
      > I don’t think Richard totally dislikes Common Lisp maybe not totally, but mostly. Beyond that he does not care about it and isn't interested in it.
      - kazinator 8y ago
        If you were already an "advanced Lisper" in the 1980's, Common Lisp might be something like C11 to someone who had expert C chops before even C99. I code in C regularly, yet I do not care and am not interested in C after C90. Only some library features of C99 and that's about it. Stallman's concepts of what is Lisp, how to use Lisp, how to implement Lisp, were formed long before Common Lisp. If you're in that position, it's easy to have allergic reactions to requirements you don't agree with.
        lispm 8y ago
        Kind of surprising, since Stallman was a developer with and user of Lisp Machine Lisp, the single biggest influence of Common Lisp. Maclisp and its successor Lisp Machine Lisp, were probably his biggest influences. Emacs Lisp is based on Maclisp - without the features of Lisp Machine Lisp like keyword arguments, Flavors as the object-system, ...

Why not just replace Emacs's embedded elisp interpreter with one written in Common Lisp? CLOCC has a basic elisp interpreter already: https://sourceforge.net/p/clocc/hg/ci/default/tree/src/cllib/elisp.lisp https://sourceforge.net/p/clocc/hg/ci/default/tree/src/cllib... Take that, put a little work into it and one could presumably replace the C core of Emacs with Common Lisp.

melling 8y ago
Stallman hates Common Lisp. https://www.gnu.org/gnu/rms-lisp.en.html https://www.gnu.org/gnu/rms-lisp.en.html
- messe 8y ago
  > I implemented Common Lisp once on the Lisp machine, and I'm not all that happy with it. One thing I don't like terribly much is keyword arguments (8). They don't seem quite Lispy to me; I'll do it sometimes but I minimize the times when I do that. > [...] > So we started to make Scheme the standard extensibility language for GNU. Not Common Lisp, because it was too large. I'd hardly say he hates it based solely on that essay.
  - kazinator 8y ago
    Wow, I so agree with that and the (8) footnote: "I don't mind if a very complex and heavyweight function takes keyword arguments. What bothers me is making simple basic functions such as “member” use them." I kept keyword arguments out of TXR Lisp. That is, out of the function call mechanism. It doesn't seem like a good idea to deal with a dictionary like mechanism in function calls. I invented something called "parameter list macros". A parameter list macro can be written which adds keyword argument ability to a function (and such a macro is provided). You can do (lambda (:key a b c -- x y) ...) and now you have keyword parameters x and y. They support the (sym dfl-val present-p) syntax and all. The :key parameter macro implements them via a source transformation. :key is able to rewrite both the parameter list and the body of the function to make this work. One reason Common Lisp programmers use keyword macros is that there is no way to invoke the default value of an optional parameter which precedes another optional parameter to which an argument is being specified. If a function has optional arguments X and Y, the caller cannot default X if it specifies Y. I fixed that in TXR Lisp: the symbol : (colon) can be passed to an optional parameter to activate its default value. So if a binary function f has two optional parameters we can invoke (f : 3) to default the first optional, and specify the second one as 3. This special feature is only supported in function calls, not in macro/destructuring parameter lists. That : symbol also serves as the &optional keyword, separating the required parameters from the optionals. It harmonizes with the consing dot that demarcates the &rest parameter: (lambda (x y : z w . r) ...): x y required, z w optional, r rest. The : symbol is nothing more than the symbol named "" (empty string) in the keyword package. It's provides a very useful third value to the nil and t duo. Common Lisps have this symbol! Unfortunately, they tend to print it funny back at you like :||, and neglect to get any mileage out of its notational convenience. As for those member functions, I provide a memq, memql and memqual that use the three different equalities. The more general member function takes a key and test function, but not as keyword arguments but positional optional parameters. If you want the default test, but custom key: [member foo bar : mykey].
- reikonomusha 8y ago
  The linked transcript doesn’t seem to indicate he hates it. I read that he just found some parts of CL to not he “lispy”, like keyword arguments.
- dcooper8 8y ago
  He just thought it was "too big" at the time. That may no longer be the case.
- mark_l_watson 8y ago
  Thanks, that was a fun read. BTW, I don’t think Richard totally dislikes Common Lisp: years ago I got an email from him about releasing my ancient Springer-Verlag Common Lisp book under the FSF documentation license. Unfortunately I couldn’t do it because I didn’t have the manuscript files.
  - avar 8y ago
    If you own the copyright to the text couldn't you make it known that if someone were to OCR it, clean up the formatting, and publish it that the result could be freely distributed?
    - jacobush 8y ago
      I guess in a fair and honest world, yes because it's legal? But in our actual world, it's also legal but publishers may play dirty and somehow claim rights because you published something based on their edition? Just thinking out loud.
  - lispm 8y ago
    > I don’t think Richard totally dislikes Common Lisp maybe not totally, but mostly. Beyond that he does not care about it and isn't interested in it.
    - kazinator 8y ago
      If you were already an "advanced Lisper" in the 1980's, Common Lisp might be something like C11 to someone who had expert C chops before even C99. I code in C regularly, yet I do not care and am not interested in C after C90. Only some library features of C99 and that's about it. Stallman's concepts of what is Lisp, how to use Lisp, how to implement Lisp, were formed long before Common Lisp. If you're in that position, it's easy to have allergic reactions to requirements you don't agree with.
      - lispm 8y ago
        Kind of surprising, since Stallman was a developer with and user of Lisp Machine Lisp, the single biggest influence of Common Lisp. Maclisp and its successor Lisp Machine Lisp, were probably his biggest influences. Emacs Lisp is based on Maclisp - without the features of Lisp Machine Lisp like keyword arguments, Flavors as the object-system, ...