Kaz Kylheku <643-408-1753@kylheku.com> writes:

... The code is from just before MacCarthy invented the ternary IF,
as a shorthand for a one clause cond: ...

I don't think that McCarthy invented IF as an abbreviation for COND, but
I could be wrong. He certainly _could_ have invented it, but if he did,
it was forgotten by the mid 1970s. Defining IF as a _personal_ macro was
common practice for 1970s Lisp programmers, and I don't think IF was
provided as standard by _any_ major Lisp implementation at that time.
(Maybe InterLisp did? I don't recall, and I no longer have an InterLisp
manual on my bookshelf.) Scheme had IF _instead_ of COND, but nobody
was using Scheme for anything serious yet. And I don't think the T
project had started at that point.

In fact, when the Lisp Machine group decided to introduce a standard IF
macro into Lisp Machine Lisp, we were a bit worried that another
significant body of Lisp code was already using a slightly different
syntax for IF than the one we wanted to use. Multics Emacs (written in
Multics MacLisp) had popularized an IF macro that used an ELSE keyword
somehow. We negotiated a deal with the Multics guys (Bernie Greenberg)
where they agreed to change their IF to guarantee that an IF with no
ELSE keyword would work exactly the same way ours did.

This was perhaps the very beginning of the road that eventually led us
to Common Lisp. A bunch of Lisp implementations (Lisp Machine Lisp, NIL
and both branches of MacLisp) all introduced a bunch of new syntax (IF,
LET, DEFSTRUCT, SETF, backquote, sharpsign, etc.) into their standard
environment so that individual programmers and programs no longer had to
define them themselves.

But I'd love to see evidence that McCarthy arrived at ternary IF before
anyone else. He certainly invented COND, where the interesting thing
about COND was that it was an _expression_ rather than a statement, so
we often say that "McCarthy invented the conditional expression". And
sometimes that gets shortened to "McCarthy invented the if-expression".
But I don't think that he ever literally wrote "(IF ...)" rather than
"(COND ...)".

I'm not even sure that McCarthy would have seen the advantage of IF over
COND given that what he originally wanted us all to write was actually
"[expr -> expr; expr]"!

- Alan

On 2024-04-02, Alan Bawden <alan@csail.mit.edu> wrote:
> But I'd love to see evidence that McCarthy arrived at ternary IF before
> anyone else.

I seem to be aware of at least some urban legend along these lines.
From your detailed historic "been there" understanding, that's what it
must be.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2 April 2024 14:38 Alan Bawden, wrote:

> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>
> ... The code is from just before MacCarthy invented the ternary IF,
> as a shorthand for a one clause cond: ...
>
> I don't think that McCarthy invented IF as an abbreviation for COND, but
> I could be wrong. He certainly _could_ have invented it, but if he did,
> it was forgotten by the mid 1970s. Defining IF as a _personal_ macro was
> common practice for 1970s Lisp programmers, and I don't think IF was
> provided as standard by _any_ major Lisp implementation at that time.
> (Maybe InterLisp did? I don't recall, and I no longer have an InterLisp
> manual on my bookshelf.)

"If" is available in Medley, (https://interlisp.org/):

,----
| (IF X COMS₁)
|
| If [EVAL X]is true, execute COMS₁; otherwise generate an error.
`----

On 2 April 2024 14:38 Alan Bawden, wrote:

> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>
> ... The code is from just before MacCarthy invented the ternary IF,
> as a shorthand for a one clause cond: ...
>
> I don't think that McCarthy invented IF as an abbreviation for COND, but
> I could be wrong. He certainly _could_ have invented it, but if he did,
> it was forgotten by the mid 1970s. Defining IF as a _personal_ macro was
> common practice for 1970s Lisp programmers, and I don't think IF was
> provided as standard by _any_ major Lisp implementation at that time.
> (Maybe InterLisp did? I don't recall, and I no longer have an InterLisp
> manual on my bookshelf.)

"If" is available in Medley, (https://interlisp.org/):

,----
| (IF X COMS₁)
|
| If [EVAL X]is true, execute COMS₁; otherwise generate an error.
`----

* Alan Bawden <86h6gjpq3i.fsf_-_@williamsburg.bawden.org> :
Wrote on Tue, 02 Apr 2024 14:38:25 -0400:
> I don't think that McCarthy invented IF as an abbreviation for COND, but
> I could be wrong. He certainly _could_ have invented it, but if he did,
> it was forgotten by the mid 1970s. Defining IF as a _personal_ macro was
> common practice for 1970s Lisp programmers, and I don't think IF was
> provided as standard by _any_ major Lisp implementation at that time.
> (Maybe InterLisp did? I don't recall, and I no longer have an InterLisp
> manual on my bookshelf.) Scheme had IF _instead_ of COND, but nobody
> was using Scheme for anything serious yet. And I don't think the T
> project had started at that point.
>
> In fact, when the Lisp Machine group decided to introduce a standard IF
> macro into Lisp Machine Lisp, we were a bit worried that another
> significant body of Lisp code was already using a slightly different
> syntax for IF than the one we wanted to use. Multics Emacs (written in
> Multics MacLisp) had popularized an IF macro that used an ELSE keyword
> somehow. We negotiated a deal with the Multics guys (Bernie Greenberg)
> where they agreed to change their IF to guarantee that an IF with no
> ELSE keyword would work exactly the same way ours did.
>
> This was perhaps the very beginning of the road that eventually led us
> to Common Lisp. A bunch of Lisp implementations (Lisp Machine Lisp, NIL
> and both branches of MacLisp) all introduced a bunch of new syntax (IF,
> LET, DEFSTRUCT, SETF, backquote, sharpsign, etc.) into their standard
> environment so that individual programmers and programs no longer had to
> define them themselves.
>
> But I'd love to see evidence that McCarthy arrived at ternary IF before
> anyone else. He certainly invented COND, where the interesting thing
> about COND was that it was an _expression_ rather than a statement, so
> we often say that "McCarthy invented the conditional expression". And
> sometimes that gets shortened to "McCarthy invented the if-expression".
> But I don't think that he ever literally wrote "(IF ...)" rather than
> "(COND ...)".

I've forgotten the distinction between a statement and an expression in
lisp. Maybe someone can remind me. is it that IF is a special operator
but COND is a macro? From the point of view of surface syntax, aren't
they the same sort of beast? Both evaluate to a result which can be
uses elsewhere, so they can't be "statements" in the sense of other
programming languages.

> I'm not even sure that McCarthy would have seen the advantage of IF over
> COND given that what he originally wanted us all to write was actually
> "[expr -> expr; expr]"!

CLHS has

(if test-form then-form else-form)
== (cond (test-form then-form) (t else-form))

so by inventing COND he had already invented IF, and probably felt
secure enough and not compelled publish another result

Madhu <enometh@meer.net> writes:

* Alan Bawden <86h6gjpq3i.fsf_-_@williamsburg.bawden.org> :
Wrote on Tue, 02 Apr 2024 14:38:25 -0400:
> ...
> But I'd love to see evidence that McCarthy arrived at ternary IF before
> anyone else. He certainly invented COND, where the interesting thing
> about COND was that it was an _expression_ rather than a statement, so
> we often say that "McCarthy invented the conditional expression". And
> sometimes that gets shortened to "McCarthy invented the if-expression".
> But I don't think that he ever literally wrote "(IF ...)" rather than
> "(COND ...)".

I've forgotten the distinction between a statement and an expression in
lisp. Maybe someone can remind me. is it that IF is a special operator
but COND is a macro? From the point of view of surface syntax, aren't
they the same sort of beast? Both evaluate to a result which can be
uses elsewhere, so they can't be "statements" in the sense of other
programming languages.

Lisp doesn't really have statements _because_ McCarthy invented the
conditional expression. That's kind of the point. Other programming
languages at the time (e.g. FORTRAN and ALGOL) only had conditional
statements. McCarthy invented the conditional expression and thus
created the first expression-only programming language.

> I'm not even sure that McCarthy would have seen the advantage of IF over
> COND given that what he originally wanted us all to write was actually
> "[expr -> expr; expr]"!

CLHS has

(if test-form then-form else-form)
== (cond (test-form then-form) (t else-form))

so by inventing COND he had already invented IF, and probably felt
secure enough and not compelled publish another result

The original claim I was responding to was that McCarthy had invented IF
"as a shorthand for a one clause COND". That certainly wouldn't have
been worth publishing as a result in itself. But it would certainly be
possible for him to have introduced an IF shorthand _in passing_ in the
course of doing something else -- like in some Lisp code he wrote to do
something of real interest. But there seems to be no evidence for that.

To summarize:

(1) McCarthy invented the conditional expression, written in his
M-expression language as:
[expr -> expr; expr -> expr; T -> expr]

(2) McCarthy also invented the S-expression representation for that as:
(COND (expr expr) (expr expr) (T expr))

(3) But there is no evidence that McCarthy ever, for _any_ reason, ever
wrote:
(IF expr expr expr)

People sometimes sloppily say that "McCarthy invented the
if-expression", by which they really mean just (1). It is also true
that McCarthy invented (2) the COND S-expression, but there is nothing
particularly interesting about that, it was just part of the encoding he
invented for representing M-expressions as S-expressions. (For which he
also invented the LAMBDA, QUOTE and LABEL S-expressions.) But there
seems to be no evidence that McCarthy ever invented (3) an "IF
S-expression" for any reason whatsoever.

- Alan

Alan Bawden <alan@csail.mit.edu> writes:
> McCarthy invented the conditional expression and thus created the
> first expression-only programming language.

I think Church's lambda calculus also had this.

https://en.wikipedia.org/wiki/Church_encoding#Church_Booleans

On 2024-04-03, Alan Bawden <alan@csail.mit.edu> wrote:
> Lisp doesn't really have statements _because_ McCarthy invented the
> conditional expression. That's kind of the point. Other programming
> languages at the time (e.g. FORTRAN and ALGOL) only had conditional
> statements. McCarthy invented the conditional expression and thus
> created the first expression-only programming language.

However, conditional expressions ultimately come from math. E.g for
specifying a discontinuous function:

f(x) = { x, if x >= 0
{ 0, if x < 0
If you think about it, it's actually kind of ignorant to invent a
programming language with imperative if statements, but in which where
the math conditional is missing.

> People sometimes sloppily say that "McCarthy invented the
> if-expression", by which they really mean just (1). It is also true

That could be the origin of the misconception; someone is going to
take that sort of statement literally.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Paul Rubin <no.email@nospam.invalid> writes:

Alan Bawden <alan@csail.mit.edu> writes:
> McCarthy invented the conditional expression and thus created the
> first expression-only programming language.

I think Church's lambda calculus also had this.

https://en.wikipedia.org/wiki/Church_encoding#Church_Booleans

Yeah, I though about that while I was composing my previous message, but
my life is finite, so I didn't go there. But this is Usenet, so we are
forced to explore every side issue until we all drop dead of exhaustion.

So does Lambda Calculus qualify as a programming language? Well _today_
we would all say yes, because we have examples of purely functional
programming languages where evaluation is lazy and so we don't need a
special operator for conditional evaluation. But when McCarthy was
inventing Lisp, nobody thought that pure Lambda Calculus was anything
like a programming language. It's only since then that we've done the
work to make that practical.

So I _could_ argue that in 1958 Lambda Calculus was _not_ a programming
language, but today in 2024 Lambda Calculus _is_ a programming language,
even though Lambda Calculus didn't change in any way!

But given the way being a "programming language" was understood in 1958,
nobody was going to invent an expression-only programming language until
they first invented the conditional expression. So thank you John
McCarthy.

- Alan

Alan Bawden <alan@csail.mit.edu> writes:
> But when McCarthy was inventing Lisp, nobody thought that pure Lambda
> Calculus was anything like a programming language.

Ah ok, that was before my time. I had been under the impression that
Lisp had started as lambda calculus with some concessions to
practicality added.

https://en.wikipedia.org/wiki/Lisp_(programming_language)#History

gives that impression too.

> It's only since then that we've done the work to make that practical.

Does Scheme not count? I think lazy evaluation is not needed since the
input to the Church boolean (I hope I have the jargon right) is two
lambda abstractions. The boolean selects one of them, and the result is
applied to whatever the next thing is.

Kaz Kylheku <643-408-1753@kylheku.com> writes:

On 2024-04-03, Alan Bawden <alan@csail.mit.edu> wrote:
> Lisp doesn't really have statements _because_ McCarthy invented the
> conditional expression. That's kind of the point. Other programming
> languages at the time (e.g. FORTRAN and ALGOL) only had conditional
> statements. McCarthy invented the conditional expression and thus
> created the first expression-only programming language.

However, conditional expressions ultimately come from math. E.g for
specifying a discontinuous function:

f(x) = { x, if x >= 0
{ 0, if x < 0

If you think about it, it's actually kind of ignorant to invent a
programming language with imperative if statements, but in which where
the math conditional is missing.

If you think like a historian, you don't describe this as "ignorant".
It's just not something that was above the horizon in the mind set of
the time. After all, that mathematical notation you are referring to
isn't something that mathematicians get very formal about. It has a
status that's midway between being able to define something using a
simple equation, and having to resort to a definition in the form of a
paragraph of words. Realizing that you could tighten that notation up
and use it in a programming language _as a kind of expression_ is
actually a bit of a leap.

> People sometimes sloppily say that "McCarthy invented the
> if-expression", by which they really mean just (1). It is also true

That could be the origin of the misconception; someone is going to
take that sort of statement literally.

Yes, that was exactly my point.

- Alan

On 2024-04-03, Alan Bawden <alan@csail.mit.edu> wrote:
> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>
> On 2024-04-03, Alan Bawden <alan@csail.mit.edu> wrote:
> > Lisp doesn't really have statements _because_ McCarthy invented the
> > conditional expression. That's kind of the point. Other programming
> > languages at the time (e.g. FORTRAN and ALGOL) only had conditional
> > statements. McCarthy invented the conditional expression and thus
> > created the first expression-only programming language.
>
> However, conditional expressions ultimately come from math. E.g for
> specifying a discontinuous function:
>
> f(x) = { x, if x >= 0
> { 0, if x < 0
>
> If you think about it, it's actually kind of ignorant to invent a
> programming language with imperative if statements, but in which where
> the math conditional is missing.
>
> If you think like a historian, you don't describe this as "ignorant".
> It's just not something that was above the horizon in the mind set of
> the time. After all, that mathematical notation you are referring to
> isn't something that mathematicians get very formal about.

That is a fair observation; roughly speaking, higher languages first
evolved from that of the machine. Why we have an if /statement/ is that
the machine has testing and branching in its instruction set, which are
also statements. The imperative language that works by jumping around
and shuffling mainly word-sized quantities inside a Von Neumann machine
is an abstraction of machine language, not an abstraction of functions.

The abstraction of machine language isn't ignorant, it's just different.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-04-03, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
> On 2024-04-03, Alan Bawden <alan@csail.mit.edu> wrote:
>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>> If you think about it, it's actually kind of ignorant to invent a
>> programming language with imperative if statements, but in which where
>> the math conditional is missing.
>>
>> If you think like a historian, you don't describe this as "ignorant".
>> It's just not something that was above the horizon in the mind set of
>> the time. After all, that mathematical notation you are referring to
>> isn't something that mathematicians get very formal about.
>
> That is a fair observation; roughly speaking, higher languages first
> evolved from that of the machine. Why we have an if /statement/ is that
> the machine has testing and branching in its instruction set, which are
> also statements. The imperative language that works by jumping around
> and shuffling mainly word-sized quantities inside a Von Neumann machine
> is an abstraction of machine language, not an abstraction of functions.
>
> The abstraction of machine language isn't ignorant, it's just different.

But, right, okay; I lost a thoguht I had some hours earlier about this.
By the time we have a higher level language inspired by math formulas in
which you can do A * B + C, and define math-like functions, you would
think that the right synapse would fire between the right two brain
cells, so that a value-yielding conditional would be supplied. When you
have translation of arithmetic formulas to machine language, the scene
is ripe for such an operator. So maybe ignorance is a strong word, but
there is a margin for disappointment.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Alan Bawden <alan@csail.mit.edu> writes:

> Paul Rubin <no.email@nospam.invalid> writes:
>
> Alan Bawden <alan@csail.mit.edu> writes:
> > McCarthy invented the conditional expression and thus created the
> > first expression-only programming language.
>
> I think Church's lambda calculus also had this.
>
> https://en.wikipedia.org/wiki/Church_encoding#Church_Booleans
>
> Yeah, I though about that while I was composing my previous message, but
> my life is finite, so I didn't go there. But this is Usenet, so we are
> forced to explore every side issue until we all drop dead of exhaustion.
>
> So does Lambda Calculus qualify as a programming language? Well _today_
> we would all say yes, because we have examples of purely functional
> programming languages where evaluation is lazy and so we don't need a
> special operator for conditional evaluation. But when McCarthy was
> inventing Lisp, nobody thought that pure Lambda Calculus was anything
> like a programming language. It's only since then that we've done the
> work to make that practical.

Pinning down exactly constitutes a programming language is not going to
be very fruitful! But Church invented the lambda calculus to define
what "effectively computable" or "effective procedure" means. (He was
interested in the Entscheidungsproblem). Its purpose was to capture the
notion of symbolic actions that could be performed "mechanically" but
without a physical mechanism. That was the whole point. Is that a
programming language? I'll pass on that, but it's clearly a notation
for writing abstract computations.

> So I _could_ argue that in 1958 Lambda Calculus was _not_ a programming
> language, but today in 2024 Lambda Calculus _is_ a programming language,
> even though Lambda Calculus didn't change in any way!

It's more helpful, I think, to consider what McCarthy would have around
as influences. Did he know of the work by Church (and Kleene and
Rosser)? Surely he did. But Church's Booleans put a very different
spin on conditional expressions, so I say it's fair to say that what we
see in early Lisp is McCarthy's own.

--
Ben.

Alan Bawden <alan@csail.mit.edu> writes:

> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>
> On 2024-04-03, Alan Bawden <alan@csail.mit.edu> wrote:
> > Lisp doesn't really have statements _because_ McCarthy invented the
> > conditional expression. That's kind of the point. Other programming
> > languages at the time (e.g. FORTRAN and ALGOL) only had conditional
> > statements. McCarthy invented the conditional expression and thus
> > created the first expression-only programming language.
>
> However, conditional expressions ultimately come from math. E.g for
> specifying a discontinuous function:
>
> f(x) = { x, if x >= 0
> { 0, if x < 0
>
> If you think about it, it's actually kind of ignorant to invent a
> programming language with imperative if statements, but in which where
> the math conditional is missing.
>
> If you think like a historian, you don't describe this as "ignorant".
> It's just not something that was above the horizon in the mind set of
> the time. After all, that mathematical notation you are referring to
> isn't something that mathematicians get very formal about.

So true.

> It has a status that's midway between being able to define something
> using a simple equation, and having to resort to a definition in the
> form of a paragraph of words. Realizing that you could tighten that
> notation up and use it in a programming language _as a kind of
> expression_ is actually a bit of a leap.

There's a paper from 1961--1963 in which he defines the conditional
expression with the intention of being able to define functions
recursively.

--8<---------------cut here---------------start------------->8---
A BASIS FOR A MATHEMATICAL THEORY OF COMPUTATION
JOHN McCARTHY
1961--1963

[This 1963 paper was included in Computer Programming and Formal Sys-
tems, edited by P. Braffort and D. Hirshberg and published by
North-Holland. An earlier version was published in 1961 in the
Proceedings of the Western Joint Computer Conference.]

[...]

The present paper is an attempt to create a basis for a mathematical
theory of computation. [...]

[...]

2.1 Functions Computable in Terms of Given Base Functions

Suppose we are given a base collection F of functions (including
predicates) having certain domains and ranges. [...] Our object is to
define a class of functions C{F} which we shall call the class of
functions computable in terms of F. Before developing C{F} formally,
we wish to give an example, and in order to give the example, we first
need the concept of conditional expression. In our notation a
conditional expression has the form

(p1 → e1, p2 → e2, . . . , pn → en)

which corresponds to the ALGOL 60 reference language (12) expression

if p1 then e1 else if p2 then e2 . . . else if pn then en.

[...]

Some examples of the conditional expressions for well known functions
are |x| = (x < 0 → -x, x >= 0 → x) [...]

Now we are ready to use conditional expressions to define functions
recursively. For example, we have

n! = (n = 0 → 1, n =/= 0 → n · (n − 1)!)

[...]
--8<---------------cut here---------------end--------------->8---

Kaz Kylheku <643-408-1753@kylheku.com> writes:

> On 2024-04-03, Kaz Kylheku <643-408-1753@kylheku.com> wrote:
>> On 2024-04-03, Alan Bawden <alan@csail.mit.edu> wrote:
>>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>> If you think about it, it's actually kind of ignorant to invent a
>>> programming language with imperative if statements, but in which where
>>> the math conditional is missing.
>>>
>>> If you think like a historian, you don't describe this as "ignorant".
>>> It's just not something that was above the horizon in the mind set of
>>> the time. After all, that mathematical notation you are referring to
>>> isn't something that mathematicians get very formal about.
>>
>> That is a fair observation; roughly speaking, higher languages first
>> evolved from that of the machine. Why we have an if /statement/ is that
>> the machine has testing and branching in its instruction set, which are
>> also statements. The imperative language that works by jumping around
>> and shuffling mainly word-sized quantities inside a Von Neumann machine
>> is an abstraction of machine language, not an abstraction of functions.
>>
>> The abstraction of machine language isn't ignorant, it's just different.
>
> But, right, okay; I lost a thoguht I had some hours earlier about this.
> By the time we have a higher level language inspired by math formulas in
> which you can do A * B + C, and define math-like functions, you would
> think that the right synapse would fire between the right two brain
> cells, so that a value-yielding conditional would be supplied. When you
> have translation of arithmetic formulas to machine language, the scene
> is ripe for such an operator. So maybe ignorance is a strong word, but
> there is a margin for disappointment.

But it's not the same disappointment as in having to use JIRA, right? :-)

``Writing bug reports on napkins and keeping them crumpled in a large
black garbage bag is better than this fucking piece of crap called
JIRA.'' -- Kaz Kylheku, 2016.

(*) Full source

--8<---------------cut here---------------start------------->8---
X-Received: by 10.200.47.116 with SMTP id k49mr3706471qta.61.1474251695757;
Sun, 18 Sep 2016 19:21:35 -0700 (PDT)
X-BeenThere: comp.programming@googlegroups.com
Received: by 10.157.2.1 with SMTP id 1ls4320407otb.4.gmail; Sun, 18 Sep 2016
19:21:33 -0700 (PDT)
X-Received: by 10.157.2.104 with SMTP id 95mr3727234otb.133.1474251693667;
Sun, 18 Sep 2016 19:21:33 -0700 (PDT)
MIME-Version: 1.0
Path: b4ni5152iti.0!nntp.google.com!news.glorb.com!2.us.feeder.erje.net!feeder.erje.net!1.eu.feeder.erje.net!enother.net!enother.net!news.mixmin.net!aioe.org!.POSTED!not-for-mail
From: Kaz Kylheku <221-50...@kylheku.com>
Newsgroups: alt.comp.os.linux,comp.programming,comp.software-eng
Subject: Re: Favourite Software Development Tools for Teams?
Followup-To: comp.programming
Date: Mon, 19 Sep 2016 02:21:29 +0000 (UTC)
Organization: Aioe.org NNTP Server
Lines: 11
Message-ID: <20160918192003.449@kylheku.com>
References: <E9HDz.15308$LX2.8752@fx36.iad>
NNTP-Posting-Host: OGJi3KNpFOhM58UHZwXj0w.user.gioia.aioe.org
X-Complaints-To: ab...@aioe.org
User-Agent: slrn/pre1.0.0-18 (Linux)
X-Notice: Filtered by postfilter v. 0.8.2

["Followup-To:" header set to comp.programming.]
On 2016-09-19, Triscal Islington <trust.your...@mail.ru> wrote:
> I'm finally heading my own software engineering project at work and,
> since I call the shots, it's up to me to decide on what collaboration
> and review tools we utilize on the project.
>
> I'm pretty well decided on git for source code management but what are
> your favourite linux tool for bug tracking, code review, collaboration, etc?

Writing bug reports on napkins and keeping them crumpled in a large
black garbage bag is better than this fucking piece of crap called JIRA.
--8<---------------cut here---------------end--------------->8---

On Wed, 03 Apr 2024 14:15:14 -0400, Alan Bawden wrote:

> Other programming languages at the time (e.g. FORTRAN and ALGOL) only
> had conditional statements.

Algol60 had if-expressions, e.g.

a := if b then c else d

Fortran had loop expressions, but they were only allowed in I/O
statements.

On Wed, 03 Apr 2024 15:29:52 -0700, Paul Rubin wrote:

> I think lazy evaluation is not needed since the
> input to the Church boolean (I hope I have the jargon right) is two
> lambda abstractions. The boolean selects one of them, and the result is
> applied to whatever the next thing is.

I use this in Python, to try to avoid that abortion that is the Python
conditional expression. Instead of, say,

a = x / y if y != 0 else 0

I would do

a = (lambda : 0, lambda : x / y)[y != 0]()

Paul Rubin <no.email@nospam.invalid> writes:

Alan Bawden <alan@csail.mit.edu> writes:
> But when McCarthy was inventing Lisp, nobody thought that pure Lambda
> Calculus was anything like a programming language.

Ah ok, that was before my time. I had been under the impression that
Lisp had started as lambda calculus with some concessions to
practicality added.

https://en.wikipedia.org/wiki/Lisp_(programming_language)#History

gives that impression too.

It's a common misconception that McCarthy was trying to turn Lambda
Calculus into a programming language. But if you read what he was
writing at the time you will find that he was actually trying to turn
First Order Predicate Calculus (FOPC, i.e. Mathematical Logic) into a
programming language. He added LAMBDA (and LABEL) because he needed
LAMBDA in order to define recursive functions, but as he himself often
admitted, he didn't really understand Lambda Calculus, he just needed
the notation. He _did_ understand FOPC.

Once you understand his true goal, a lot of history becomes more clear.
For example, it explains why McCarthy often talked about conditional
expressions as such an important idea, while he devoted much less ink to
lambda expressions. From our point of view it's clear that adding
LAMBDA to a programming language was more significant then adding COND,
but that's not how he saw things at the time.

It also explains how Common Lisp wound up being a Lisp-2. We have
separate namespaces for functions and values because that's how FOPC
works, so that's how Lisp 1.5 was supposed to work. (It doesn't
_actually_ work that way, but it's clear from the manual that that's how
you're supposed to think about it!) Most Lisps followed Lisp 1.5 down
that path.

> It's only since then that we've done the work to make that practical.

Does Scheme not count? I think lazy evaluation is not needed since the
input to the Church boolean (I hope I have the jargon right) is two
lambda abstractions. The boolean selects one of them, and the result is
applied to whatever the next thing is.

When I wrote "make that practical" I was referring to using Lambda
Calculus _directly_ as a practical programming language. And no, I
don't think that Scheme lets you do that. Even ignoring how
inconvenient it would be to wrap lambdas around both arms of all your
conditionals, the big problem is what do you do about side effects like
I/O? You really need Monads (or something like them) in order to make
that work, and it wasn't until sometime in the 1980s that anybody
figured that out. And I'm not even sure that Haskel (for example)
counts as using Lambda Calculus directly as a programming language. It
seems like there are a lot of ideas knocking around in Haskel that are
well beyond what Church invented!

But all this happened well after McCarthy developed Lisp. If you had
told anyone in 1960 that they should look to Lambda Calculus for useful
insights into how to design a programming language, they probably would
have thought it was just about as relevant as Turing Machines are to
designing actual computing hardware -- perhaps not completely
irrelevant, but not a very practical.

- Alan

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Wed, 03 Apr 2024 14:15:14 -0400, Alan Bawden wrote:

> Other programming languages at the time (e.g. FORTRAN and ALGOL) only
> had conditional statements.

Algol60 had if-expressions, e.g.

a := if b then c else d

Ah yes, the history is slightly more complicated than I remembered.
Algol 58 did not have conditional expressions. But McCarthy then joined
the Algol committee and he suggested that they add conditional
expressions. And so they do appear in Algol 60.

- Alan

On 2024-04-04, Alan Bawden <alan@csail.mit.edu> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
> On Wed, 03 Apr 2024 14:15:14 -0400, Alan Bawden wrote:
>
> > Other programming languages at the time (e.g. FORTRAN and ALGOL) only
> > had conditional statements.
>
> Algol60 had if-expressions, e.g.
>
> a := if b then c else d
>
> Ah yes, the history is slightly more complicated than I remembered.
> Algol 58 did not have conditional expressions. But McCarthy then joined
> the Algol committee and he suggested that they add conditional
> expressions. And so they do appear in Algol 60.

Aha, that could also be the source of the idea that MacCarthy came up
with the ternary IF. (Is it documented whether he actually suggested the
three-operand one, or something more COND like that the committee
whittled down to the above form?)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-04-02, Alan Bawden <alan@csail.mit.edu> wrote:
> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>
> ... The code is from just before MacCarthy invented the ternary IF,
> as a shorthand for a one clause cond: ...
>
> I don't think that McCarthy invented IF as an abbreviation for COND, but
> I could be wrong.

OK, I found the smoking gun. Why, it's under our noses: Maccarthy's
February 1979 "History of Lisp" paper.

http://jmc.stanford.edu/articles/lisp/lisp.pdf

(Don't try HTTPS, it doesn't resolve to the PDF. There may be other
hostings of it.)

Quote:

I invented conditional expressions in connection with a set of chess
legal move routines I wrote in FORTRAN for the IBM 704 at M.I.T.
during 1957-58. This program did not use list processing. The IF
statement provided in FORTRAN 1 and FORTRAN 2 was very awkward to use,
and it was natural to invent a function XIF(M,N1,N2) whose value was
N1 or N2 according to whether the expression M was zero or not. The
function shortened many programs and made them easier to understand,
but it had to be used sparingly, because all three arguments had to be
evaluated before XIF was entered, since XIF was called as an ordinary
FORTRAN function though written in machine language. This led to the
invention of the true conditional expression which evaluates only one
of N1 and N2 according to whether M is true or false and to a desire
for a programming language that would allow its use.

A paper defining conditional expressions and proposing their use in
Algol was sent to the Communications of the ACM but was arbitrarily
demoted to a letter to the editor, because it was very short.

There you go; no hallucination or urban legends. Now, this does not
establish that MacCarthy ever worked with (if A B C) in Lisp. But
that is just a variation on the same idea; a footnote, if you will.

MacCarthy used XIF(A, B, C), in his own words, to shorten many programs,
and make them easier to understand, in his own words. (In Lisp, we
can use IF to shorten programs that use COND!)

The part about the "desire for a programming language that would allow
its use" is also important; his inclusion of a conditional in Lisp can
be traced to these thoughts, which have their origin in working with
a three-argument form, and desire to have it with the right evaluation
semantics.

As for Fortran, it eventually caved in and got a conditional operator.
In the year 2021!!! https://j3-fortran.org/doc/year/21/21-157r2.txt

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> I use this in Python, to try to avoid that abortion that is the Python
> conditional expression. Instead of, say,
>
> a = x / y if y != 0 else 0
>
> I would do
>
> a = (lambda : 0, lambda : x / y)[y != 0]()

Do you use this in real code?

Apart from my stomach revolting against this (interesting!) construct, I
am in fact surprised that it works: I did not know that tuples can be
indexed by boolean values (feels C-like). I am also surprised that True
"equals" to 1 in this context and False to 0 (rather not C-like).

Could you please give some pointers about the rationale (or further
documentation) here?

Best regards

Axel

On Thu, 04 Apr 2024 08:34:54 +0200, Axel Reichert wrote:

> Could you please give some pointers about the rationale (or further
> documentation) here?

It also generalizes to a switch-expression. Languages nowadays commonly
have switch-statements, but switch-expressions are rarer. Also they are
invariably of the labelled form, while earlier languages (like Algol 68)
had the unlabelled form. My technique for switch-expressions supports both
forms.

Have a look at the “Simple Code-Shortening Idioms” notebook in this
collection <https://gitlab.com/ldo/python_topics_notebooks/>.

Axel Reichert <mail@axel-reichert.de> writes:
> I am also surprised that True "equals" to 1 in this context and False
> to 0 (rather not C-like).

There is a hacky thing with that, because the boolean type wasn't added
to Python til fairly late in its history.

> Could you please give some pointers about the rationale (or further
> documentation) here?

For a long time the Python developers refused to have a conditional
expression in the language, preferring the kludgy

a = y and x/y

or other bug-prone hacks of that sort. The danger was that all sorts of
null values such as 0, 0.0, None, the empty list, all are treated as
false for boolean expression purposes, so you could end up getting
fooled by one of those cases. The hack with lambdas was a way to
express the actually desired behaviour though I didn't realize anyone
used it in practice.

Later, the Python interpreter itself fell fictim to such a bug, and
that's when the conditional expression finally got accepted.

I use Python all the time and it is very pleasant, but very often its
decisions are initially driven by what is convenient to implement in
CPython (the reference interpreter, written in C). So various kludgy
practices develop that often must be cleaned up sometime later.