From: Pierre THIERRY
Subject: Why if as special form instead of cond?
Date: 
Message-ID: <pan.2006.08.17.04.10.51.665631@levallois.eu.org>
As I've read the original paper of McCarthy on Lisp, I'm now wondering
about the rationale of if as special form and cond as a macro built on
top of it, as ti was the contrary in early Lisp. Is it because the
if-then-else scheme is used far more times then the cond one?

Curiously,
Nowhere man
-- 
···········@levallois.eu.org
OpenPGP 0xD9D50D8A

From: hayeah
Subject: Re: Why if as special form instead of cond?
Date: 
Message-ID: <1155799641.220817.156130@m79g2000cwm.googlegroups.com>
Pierre THIERRY wrote:
> As I've read the original paper of McCarthy on Lisp, I'm now wondering
> about the rationale of if as special form and cond as a macro built on
> top of it, as ti was the contrary in early Lisp. Is it because the
> if-then-else scheme is used far more times then the cond one?
>

Maybe "if" resembles machine branching.. thus "more fundamental",
thus prettier to have as a primitive?
From: Pascal Bourguignon
Subject: Re: Why if as special form instead of cond?
Date: 
Message-ID: <87y7tom19l.fsf@thalassa.informatimago.com>
Pierre THIERRY <···········@levallois.eu.org> writes:
> As I've read the original paper of McCarthy on Lisp, I'm now wondering
> about the rationale of if as special form and cond as a macro built on
> top of it, as ti was the contrary in early Lisp. Is it because the
> if-then-else scheme is used far more times then the cond one?

It doesn't make a difference.  In any case, the compiler produce the
same intermediary data structure,  before generating the binary code.
My bet is they have choosed one at head-or-cross.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.
From: Ari Johnson
Subject: Re: Why if as special form instead of cond?
Date: 
Message-ID: <87lkpnqzmd.fsf@bender.theari.com>
Pierre THIERRY <···········@levallois.eu.org> writes:

> As I've read the original paper of McCarthy on Lisp, I'm now wondering
> about the rationale of if as special form and cond as a macro built on
> top of it, as ti was the contrary in early Lisp. Is it because the
> if-then-else scheme is used far more times then the cond one?

If I had to justify choosing IF over COND as the special form, I would
say that the compiled code will end up exactly the same with any sane
compiler.  In the case of CMUCL and SBCL, for instance, the compiler
chops things up into a flow graph before doing any real work, so it
doesn't really matter whether an IF or a COND resulted in a given
branch in the graph.  However, it is less work for the person writing
the compiler to generate a flow graph when there is only one branch to
deal with at a time as with IF.

Essentially, the compiler has to look at a form and, if it is a
conditional form of any sort, generate a branch in the flow graph.
You can look at this like translating from Lisp to a flow graph.  In
that flow graph, you will have branch nodes that look very much like
IF in their semantics.  That is, they will test one thing and branch
one of two ways depending on the result of the test.  If the compiler
operates in terms of COND, it is just going to translate it into a
bunch of IF-equivalents, anyhow, so why not let higher-level macros do
the translation into IFs and spare the compiler some work?
From: Ari Johnson
Subject: Re: Why if as special form instead of cond?
Date: 
Message-ID: <87y7tnqypd.fsf@bender.theari.com>
Ari Johnson <·········@gmail.com> writes:

> Pierre THIERRY <···········@levallois.eu.org> writes:
> 
> > As I've read the original paper of McCarthy on Lisp, I'm now wondering
> > about the rationale of if as special form and cond as a macro built on
> > top of it, as ti was the contrary in early Lisp. Is it because the
> > if-then-else scheme is used far more times then the cond one?
> 
> If I had to justify choosing IF over COND as the special form, I would
> say that the compiled code will end up exactly the same with any sane
> compiler.  In the case of CMUCL and SBCL, for instance, the compiler
> chops things up into a flow graph before doing any real work, so it
> doesn't really matter whether an IF or a COND resulted in a given
> branch in the graph.  However, it is less work for the person writing
> the compiler to generate a flow graph when there is only one branch to
> deal with at a time as with IF.
> 
> Essentially, the compiler has to look at a form and, if it is a
> conditional form of any sort, generate a branch in the flow graph.
> You can look at this like translating from Lisp to a flow graph.  In
> that flow graph, you will have branch nodes that look very much like
> IF in their semantics.  That is, they will test one thing and branch
> one of two ways depending on the result of the test.  If the compiler
> operates in terms of COND, it is just going to translate it into a
> bunch of IF-equivalents, anyhow, so why not let higher-level macros do
> the translation into IFs and spare the compiler some work?

I should add one more thing.  While some early Lisps may have been
compiled, and while I was not aware of Lisp until late in its history,
I believe that interpretation was the tendency early on.  In a simple
interpreter, there is no flow-graph analysis to do and therefore it is
not any harder to handle COND than it is to handle IF.  That is, in an
interpreter, when faced with a COND, you just loop through the
arguments to COND and branch along the direction of the first one
whose CAR evaluates to a true value.  In a Lisp interpreter I wrote, I
went with COND as the special form for this reason.

However, in a compiler you don't loop through things like that, you
compile them just once.  When I wrote a compiler for the same Lisp
dialect as I'd written the interpreter I just mentioned, I stuck with
the same language facts of life such as COND being a special form, and
I did not do any advanced flow graph analysis or anything, but COND
does get translated directly into a pseudo-assembly form of a bunch of
IFs.
From: pTymN
Subject: Re: Why if as special form instead of cond?
Date: 
Message-ID: <1155824231.707226.177710@m73g2000cwd.googlegroups.com>
I like using COND. It feels like C++'s switch & if/else if/else if/else
if/else combined. It really is succinct.
From: Kaz Kylheku
Subject: Re: Why if as special form instead of cond?
Date: 
Message-ID: <1155849461.977890.252670@i3g2000cwc.googlegroups.com>
Pierre THIERRY wrote:
> As I've read the original paper of McCarthy on Lisp, I'm now wondering
> about the rationale of if as special form and cond as a macro built on
> top of it, as ti was the contrary in early Lisp. Is it because the
> if-then-else scheme is used far more times then the cond one?

Ask yourself which one is larger and more complicated?

Special forms are implemented in the interpreter or compiler core.

The code to handle the forms might not be Lisp. It could be, for
instance, assembly language. If there is a bug in a special form, you
will have to trace it down into that lower level language. When the fix
is found, you will have to rebuild the system from the ground up.

If there is a bug in a macro, you just rewrite the Lisp code for the
macro, and then reload it, and everything that depends on it, without
having to rebuild the binary image.

Would you rather write IF in assembly language and COND in Lisp? Or the
other way around?

Then there are code walking considerations. Third party code walkers
have to understand special forms. So it's desireable that the
repertoire of special forms be small and simple.

As a concrete example, let's look at a simple Lisp implementation:
Lisp500 (Lisp in 500 lines). In this tiny implementation, the IF
special form appears as a C function in the lisp500.c source file:

  lval eval_if(lval *f, lval ex) { return evca(f,
evca(f,ex)?cdr(ex):cddr(ex)); }

The code is nice and short, slickly mapping the IF logic to the C
ternary operator.

The COND form is implemented as a macro in the associated init500.lisp
file.

(defmacro cond (&rest clauses)
  (when clauses
    (if (cdar clauses)
	`(if ,(caar clauses)
	     (progn ,@(cdar clauses))
	     (cond ,@(cdr clauses)))
	`(or ,(caar clauses)
	     (cond ,@(cdr clauses))))))

Note, by the way, how the implementation of COND uses IF in its
expander, not just in the expansion.

Also note how Lisp500's implementation of COND is something you could
plonk into any Lisp implementation: it's portable! The author of
Lisp500 might just have cut and pasted it form somewhere. But you can't
just cut and paste a C implementation of it from somewhere: that has to
to be tailored to the unique Lisp500 C language guts.

As an exercise, take Lisp500 and swap these two around: take out
eval_if and write eval_cond, and make IF a macro.
From: Barry Margolin
Subject: Re: Why if as special form instead of cond?
Date: 
Message-ID: <barmar-F2CAAA.19391717082006@comcast.dca.giganews.com>
In article <······························@levallois.eu.org>,
 Pierre THIERRY <···········@levallois.eu.org> wrote:

> As I've read the original paper of McCarthy on Lisp, I'm now wondering
> about the rationale of if as special form and cond as a macro built on
> top of it, as ti was the contrary in early Lisp. Is it because the
> if-then-else scheme is used far more times then the cond one?

Maybe it's because the original Lisp was a library built on top of 
Fortran, which has a built-in IF, but no COND.

The interesting thing about this question is that MACLISP didn't have 
IF, it only had COND.  Many popular user-written macro libraries added 
IF, but there was no concensus for its syntax.  Some of the styles that 
I remember were:

(if <condition> <then> <optional-else>) -- Like CL
(if <condition> <then> <else1> <else2> ...) -- Like Emacs Lisp
(if <condition> <then1> <then2> ... else <else1> <else2> ...)

-- 
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Ken Tilton
Subject: Re: Why if as special form instead of cond?
Date: 
Message-ID: <TWaFg.1787$3G4.906@newsfe08.lga>
Barry Margolin wrote:
> In article <······························@levallois.eu.org>,
>  Pierre THIERRY <···········@levallois.eu.org> wrote:
> 
> 
>>As I've read the original paper of McCarthy on Lisp, I'm now wondering
>>about the rationale of if as special form and cond as a macro built on
>>top of it, as ti was the contrary in early Lisp. Is it because the
>>if-then-else scheme is used far more times then the cond one?
> 
> 
> Maybe it's because the original Lisp was a library built on top of 
> Fortran, which has a built-in IF, but no COND.

I don't know about that. Isn't COND why Lisp was born? McCarthy 
suggested COND for <sone other language> and when they blew him off he 
decided to go make Lisp. Could explain why...
> 
> The interesting thing about this question is that MACLISP didn't have 
> IF, it only had COND. 

kt

-- 
Cells: http://common-lisp.net/project/cells/

"I'll say I'm losing my grip, and it feels terrific."
    -- Smiling husband to scowling wife, New Yorker cartoon
From: Ken Tilton
Subject: Re: Why if as special form instead of cond?
Date: 
Message-ID: <pbbFg.1515$A%6.1267@newsfe09.lga>
Ken Tilton wrote:
> 
> 
> Barry Margolin wrote:
> 
>> In article <······························@levallois.eu.org>,
>>  Pierre THIERRY <···········@levallois.eu.org> wrote:
>>
>>
>>> As I've read the original paper of McCarthy on Lisp, I'm now wondering
>>> about the rationale of if as special form and cond as a macro built on
>>> top of it, as ti was the contrary in early Lisp. Is it because the
>>> if-then-else scheme is used far more times then the cond one?
>>
>>
>>
>> Maybe it's because the original Lisp was a library built on top of 
>> Fortran, which has a built-in IF, but no COND.
> 
> 
> I don't know about that. Isn't COND why Lisp was born? McCarthy 
> suggested COND for <sone other language> and when they blew him off he 
> decided to go make Lisp. Could explain why...

Here is something, footnote on page 3:

"I sent a proposal for conditional expressions to a CACM forum on what 
should be included in Algol 60. Because the item was short, the editor 
demoted it to a letter to the editor, for which CACM subsequently 
apologized. The notation given here was rejected for Algol 60, because 
it had been decided that no new mathematical notation should be allowed
in Algol 60, and everything new had to be English. The if . . . then . . 
. else that Algol 60 adopted was suggested by John Backus.

http://www-formal.stanford.edu/jmc/recursive.pdf#search=%22mccarthy%20cond%20lisp%22

Looks like two languages missed the boat:

"In fact, the differentiation program was not implemented that summer, 
because FLPL allows neither conditional expressions nor recursive use of 
subroutines. At this point a new language was necessary, since it was 
very difficult both technically and politically to tinker with Fortran, 
and neither conditional expressions nor recursion could be implemented 
with machine language Fortran functions - not even with ``functions'' 
that modify the code that calls them. Moreover, the IBM group seemed 
satisfied with FLPL as it was and did not want to make the vaguely 
stated but obviously drastic changes required to allow conditional 
expressions and recursive definition. As I recall, they argued that 
these were unnecessary."

http://www-formal.stanford.edu/jmc/history/lisp/node2.html

kt



-- 
Cells: http://common-lisp.net/project/cells/

"I'll say I'm losing my grip, and it feels terrific."
    -- Smiling husband to scowling wife, New Yorker cartoon