R
Rainer Weikusat
Tidbit of LISP history I came across recently:
The erasure problem also had to be considered, and it was
clearly unaesthetic to use explicit erasure as did IPL. There
were two alternatives. The first was to erase the old contents
of a program variable whenever it was updated. Since the car
and cdr operations were not to copy structure, merging list
structure would occur, and erasure would require a system of
reference counts. Since there were only six bits left in a
word, and these were in separated parts of the word, reference
counts seemed infeasible without a drastic change in the way
list structures were represented. (A list handling scheme
using reference counts was later used by Collins (1960) on a
48 bit CDC computer).
The second alternative is garbage collection in which storage
is abandoned until the free storage list is exhausted, the
storage accessible from program variables and the stack is
marked, and the unmarked storage is made into a new free
storage list. Once we decided on garbage collection, its
actual implementation could be postponed, because only toy
examples were being done.
http://www-formal.stanford.edu/jmc/history/lisp/node3.html#SECTION00030000000000000000
'Erasure' refers to 'freeing allocated memory'. This implies that 'the
tracing garbage collector' wasn't invented by McCarthy because he
considered it a superior method of automatic memory management but was
a makeshift approach chosen because limitations of the IBM 704
hardware made using reference counting 'infeasible', given the
cons cell implementation which already existed at the time the 'memory
management problem' was starting to be considered with "We don't
absolutely have to solve this now, but do it 'somehow' in future"
being a secondary concern (according to other sources, the actual
garbage collector was later developed by a student who had to work
within the constraints of the existing system).
Isn't it amazing that - until today - automatic resource management is
held back by deficiencies inherent in a workaround for the word size
of a computer which looked like this?
http://en.wikipedia.org/wiki/File:IBM_Electronic_Data_Processing_Machine_-_GPN-2000-001881.jpg
To be fair to 'the Perl 6 people': The problem with reference
counting is that while it is convenient for language users because it
implies that all kinds of resources can be managed automatically in a
'lexically scoped way', it does exactly nothing for language
implementors as the pairs (<allocate memory>, <free memory>) and
(<increment ref count>, <decrement refcount>) are obviously
equivalent.
The erasure problem also had to be considered, and it was
clearly unaesthetic to use explicit erasure as did IPL. There
were two alternatives. The first was to erase the old contents
of a program variable whenever it was updated. Since the car
and cdr operations were not to copy structure, merging list
structure would occur, and erasure would require a system of
reference counts. Since there were only six bits left in a
word, and these were in separated parts of the word, reference
counts seemed infeasible without a drastic change in the way
list structures were represented. (A list handling scheme
using reference counts was later used by Collins (1960) on a
48 bit CDC computer).
The second alternative is garbage collection in which storage
is abandoned until the free storage list is exhausted, the
storage accessible from program variables and the stack is
marked, and the unmarked storage is made into a new free
storage list. Once we decided on garbage collection, its
actual implementation could be postponed, because only toy
examples were being done.
http://www-formal.stanford.edu/jmc/history/lisp/node3.html#SECTION00030000000000000000
'Erasure' refers to 'freeing allocated memory'. This implies that 'the
tracing garbage collector' wasn't invented by McCarthy because he
considered it a superior method of automatic memory management but was
a makeshift approach chosen because limitations of the IBM 704
hardware made using reference counting 'infeasible', given the
cons cell implementation which already existed at the time the 'memory
management problem' was starting to be considered with "We don't
absolutely have to solve this now, but do it 'somehow' in future"
being a secondary concern (according to other sources, the actual
garbage collector was later developed by a student who had to work
within the constraints of the existing system).
Isn't it amazing that - until today - automatic resource management is
held back by deficiencies inherent in a workaround for the word size
of a computer which looked like this?
http://en.wikipedia.org/wiki/File:IBM_Electronic_Data_Processing_Machine_-_GPN-2000-001881.jpg
To be fair to 'the Perl 6 people': The problem with reference
counting is that while it is convenient for language users because it
implies that all kinds of resources can be managed automatically in a
'lexically scoped way', it does exactly nothing for language
implementors as the pairs (<allocate memory>, <free memory>) and
(<increment ref count>, <decrement refcount>) are obviously
equivalent.