[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: QUOTE-MAY-COPY (Version 4)
- To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Issue: QUOTE-MAY-COPY (Version 4)
- From: firstname.lastname@example.org (Sandra J Loosemore)
- Date: Tue, 24 Jan 89 21:47:24 MST
- Cc: CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 24 Jan 89 22:10 EST
> If I switch to ALWAYS I would agree
> with Kent's amendment that all objects are allowed as constants and
> copying is permitted only for the objects where equivalence is defined.
I sent around a draft of the new writeup to cl-compiler the other day
that includes a proposal along these lines. Proposal
QUOTE-MAY-COPY:NOT-EVAL seems to be uniformly hated by everyone, so I
let it drop.
> There is a claim that QUOTE-MAY-COPY:NOT-EVAL-OR-COMPILE would require
> major revamping of some implementations (PSL/PCLS and maybe KCL). I
> find this hard to believe, but if it's true I might change my vote
> to ALWAYS on the grounds of that. I'd have to hear more about the
> specific implementation problems first. It seems to me that constant
> copying in COMPILE can only be a matter of efficiency, and compiled
> functions always have to have access to normal Lisp objects.
For KCL, my understanding of what happens is that COMPILE ends up PRINTing
the constants to a file and then reading it in again. Jeff Dalton claims
that COMPILE could be fixed to work around this problem, though.
For PSL/PCLS, compiled code objects are copied into a part of memory
that is not scanned by the garbage collector. Constant references are
just anonymous pointers sitting at unknown locations within the code.
Because of this, compiled code can't contain any references to
constants that might possibly be relocated, so all constants have to
be copied into read-only memory when the functions that reference them
are compiled. There are workarounds involving indirecting through a
table, or maintaining a table of offsets of constant pointers within
each function, but it seems unlikely that anybody will have the
ambition to implement them, at this point. We've never claimed that
PSL/PCLS was a real Common Lisp anyway.
I'm not sure what Utah Common Lisp was planning to do about COMPILE;
as far as I know, the compiler is strictly a cross-compiler now. I
heard a lot of unhappy noises from the main compiler hacker though,
the last time I talked to him about this. A-Lisp (the implementation
I was working on personally) treats code objects the same way PSL/PCLS
does, but it doesn't have COMPILE implemented yet either (and probably
never will). Both UCL and A-Lisp refuse to compile circular
constants, because the loader wants to build constants bottom-up in
both implementations; UCL gets stuck in an infinite loop and A-Lisp
signals an error.
There might be some other implementations that would be affected that
I don't know about. I think I remember Walter saying that VaxLisp
also copied constants and didn't GC code, but I might be mistaken.