6 ms·

From the comments to the article: > If Emacs adopted one of the proposals to use a standard Lisp dialect That should be 'if Emacs adopted the standard Lisp di

by zeveb 10y ago

From the comments to the article: > If Emacs adopted one of the proposals to use a standard Lisp dialect That should be 'if Emacs adopted the standard Lisp dialect.' There's only one standard Lisp, and that's Common Lisp[1][2]. I do indeed think that it would be wonderful if the elisp engine were reimplemented in Lisp, but it's a tremendous amount of work, with a lot of potential incompatibilities in the short term, with very little to show until the long term. [1] That doesn't mean that other Lisp-like languages aren't awesome. Racket, in particular, leaps to mind as something which is massively cool. Clojure isn't to my taste, but I can understand why some folks like it. Scheme has its virtues too. But none of them is Lisp, unlike elisp, which really is a Lisp. [2] There are also EuLisp & ISLISP, but they're effectively dead.

AceJohnny2 10y ago
I've been using Emacs for over a decade now. Every now and then (say, once a week), I feel the need to fiddle with some ELisp code. I read Stevey's Emergency Elisp guide: http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html I reached the part about the then clause of if/then/else needing a (progn ...) if it was to be a multi-statement clause, but the else clause doesn't. But you can avoid the progn if you don't have an else clause by using when instead of if! I facepalmed so hard I needed reconstructive surgery. I haven't fully recovered from that. (in reality it's because, though ELisp itself is bad enough, Emacs' API is daunting)
- qwertyuiop924 10y ago
  That's common in Lisps. Just use cond and when if it bothers you.
  - AceJohnny2 10y ago
    Why do Lisps separate these related semantics? Are there implementation reasons, or is it mostly "the way it's always been"? Edit: thanks folks! You've helped me get over the facepalm from years ago :)
    - foldr 10y ago
      I'm confused by this question. What would the alternative be?
      - AceJohnny2 10y ago
        Just if (or cond), no alternative-form when or cond (resp. if)
        hibbelig 10y ago
        The alternative forms are just syntactic sugar. Don't you like sugar? (But the basic form is "cond".) (In C, you can say "x = x + 1" or "x += 1" or "x++", where the first one is enough. Still I like having the other two.)
    - qwertyuiop924 10y ago
      Firstly, because the way Lisp is structured makes it impractical to have implicit progn (or implicit begin in the schemes) in if. Secondly, because lisp, while not a functional language, has functional leanings: you would be surprised how often it is that one form is all you need.
      - lispm 10y ago
        Well, Common Lisp has such a construct built in: CL-USER 48 > (LOOP REPEAT 2 FOR number = (READ) IF (> number 0) DO (princ '(the number is larger than 0)) (print 'true) (terpri) ELSE DO (princ '(the number is not larger than 0)) (print 'false) (terpri)) 2 (THE NUMBER IS LARGER THAN 0) TRUE -2 (THE NUMBER IS NOT LARGER THAN 0) FALSE NIL It is also not that difficult to write a multi-expression IF. Here is a sketch: (defmacro if* (cond &rest conseq) (let ((p cond) (thenpos (position 'then conseq)) (elsepos (position 'else conseq))) (cond ((and thenpos elsepos) `(if ,p (progn ,@(subseq conseq (1+ thenpos) elsepos)) (progn ,@(subseq conseq (1+ elsepos))))) (thenpos `(when ,p ,@(subseq conseq (1+ thenpos)))) (elsepos `(unless ,p ,@(subseq conseq (1+ elsepos))))))) Then we can write: (if* (> pi 0) then (print 'a) (print 'b) else (print 'c) (print 'd)) and (if* (> pi 0) then (print 'a) (print 'b)) and (if* (> pi 0) else (print 'a) (print 'b))
- hibbelig 10y ago
  It's just a consequence of the Lisp syntax: (if COND THEN ELSE), so this list has four elements, and the second is the condition, the third is one leg, and the last is the other leg. How would you make the "THEN" part longer, except by wrapping parens around it? To use a metaphor: In typical infix languages, I can only add two numbers, not three. Why do I need to do strange things like using two plus signs as in "3 + 4 + 5" to add three numbers? Lisp can do it with one: (+ 3 4 5) The answer to this metaphor is that the very idea of infix results in this limit. In the same way, the very idea of expressing everything as s-expressions results in that limitation.
- akkartik 10y ago
  You might be interested in this ancient discussion on the Arc Forum about the benefits and drawbacks of Lisp conditionals: http://arclanguage.org/item?id=18218 http://arclanguage.org/item?id=18218
qwertyuiop924 10y ago
>There's only one standard Lisp, and that's Common Lisp That isn't true. Scheme is a Lisp. Why would think otherwise? Is it because nil != false? Even McCarthy admitted that that was a random decision, and possibly a mistake. Is it because it hasn't got "proper" macros? That's a common misconception, but it's not true: all but the most minimal implementations provide an imperative macro system. Is it because it's lisp-1? Many lisps have been. Is it because they have different histories? Because that's not true. Both came out of MIT. Many people were on both standardization communities then, and many people are active in both communities now. The first Scheme was written in MACLisp, for crying out loud.
- zeveb 10y ago
  > Is it because nil != false? Even McCarthy admitted that that was a random decision, and possibly a mistake. I think that code written where NIL is the sole false value tends to read better than code with a distinguished false value, but I'm open to the idea that uglier code is more reliable. > That's a common misconception, but it's not true: all but the most minimal implementations provide an imperative macro system. But they're not standardised. The manner in which they affect the runtime environment is not standardised. It's just not a sound basis for a portable project: in practise any large software project will run not on Scheme but on Guile Scheme, or Chicken Scheme. > Is it because it's lisp-1? Many lisps have been. Only mistakenly. I used to think that Lisp-1 is better: after all, I'm used to other languages like C or JavaScript where functions and variables share the same namespace. I've come to realise that 'because C & JavaScript do it' is hardly sufficient for something to be good grin It turns out that the multiple namespaces of Lisp are extremely useful for industrial-strength software. > Many people were on both standardization communities then Sure, there's lots of cross-pollination between Lisp & Scheme, because they are both good languages. I don't dislike Scheme: in its place, it's a very interesting way to learn certain concepts. It's Lisp-like, which means it's certainly not all bad. But it's not an actual descendant of a Lisp: it's its own independent language. It has flaws (continuations which make UNWIND-PROTECT impossible; nil ≠ #f; Lisp-1; worst of all: it's under-specified), but it's not bad. The world would probably be a worse place if there were no Scheme in it. But I think that emacs would be worse if it were implemented in Scheme rather than Lisp.

by zeveb 10y ago

AceJohnny2 10y ago

I've been using Emacs for over a decade now. Every now and then (say, once a week), I feel the need to fiddle with some ELisp code. I read Stevey's Emergency Elisp guide: http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html I reached the part about the then clause of if/then/else needing a (progn ...) if it was to be a multi-statement clause, but the else clause doesn't. But you can avoid the progn if you don't have an else clause by using when instead of if! I facepalmed so hard I needed reconstructive surgery. I haven't fully recovered from that. (in reality it's because, though ELisp itself is bad enough, Emacs' API is daunting)

qwertyuiop924 10y ago
That's common in Lisps. Just use cond and when if it bothers you.
- AceJohnny2 10y ago
  Why do Lisps separate these related semantics? Are there implementation reasons, or is it mostly "the way it's always been"? Edit: thanks folks! You've helped me get over the facepalm from years ago :)
  - foldr 10y ago
    I'm confused by this question. What would the alternative be?
    - AceJohnny2 10y ago
      Just if (or cond), no alternative-form when or cond (resp. if)
      - hibbelig 10y ago
        The alternative forms are just syntactic sugar. Don't you like sugar? (But the basic form is "cond".) (In C, you can say "x = x + 1" or "x += 1" or "x++", where the first one is enough. Still I like having the other two.)
  - qwertyuiop924 10y ago
    Firstly, because the way Lisp is structured makes it impractical to have implicit progn (or implicit begin in the schemes) in if. Secondly, because lisp, while not a functional language, has functional leanings: you would be surprised how often it is that one form is all you need.
    - lispm 10y ago
      Well, Common Lisp has such a construct built in: CL-USER 48 > (LOOP REPEAT 2 FOR number = (READ) IF (> number 0) DO (princ '(the number is larger than 0)) (print 'true) (terpri) ELSE DO (princ '(the number is not larger than 0)) (print 'false) (terpri)) 2 (THE NUMBER IS LARGER THAN 0) TRUE -2 (THE NUMBER IS NOT LARGER THAN 0) FALSE NIL It is also not that difficult to write a multi-expression IF. Here is a sketch: (defmacro if* (cond &rest conseq) (let ((p cond) (thenpos (position 'then conseq)) (elsepos (position 'else conseq))) (cond ((and thenpos elsepos) `(if ,p (progn ,@(subseq conseq (1+ thenpos) elsepos)) (progn ,@(subseq conseq (1+ elsepos))))) (thenpos `(when ,p ,@(subseq conseq (1+ thenpos)))) (elsepos `(unless ,p ,@(subseq conseq (1+ elsepos))))))) Then we can write: (if* (> pi 0) then (print 'a) (print 'b) else (print 'c) (print 'd)) and (if* (> pi 0) then (print 'a) (print 'b)) and (if* (> pi 0) else (print 'a) (print 'b))
hibbelig 10y ago
It's just a consequence of the Lisp syntax: (if COND THEN ELSE), so this list has four elements, and the second is the condition, the third is one leg, and the last is the other leg. How would you make the "THEN" part longer, except by wrapping parens around it? To use a metaphor: In typical infix languages, I can only add two numbers, not three. Why do I need to do strange things like using two plus signs as in "3 + 4 + 5" to add three numbers? Lisp can do it with one: (+ 3 4 5) The answer to this metaphor is that the very idea of infix results in this limit. In the same way, the very idea of expressing everything as s-expressions results in that limitation.
akkartik 10y ago
You might be interested in this ancient discussion on the Arc Forum about the benefits and drawbacks of Lisp conditionals: http://arclanguage.org/item?id=18218 http://arclanguage.org/item?id=18218

qwertyuiop924 10y ago

>There's only one standard Lisp, and that's Common Lisp That isn't true. Scheme is a Lisp. Why would think otherwise? Is it because nil != false? Even McCarthy admitted that that was a random decision, and possibly a mistake. Is it because it hasn't got "proper" macros? That's a common misconception, but it's not true: all but the most minimal implementations provide an imperative macro system. Is it because it's lisp-1? Many lisps have been. Is it because they have different histories? Because that's not true. Both came out of MIT. Many people were on both standardization communities then, and many people are active in both communities now. The first Scheme was written in MACLisp, for crying out loud.

zeveb 10y ago
> Is it because nil != false? Even McCarthy admitted that that was a random decision, and possibly a mistake. I think that code written where NIL is the sole false value tends to read better than code with a distinguished false value, but I'm open to the idea that uglier code is more reliable. > That's a common misconception, but it's not true: all but the most minimal implementations provide an imperative macro system. But they're not standardised. The manner in which they affect the runtime environment is not standardised. It's just not a sound basis for a portable project: in practise any large software project will run not on Scheme but on Guile Scheme, or Chicken Scheme. > Is it because it's lisp-1? Many lisps have been. Only mistakenly. I used to think that Lisp-1 is better: after all, I'm used to other languages like C or JavaScript where functions and variables share the same namespace. I've come to realise that 'because C & JavaScript do it' is hardly sufficient for something to be good grin It turns out that the multiple namespaces of Lisp are extremely useful for industrial-strength software. > Many people were on both standardization communities then Sure, there's lots of cross-pollination between Lisp & Scheme, because they are both good languages. I don't dislike Scheme: in its place, it's a very interesting way to learn certain concepts. It's Lisp-like, which means it's certainly not all bad. But it's not an actual descendant of a Lisp: it's its own independent language. It has flaws (continuations which make UNWIND-PROTECT impossible; nil ≠ #f; Lisp-1; worst of all: it's under-specified), but it's not bad. The world would probably be a worse place if there were no Scheme in it. But I think that emacs would be worse if it were implemented in Scheme rather than Lisp.