<p>The <a href="http://en.wikipedia.org/wiki/ISWIM" rel="nofollow">wikipedia</a> page for ISWIM says that it is a higher-order language, and that ISWIM is syntactic sugar for the $\lambda$-calculus. </p>

<p>Although it seems to have no explicit $\lambda$ construct, thereby making it impossible to have anonymous functions, one achieves the same expressive power by combining lexical scoping and first-class functions: Define a new name  for a function locally; pass function as value to higher-order function.</p>

CC BY-SA 3.0
2013-07-18T08:37:59.213Z
Thanks for the answer, Dave.  So it seems Landin was promoting a more mathematical-style of programming.  In mathematics, we do not have $\lambda$ but we do have higher-order functions.
day
CC BY-SA 4.0
2024-02-28T20:23:13.750Z
@Dave Clarke, others@Dave Clarke, others  I think the bigger reason against direct lambda-abstraction is that you need a way to deal with recursion that is not so tricky as the Y combinator.  If your read Landin's papers on things like program points, you'll see lambda abstractions are heavily used, also over tuples, in defining the semantics of the SECD machine.
orcmid
CC BY-SA 3.0
2013-07-15T19:27:49.120Z
2013-07-15T19:27:49.120Z
Dave Clarke
<p>I was around when ISWIM was being formulated, including an implementation project on the Univac 1107 in the mid 1960s.  It never struck me that there were no anonymous functions.  But functions were first class in the sense that they can be returned as results of other functions.  And expressions can produce them, but the expression used a name, even if just to get the function defined, say in a parameter expressions, something like</p>
<p>fx(p1 where p1(i) = 2*i-3)</p>
<p>or something more elaborate.</p>
<p>I think we were so enamored of the expression formulations with <strong>let</strong> and <strong>where</strong> that we didn't think of bare anonymous functions.  Also, function definitions were not recursive by default, so it took something not quite like <strong>label</strong> to get that done.</p>

CC BY-SA 4.0
2024-02-27T09:05:44.427Z
Do you know whether one can get hold of an ISWIM implementation nowadays?
Andrej Bauer
CC BY-SA 4.0
2024-02-27T15:35:22.953Z
https://www.google.com/search?q=iswim+implementation there seems to be a few.
winitzki
CC BY-SA 4.0
2024-02-27T20:56:45.880Z
https://github.com/jeapostrophe/iswim
Max New
CC BY-SA 4.0
2024-02-28T11:42:03.150Z
@orcmid The Wikipedia page https://en.wikipedia.org/wiki/ISWIM is a bit ambiguous but claims it was implemented. Maybe you can correct this?
Martin Berger
CC BY-SA 4.0
2024-02-28T15:42:06.057Z
@Martin No, the wikipedia article says it was not implemented, although it may have inspired some other work.  The Univac 1107 implementation was not completed.  the PAL language at MIT had some of the syntactic forms, it was devised by Art Evans while Peter Landin was there before returning to the UK.  PAL did not use the SECD machine as far as I know.  It broke the spirit in any case: LET was a variable declaration and assignment statement.
orcmid
CC BY-SA 4.0
2024-02-28T15:58:21.013Z
@AndrejBauer I am not aware of any extant ISWIM implementation, unless Landin continued the work after he returned to the UK.  There is a description of the SECD machine in Bill Burge's "Recursive Programming Techniques" book although, for some reason, he does not refer to the Next 700 paper; he cites Landin's earlier "Mechanical Evaluation of Expressions" (MEE) paper.
orcmid
CC BY-SA 4.0
2024-02-28T16:02:29.943Z
@AndrejBauer I suspect that ML is the closest as an implementation and dealt with types and type inference in ways that Landin might not have dug into while in the US.  The SECD machine is very costly if you allow assignment, although there are other ways to have stateful entities that don't break the model.  (In ML, there is a punt/hack about assignment, but F# compute expressions may do the job, although F# is built on a mutable storage model.)  The folks at Cambridge doing functional-programming work might have better recent information.
orcmid
CC BY-SA 4.0
2024-02-28T16:08:02.873Z
Thanks, I was mostly asking for historical reasons to see whether some archeological artefacts may still be around.
Andrej Bauer
CC BY-SA 4.0
2024-02-28T17:05:04.780Z
@AndrejBauer It's nice to hear from you regardless.  Although Burge and Landin were expecting to use McG (their name for Strachey's Macro Generator), the Univac 1107 implementation was using the SLEUTH II macro assembler and it was all in assembly language.  I am certain there are no artifiacts.  Most of the workiing papers that Burge and especially Landin wrote as technical notes inside Sperry Univac were published elsewhere eventually.  I doubt I have retained any of them.
orcmid
CC BY-SA 4.0
2024-02-28T20:48:10.083Z
If you think about it, it's a pity so much history is gone.
Andrej Bauer
CC BY-SA 4.0
2024-02-28T21:32:33.220Z
@AndrejBauer yes, there is much lost and some of the folklore is a bit ungrounded.

I just looked at the PAL reference manual that is available on the PAL Language.  I notice that PAL did have a form of lambda expression for anonymous function descriptions.  The form was "ll arg-list = expr" where the "ll" (two L's) was used as the substitute for a lambda.  According to that manual, the first implementation of PAL was in LISP and a subsequent one was in BCPL.  I knew of a MIT graduate student who worked on it in some manner, but he is not listed as a contributor in the manual.
orcmid
CC BY-SA 4.0
2024-02-27T02:50:38.263Z
2024-02-27T02:50:38.263Z
orcmid
<p>I recently read Landin's paper "The Next 700 Programming Languages".  But I was a bit confused by ISWIM.  In particular, are functions first-class objects in ISWIM?  It seems not because every function must occur under some name and there is no $\lambda$-like construct in the language to construct an anonymous function.  Landin even explicitly claimed in the first footnote that "a not inappropriate title would have been Church without lambda".  Anybody knows the reason behind this choice?  Is ISWIM less expressive than a language with $\lambda$?</p>

<pl.programming-languages><lambda-calculus><functional-programming>
A few questions about ISWIM
day
# A few questions about ISWIM

(Asked by: username_0 on 2013-07-15)

I recently read Landin's paper "The Next 700 Programming Languages". But I was a bit confused by ISWIM. In particular, are functions first-class objects in ISWIM? It seems not because every function must occur under some name and there is no $\lambda$-like construct in the language to construct an anonymous function. Landin even explicitly claimed in the first footnote that "a not inappropriate title would have been Church without lambda". Anybody knows the reason behind this choice? Is ISWIM less expressive than a language with $\lambda$?

**Tags:** pl.programming-languages, lambda-calculus, functional-programming

---

## 2 answers

### Answer by username_1 on 2013-07-15. Score: 2 | Accepted answer

The [wikipedia](http://en.wikipedia.org/wiki/ISWIM) page for ISWIM says that it is a higher-order language, and that ISWIM is syntactic sugar for the $\lambda$-calculus.

Although it seems to have no explicit $\lambda$ construct, thereby making it impossible to have anonymous functions, one achieves the same expressive power by combining lexical scoping and first-class functions: Define a new name for a function locally; pass function as value to higher-order function.

> **Comments:**
> **username_0**: Thanks for the answer, Dave.  So it seems Landin was promoting a more mathematical-style of programming.  In mathematics, we do not have $\lambda$ but we do have higher-order functions.  
> **username_2**: @Dave Clarke, others@Dave Clarke, others  I think the bigger reason against direct lambda-abstraction is that you need a way to deal with recursion that is not so tricky as the Y combinator.  If your read Landin's papers on things like program points, you'll see lambda abstractions are heavily used, also over tuples, in defining the semantics of the SECD machine.  

---

### Answer by username_2 on 2024-02-27. Score: 3

I was around when ISWIM was being formulated, including an implementation project on the Univac 1107 in the mid 1960s. It never struck me that there were no anonymous functions. But functions were first class in the sense that they can be returned as results of other functions. And expressions can produce them, but the expression used a name, even if just to get the function defined, say in a parameter expressions, something like

fx(p1 where p1(i) = 2\*i-3)

or something more elaborate.

I think we were so enamored of the expression formulations with **let** and **where** that we didn't think of bare anonymous functions. Also, function definitions were not recursive by default, so it took something not quite like **label** to get that done.

> **Comments:**
> **username_3**: Do you know whether one can get hold of an ISWIM implementation nowadays?  
> **username_4**: https://www.google.com/search?q=iswim+implementation there seems to be a few.  
> **username_5**: https://github.com/jeapostrophe/iswim  
> **username_6**: @orcmid The Wikipedia page https://en.wikipedia.org/wiki/ISWIM is a bit ambiguous but claims it was implemented. Maybe you can correct this?  
> **username_2**: @Martin No, the wikipedia article says it was not implemented, although it may have inspired some other work.  The Univac 1107 implementation was not completed.  the PAL language at MIT had some of the syntactic forms, it was devised by Art Evans while Peter Landin was there before returning to the UK.  PAL did not use the SECD machine as far as I know.  It broke the spirit in any case: LET was a variable declaration and assignment statement.  
> **username_2**: @AndrejBauer I am not aware of any extant ISWIM implementation, unless Landin continued the work after he returned to the UK.  There is a description of the SECD machine in Bill Burge's "Recursive Programming Techniques" book although, for some reason, he does not refer to the Next 700 paper; he cites Landin's earlier "Mechanical Evaluation of Expressions" (MEE) paper.  
> **username_2**: @AndrejBauer I suspect that ML is the closest as an implementation and dealt with types and type inference in ways that Landin might not have dug into while in the US.  The SECD machine is very costly if you allow assignment, although there are other ways to have stateful entities that don't break the model.  (In ML, there is a punt/hack about assignment, but F# compute expressions may do the job, although F# is built on a mutable storage model.)  The folks at Cambridge doing functional-programming work might have better recent information.  
> **username_3**: Thanks, I was mostly asking for historical reasons to see whether some archeological artefacts may still be around.  
> **username_2**: @AndrejBauer It's nice to hear from you regardless.  Although Burge and Landin were expecting to use McG (their name for Strachey's Macro Generator), the Univac 1107 implementation was using the SLEUTH II macro assembler and it was all in assembly language.  I am certain there are no artifiacts.  Most of the workiing papers that Burge and especially Landin wrote as technical notes inside Sperry Univac were published elsewhere eventually.  I doubt I have retained any of them.  
> **username_3**: If you think about it, it's a pity so much history is gone.  
> **username_2**: @AndrejBauer yes, there is much lost and some of the folklore is a bit ungrounded.  I just looked at the PAL reference manual that is available on the PAL Language.  I notice that PAL did have a form of lambda expression for anonymous function descriptions.  The form was "ll arg-list = expr" where the "ll" (two L's) was used as the substitute for a lambda.  According to that manual, the first implementation of PAL was in LISP and a subsequent one was in BCPL.  I knew of a MIT graduate student who worked on it in some manner, but he is not listed as a contributor in the manual.  

---

