[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issue COMPILE-ARGUMENT-PROBLEMS
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: issue COMPILE-ARGUMENT-PROBLEMS
- From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
- Date: Mon, 2 Jan 89 23:03:10 MST
- Cc: sandra%defun@cs.utah.edu, CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 3 Jan 89 00:14 EST
It looks to me like the main difference between the two proposals is
in the treatment of functions defined in a non-null lexical
environment. The proposal that was voted on was amended in accordance
with your earlier suggestions to make the other situations harmless --
doing nothing is an acceptable alternative if the function is already
compiled, but signalling errors or blowing fuses is not -- so I think
the other issues you touch upon in your new proposal could probably be
handled as editorial changes. I would much rather do that than re-open
the issue (I think our time would be better spent trying to deal with
the many other unresolved issues we still have pending), but if you
feel strongly about this then of course we can go ahead and ask for
another vote.
A problem I have with your proposal is that I believe that
COMPILED-FUNCTION-P must be true of any function returned from
COMPILE, and that COMPILE must also at least ensure that all macro
calls in the function have been expanded. I don't think that allowing
COMPILE to do nothing when passed an interpreted function is a
legitimate option.
I've actually been trying to draft a short document for Kathy Chapman
to describe the minimum functionality required for implementations of
COMPILE and COMPILE-FILE (incorporating Steve's famous "compiler
model" from last March), but if what's obvious to me isn't obvious to
other people, I should probably turn at least this one part of the
writeup into a new issue so we can vote on it formally.
-Sandra
-------