Pure Lisp

Pure Lisp

A purely functional language derived from Lisp by excluding any feature which causes side-effects.
References in periodicals archive ?
We shall refer to Lisp with or without these mutation primitives as impure or pure Lisp, respectively.
This answer is not completely satisfying, however, because it assumes we want our programs to produce a particular representation of the answer, and it is this representation - rather than the answer - that is beyond the power of pure Lisp.
Can every impure Lisp program solving such a problem be transformed into a pure Lisp program with the same input-output behavior, in such a way that the number of primitives executed by the pure program exceeds the number performed by the impure program by at most a constant factor?
Our question regarding pure versus impure Lisp undoubtedly occurred to many workers, but its first appearance in print seems to be due to Hood and Melville [1981], who conclude their paper with the remark "It would be interesting to exhibit a problem for which the lower bound in Pure LISP is worse than some implementation using rplaca and rplacd.
1 There is a symbolic on-line computation that can be performed by an impure Lisp program in such a way that at most O(n) primitive operations are needed to produce the first n outputs, but for which every pure Lisp program must perform (for some input sequences) at least [Omega](n log n) primitive operations to produce the first n outputs.
Every symbolic on-line computation that can be performed by an impure Lisp program in such a way that at most T(n) primitive operations are needed to produce the first n outputs can be performed by a pure Lisp program that performs at most O(T(n) log T(n)) primitive operations (for all inputs sequences and for all values of n) to produce the first n outputs.
1972] have shown, however, that a queue (or even a dequeue, where items can be added or removed from either end) can be implemented in pure Lisp with O(1) primitive Lisp operations being performed for each queue (or dequeue) operation.
Clinger) is that pure Lisp must be compiled (rather than interpreted) if it is to express computations with the same efficiency as impure Lisp.
1 Every on-line symbolic impure Lisp machine M can be simulated by a pure Lisp machine M' in such a way that all outputs produced by M within the first n steps are produced by M[prime]within the first O(n log n) steps.
This can almost be proved by combining Theorem 1 of Ben-Amram and Galil [1992], where n steps on a RAM are simulated by O(n log n) steps on a pure Lisp machine, with an obvious simulation of n steps on an impure Lisp machine simulated by O(n) steps on a RAM.
The heart of the simulation is a technique for simulating mutation of array entries in pure Lisp.
Boyer and Moore then coded an interpreter in Baroque for a programming language akin to pure Lisp, with pattern-matched invocation and nondeterminism inherited from its implementation language.