Hacker News Reader

Comment by AceJohnny2 | Hacker News Reader

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

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)

View on HN

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.

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

That's common in Lisps. Just use cond and when if it bothers you.

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 :)

cond actually is a predecessor of if/else you know from other languages. Yes, it was first. As for progn, it's pretty much the equivalent of curly braces from C-like languages (or of the comma operator, if you care about its value).

Why if seems to be commonly defined as (condition then-clause &rest else-clauses) instead of (condition then-clause else-clause), I don't know. History/common use patterns, probably?

> Why do Lisps separate these related semantics?

It's not really separating related semantics; it's that an if-then-else option has to have both a then clause and and else clause. (IF then else) is a natural way to express that, but it does mean that if you want to do more than one thing in the then clause then you'll need to have a PROGN. You could have multiple statements in the else clause (which is what emacs does).

In Common Lisp, the syntax is:

    if test-form then-form [else-form] => result*

In emacs, it's:

     if test-form then-form [else-form]* => result*

I think that the emacs form is weird and annoying, but might make certain forms of code easier (e.g. check for something and short-circuit, else calculate something more deeply).

COND is a different beast entirely.

Note that WHEN & UNLESS both have an implicit PROGN.

OK, so the weirdness is really that Emacs' else-form accepts multiple statements, and/or that there is no implicit progn for both then-form and else-form.

I.e, I would've expected something like this:

    (if (condition)
      (
         (then do something)
         (and more things)
      )
      (
         (else do something else)
         (and more other things)
      )
    )

(and yeah, I'm definitely showing my C-semantic preferences here aren't I?)

Yup. And the reason not to default to a list of then-forms and a list of else-forms is partly æsthetic, but partly dealing with the common case, because:

    (if (eq foo bar) (baz))

looks like a function call, not returning the value of baz (using your syntax).

And of course Lisp is often written in a semi-functional way, so PROGN is, while not rare or really even avoided, not the usual way of doing things, usually.

That's closer to cond:

  (cond
    (<condition1> <body>*)
    (<condition2> <body>*)
    (else <body>))

Not in Common Lisp, that: else is just a variable reference here. Unbound, if you're lucky; bound to a true value if you're somewhat less lucky, and bound to nil if you're haplessly unfortunate. :)

Ah. I forgot about that.

See, this is what happens when you know Scheme better than CL.

There cannot be an implicit progn for both! Because we don't know where one ends and the other begins.

That is, unless we introduce a signal, like an else keyword/label which separates them, like this:

  (if cond form form form
      else form form form)

Such macros have existed. A certain John Foderaro of Franz, Inc. was (is?) known for favoring and promoting his if{star} macro. (Of course I mean asterisk by {star} which HN won't let me type).

Info here:

http://franz.com/~jkf/coding_standards.html

http://franz.com/support/documentation/6.0/doc/operators/exc...

Your idea is certainly doable:

  (my-if cond
    (then-form then-form ...)
    (else-form else-form ...))

The macro is trivial:

  (defmacro my-if (cond then-forms &optional else-forms)
    `(if ,cond
       (progn ,@then-forms)
       (progn ,@else-forms)))

I've always resisted writing this macro because I felt it has a slight readability issue:

  (my-if (some condition)
    ((consequent)
     (consequent2)
     (consequent3))
    ((alternative) ;; relatively quiet signal here
     (alternative)))

Maybe it's not that bad, after all. Still, it's just saving a few keystrokes to insert progn and doesn't buy much over cond, which is more general, allowing multiple conditions:

  (cond
    ((some condition)
       (consequent)
       (consequent2)
       (consequent3))
    ((other condition)
       (other)
       (other2))
    (t (alternative)
       (alternative)))

NOTE: cond existed in Lisp first, as a special form. The if macro came later as a syntactic sugar for simple situations involving just one condition!

The thing is that if you keep most of your code functional, a lot of this is moot. We need multiple statements when we are doing something imperative. There is never any reason to have (progn S1 S2) unless S1 has a side effect. If S1 has no side effect, then this is equivalent to (progn S2), which is just S2. If you avoid side effects, the you don't need any progn most of the time (implicit or not).

This is why progn is called what it is; it's Lisp's feature for writing a "program" (in the sense of an imperative list of things to do). Well, "prog" is that feature; and "progn" is the variant which returns the value of the n-th form.

Another mitigation is that lot of the time code binds variables anyway with a let:

  (if condition
    (let (... vars ...)
      this
      that)
    (let (.... other vars ...)
      other))

It's very tempting to write:

(if a (something because of a) (something more because of a))

Requiring a progn for the else clause means that the above is caught by the compiler.

That is true, but somewhat alleviated by Emacs' choice to indent the THEN form at a different level than [ELSE]*. A novice would notice that the code looks incorrect as they were typing it.

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.

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))

If it's part of LOOP, than it's not part of the language, now is it?

Well, it is, but you can't do it in the general case.

You can define a macro for it, though.

I'm confused by this question. What would the alternative be?

Just if (or cond), no alternative-form when or cond (resp. if)

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.)

Reply on news.ycombinator.com