Proceedings of the November 7-10, 1966, Fall Joint Computer Conference on XX - AFIPS '66 (Fall) 1966
DOI: 10.1145/1464291.1464362
|View full text |Cite
|
Sign up to set email alerts
|

The LISP 2 programming language and system

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1
1
1

Citation Types

0
6
0

Year Published

1967
1967
2013
2013

Publication Types

Select...
6
1
1

Relationship

0
8

Authors

Journals

citations
Cited by 12 publications
(6 citation statements)
references
References 2 publications
0
6
0
Order By: Relevance
“…He deals only with objects of the language which have the right properties -e. g. , access to the second 1-bit field gets the desired value. This differs from the approach taken in LISP 2 [8] where the programmer deals explicitly with the bit packing himself.…”
Section: Data Type Extensionsmentioning
confidence: 94%
“…He deals only with objects of the language which have the right properties -e. g. , access to the second 1-bit field gets the desired value. This differs from the approach taken in LISP 2 [8] where the programmer deals explicitly with the bit packing himself.…”
Section: Data Type Extensionsmentioning
confidence: 94%
“…In some cases this was driven by the desire to emulate styles of programming found in ALGOL-like languages [Abrahams 1966] and by the fact that, although some compilers would sometimes optimize tail-recursive calls, the programmer could not rely on this until the era of good Scheme and Common Lisp compilers in the 1980s, so performance was an issue.…”
Section: Iterationmentioning
confidence: 99%
“…Abrahams et al remark that by 1966 macros were an accepted part of Lisp 1.5 as well [Abrahams 1966].…”
Section: (Cadr Form) )mentioning
confidence: 99%
See 1 more Smart Citation
“…From another point of view, one can ignore the implementation and take BUFFER as an abstract set of data types with certain properties. (2) The notion of underling representation has a natural extension. We have jut used the mode STRUCT (FRONT INT,BACK:INT, BODY:VECTOR(200,CHAR)) as a basis for defining RB so that the former is the underlying representation of the latter; we could equally well use an RB as a basis for defining a new mode, for which RB would be the underlying representation.…”
Section: Communicationsmentioning
confidence: 99%