[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
- To: Masinter.pa@XEROX.COM
- Subject: Re: Issue: TRACE-FUNCTION-ONLY (Version 5)
- From: kempf%hplabsz@hplabs.HP.COM
- Date: Wed, 11 Nov 87 09:37:06 MST
- Cc: cl-cleanup@SAIL.STANFORD.EDU, email@example.com
- In-reply-to: Your message of 10 Nov 87 13:20:00 -0800. <871110-132016-5562@Xerox>
> 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.)
This change sounds fine.
> 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 have no problem with this.
> 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.")
This was in response to a suggestion by Dave Moon, but I have no objection
if it is removed.
To save time, could you fold these changes into the final document? Thanks.