[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)



    Date: 11 Nov 87 12:10:09 PST
    From: Masinter.PA@Xerox.COM

    I was using the word "destroy" in the sense that it is used in CLtL. ...

Is it actually defined or just used in a seemingly consistent way. No offense
meant to Steele because the job he did was really excellent, but I hope we're
long past the days where we think that just because CLtL uses a particular
undefined term (even consistently) then the term is well-defined. (Of course,
it's possible I just didn't notice the definition...)

    ... I don't think requiring destroyed cells to be smashed with NIL
    will solve any particular problems. It won't improve the style
    of any program, and won't allow any implementation to be more
    efficient.

I don't think this is clear.

There are many cases where people have `noticed' what REMPROP was returning
in Maclisp and figured out how to take advantage of it because it was an
`interesting' thing. If you smash something into usefulness, you reduce the
risk that people will `discover' [untrue] things about the language and rely
on them to be portable. If the desire to do non-portable things is reduced,
then I think this is equivalent to upgrading the overall level of style.

As for efficiency, we plan to do interesting things with our GC that takes
advantage of our being allowed to smash the car of the cell. But other
implementations might not have neat things they can do and yet users may
retain pointers to the cdr chain (with no intent to later inspect the
car of any cell in that chain). Since the cadr of the removed 2-list
is likely to sometimes contain large structures, forcing people to smash
a NIL into there may in fact improve the GC performance of some 
implementations where the user would otherwise be retaining pointers to
live structure.