[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ELIMINATE-FORCED-CONSING
- To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
- Subject: ELIMINATE-FORCED-CONSING
- From: Scott.Fahlman@B.GP.CS.CMU.EDU
- Date: Wed, 07 Sep 88 14:52:00 EDT
- Cc: cl-cleanup@sail.stanford.edu
- In-reply-to: Your message of Tue, 06 Sep 88 15:38:22 -0700. <8809062238.AA12484@trwrb.TRW.COM>
Through some fluke of network routing, Ginder's revised proposal reached me
before his detailed response to Moon. When I saw the :MODIFY and :RECYCLE
arguments and the complexities involved in making the latter do what you
want, my head started spinning. I think that this is all very confusing,
and I am strongly opposed to this proposal in its current form. :MODIFY
and :RECYCLE are similar enough to be easily confused, but they differ in
subtle ways in their details; I never want to have to explain to a class
when you use which one.
Once I saw Ginder's other message, I realized what the problem is: I'm
happy enough to accept a :MODIFY or :OVERWRITE option in all of the
appropriate places -- I have no preference for one of these names over the
other -- but I really don't think that any of this recycling nonsense
should be muddled in with the sequence functions. To have both :MODIFY and
:RECYCLE present, similar but different in subtle ways, is to invite
endless confusion. If we accept just the :MODIFY part of the proposal, I
think that Moon's prescriptions -- discarding excess conses, for example,
are right.
If there really is a need for recycling of CONS cells, I would support an
explicit RECYCLE call whose argument is a list. This would authorize (but
not require) and implementation to CDR down the list argument, setting the
CAR of each cell to NIL, and then to splice the whole thing onto a free
list of some sort; CONS would use these free cells before allocating new
ones. Systems with epehemeral GC might not want to implement this since it
doesn't buy much and might result in worse storage locality than just
dropping the list. Something similar could be done for arrays, structures,
etc., though that is harder to do.
In the past we always stayed away from such things, since these constructs
lead to very confusing bugs if the program is actually holding onto the
recycled structure somewhere else. However, many programs end up creating
their own resource managers to reduce garbage-creation, and perhaps it is
time to consider adding this to the language proper. In any case, I think
that mixing this recycling concept with the sequence functions is the wrong
move.
I would be prepared to support a version of this proposal that just
included the :MODIFY parts.
-- Scott