[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
- To: kempf%hplabsz@hplabs.HP.COM
- Subject: Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
- From: Masinter.pa@Xerox.COM
- Date: 10 Nov 87 13:20 PST
- Cc: cl-cleanup@sail.stanford.edu, kempf%hplabs@hplabs.HP.COM
- In-reply-to: kempf%hplabsz@hplabs.HP.COM's message of Mon, 09 Nov 87 15:41:27 MST
Proposal form:
We need to decide on the name of this proposal. The mail messages have
had subject lines "TRACE Proposal" or "Issue: TRACE-FUNCTION-ONLY", but
the body of the proposal has said TRACE-CLOS. Since I've been filing it
under TRACE-FUNCTION-ONLY, I vote for changing the body to say
TRACE-FUNCTION-ONLY. (The proposal for dealing with SETF functions is
called SETF-FUNCTION-VS-MACRO, not SETF-CLOS.)
I'm a bit uneasy that some things appear under different categories than
I would have placed them (most of the discussion under Rationale is not
properly part of the rationale of this proposal but rather some
additional considerations). The discussion of Conversion Cost seems to
be a discussion of Adoption Cost instead. Conversion Cost is supposed to
address the cost to users of converting their code to deal with a
proposal, rather than to the Lisp system implementors. I think the
current practice and extensions to TRACE employed by various
implementations should at least be alluded to under Current Practice.
I don't know why the fact that this is a part of the environment rather
than the language makes the burden of adoption cost any less.
("However, compatibility with existing implementations seems less of an
issue here, since TRACE is more a part of the environment.")