[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: TRACE-ERROR (Version 1)
- To: edsel!eb@labrea.stanford.edu
- Subject: Issue: TRACE-ERROR (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Wed, 22 Jun 88 13:02 EDT
- Cc: CL-Cleanup@sail.stanford.edu
- In-reply-to: <8806212112.AA00406@blacksox.lucid.com>
Date: Tue, 21 Jun 88 14:12:17 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
It seems to me that this is beyond the scope of the cleanup committee
or even the standardization effort. What you are describing is a bug
in a particular implementation of TRACE.
Not necessarily if the documentation doesn't say it's a bug. Some vendors
prefer not to change anything that the standard doesn't require them to change.
Also, the time between releases may be very long. And, as far as I can see,
there's no good reason I should ever find myself inconvenienced by this problem.
It is a bug because it reduces the usability of TRACE,
Few vendors use this criterion in general for determining what's a bug
and what's not.
not because that version of TRACE does not conform to some present or
future Common Lisp standard.
Certainly not if we don't agree to discuss it in this forum, but that's
a bit self-defeatist.
Send a bug report to your Lisp supplier.
But it's not guaranteed to help since I have no leverage.
I (wearing my third-party application developer hat) can afford to
discriminate against a CL because it doesn't do floating point or bignums
right, or because it doesn't implement lexical closures, but if it reaches
and interesting target market and it doesn't do TRACE right, I'm probably
going to be stuck using it. Some vendors want to implement just the bare
minimum and appeal to the full force of the "is an error" rule wherever
possible. I think that where reasonable we should raise the least common
denominator, and I think a reasonable place to start is in places that
users (eg, me, in this case) report that there's been a problem.
In this particular case, any reasonable vendor is probably going to give
in to my demands, but this bug is an easy mistake to make and there's no
reason not to put the feature I'm asking for in the standard if only to
remind all vendors to get the feature into release 1 of their product.
P.S. As it happens, I think that supplier is Lucid! ...
I'm pretty sure it was not.
I believe that our TRACE implementation accepts the :WHEREIN keyword
but does not implement its functionality.
[Actually, I just pulled :WHEREIN out of a hat. I don't remember the real
keyword, but I know I never use :WHEREIN. Maybe it was :BREAK...] Anyway,
I'm inclined to believe this would be acceptable as long as TRACE does
typeout saying that it was not using the keyword. Anything that tells the
user what's going on.