4 ms·

Turns out we're both right. > Anyway, I decided to write a paper describing LISP both as a programming language and as a formalism for doing recursive function

by j-pb 7y ago

Turns out we're both right. > Anyway, I decided to write a paper describing LISP both as a programming language and as a formalism for doing recursive function theory. > One mathematical consideration that influenced LISP was to express programs as applicative expressions built up from variables and constants using functions. I considered it important to make these expressions obey the usual mathematical laws allowing replacement of expressions by expressions giving the same value. The motive was to allow proofs of properties of programs using ordinary mathematical methods. This is only possible to the extent that side-effects can be avoided. Unfortunately, side-effects are often a great convenience when computational efficiency is important, and ``functions'' with side-effects are present in LISP. From http://www-formal.stanford.edu/jmc/history/lisp/node3.html#SECTION00030000000000000000 http://www-formal.stanford.edu/jmc/history/lisp/node3.html#S...

lispm 7y ago
Functions with side-effects are common in LISP. That's why LISP functions are more like traditional procedures and less like mathematical functions. There was a mathematical 'theory' presented, but it differed from the actual programming language LISP (see the LISP 1 Programmer's Manual, 1960): https://kyber.io/rawvids/LISP_I_Programmers_Manual_LISP_I_Programmers_Manual.pdf https://kyber.io/rawvids/LISP_I_Programmers_Manual_LISP_I_Pr...
- j-pb 7y ago
  Did you even read the piece by McCarty? He talks about how it was meant as an alternative to the computational models based on turing machines in addition to a symbolic computation tool for AI and therefore used side effects for convenience but also tried to keep mathematical properties, like referential transparency. Tbh it seems pointless discussing this with you because the idea of common lisp being the embodyment of the lisp philosophy seems to have become personal to you. Sorry my energy reservoirs are drained, I'm just gonna ignore your posts, and head back to work, there's a large CL codebase that needs to be rewritten to clojure and that's stressful enough.
  - lispm 7y ago
    > Did you even read the piece by McCarty? Sure, the paper was more a side-effect of their work on LISP 1 and the mathematical ideas were developed at the end of the first phase of the development & implementation of LISP. > He talks about how it was meant as an alternative to the computational models based on turing machines in addition to a symbolic computation tool for AI and therefore used side effects for convenience but also tried to keep mathematical properties, like referential transparency. The programming language LISP 1 had SET, SETQ, control flow via GOTO, setting of slots of cons cells, destructive operations for list processing, destructive property list operations, ... LISP was an actual programming system for a real computer, their IBM 704. It was a LISP implementation written in assembler and LISP with stuff like an interpreter, a compiler, garbage collection, input/output, a kind of read-eval-print-loop, saving memory dumps and loading them, writing/loading assembler code from LISP, and all that stuff which is in a typical LISP implementation since then. The chapter you linked to even has the title 'The implementation of LISP'. Check out the LISP 1 manual I linked to sometime.

by j-pb 7y ago

lispm 7y ago

Functions with side-effects are common in LISP. That's why LISP functions are more like traditional procedures and less like mathematical functions. There was a mathematical 'theory' presented, but it differed from the actual programming language LISP (see the LISP 1 Programmer's Manual, 1960): https://kyber.io/rawvids/LISP_I_Programmers_Manual_LISP_I_Programmers_Manual.pdf https://kyber.io/rawvids/LISP_I_Programmers_Manual_LISP_I_Pr...

j-pb 7y ago
Did you even read the piece by McCarty? He talks about how it was meant as an alternative to the computational models based on turing machines in addition to a symbolic computation tool for AI and therefore used side effects for convenience but also tried to keep mathematical properties, like referential transparency. Tbh it seems pointless discussing this with you because the idea of common lisp being the embodyment of the lisp philosophy seems to have become personal to you. Sorry my energy reservoirs are drained, I'm just gonna ignore your posts, and head back to work, there's a large CL codebase that needs to be rewritten to clojure and that's stressful enough.
- lispm 7y ago
  > Did you even read the piece by McCarty? Sure, the paper was more a side-effect of their work on LISP 1 and the mathematical ideas were developed at the end of the first phase of the development & implementation of LISP. > He talks about how it was meant as an alternative to the computational models based on turing machines in addition to a symbolic computation tool for AI and therefore used side effects for convenience but also tried to keep mathematical properties, like referential transparency. The programming language LISP 1 had SET, SETQ, control flow via GOTO, setting of slots of cons cells, destructive operations for list processing, destructive property list operations, ... LISP was an actual programming system for a real computer, their IBM 704. It was a LISP implementation written in assembler and LISP with stuff like an interpreter, a compiler, garbage collection, input/output, a kind of read-eval-print-loop, saving memory dumps and loading them, writing/loading assembler code from LISP, and all that stuff which is in a typical LISP implementation since then. The chapter you linked to even has the title 'The implementation of LISP'. Check out the LISP 1 manual I linked to sometime.