Re: Issue: TRACE-ERROR (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 22 Jun 88 23:06 PDT
    From: masinter.pa@Xerox.COM

    I would like to separate out, if possible, the requirement for
    conformance -- what it is you have to have to say that you have
    ANSI Common Lisp -- and the strong recommendations the standard
    might make for having an acceptable environment.

I'm completely baffled by why anyone thinks this has anything whatsoever
to do with conformance. Conformance has to do with adherence to what is
written. I'm suggesting we write something different. Whether people
conform or not will be judged against what we write and is, indeed,
something beyond our jurisdiction.

    This issue is in many ways like IF-BODY; it attempts to put some
    constraints on things that implementations do that aren't part of
    the standard anyway.

There are things that are intended to be left open and things that
are not. We have to separate them out. I am asserting that the right
to ignore a user's TRACE specification without a hint that that's what
you're doing is something we don't want to leave open, even if we leave
open what kinds of TRACE extensions we allow. This is no different than
allowing people to extend COERCE or OPEN or SUBTYPEP, but requiring
specifying that COERCE must signal an error if it can't do the coercion
or that OPEN must still return a stream even if the keywords are 
non-standard or how TYPEP passes back information about the fact that 
it couldn't do its job correctly.

    I don't know for sure that there is precedent, but I vaguely
    remember some similar wording in other standards documents. I'd like
    to see the only "standard" for ED, TRACE, BREAK and the other
    "environment" features be that they exist in the Lisp package and
    that the implementations document what they do; 

I'd be almost ammenable to this except that I'd want to specify that if
they do nothing they must either return some CL-specified value or
else do typeout informing the user that they did nothing.

For example, on the 3600, ED communicates with and/or spins off a new
process which will run the editor. It therefore returns before it has
`done anything'. On the 3600, you have a bar at the bottom of the screen
that tells you that the machine is still busy, so this isn't too baffling.
If I were on a machine that did not have a status line at the bottom of
the screen and called ED only to see it return, I might not know if it
was still doing something in background and might not know how to decide
when to stop waiting.

    secondly, we can strongly *recommend* (maybe in the notes) that TRACE do
    error checking

This would be ok, but since no one has advanced a reason why TRACE should
not always do error checking, this is pretty wimpy.

    and that DRIBBLE change the current *terminal-io* rather than
    work with an embedded top-level loop.

People have advanced valid reasons for this not to happen. It's interesting
that you pick these examples because you seem to intend me to be able to
send a bug report to an implementation which doesn't follow the recommendation
saying "gosh, i wish it did" and yet I hope you're not trying to incite
Lispm users to riot by inserting a recommendation about DRIBBLE which is
non-binding but which has been shown not to be generally agreed upon by the
technical community.

I personally think there is no place for notes in the standard. There
bindingness on conformity (or lack thereof) is just too confusing.

    We certainly gutted DRIBBLE, I don't know why we should turn around and tighten
    up TRACE.

Not so. We didn't gut DRIBBLE, we acknowledged the status quo (a status quo
which was supported by the existing vague wording). Making any change would
have forced some implementation to make an incompatible change. On the other
hand, the proposed change to TRACE is not interestingly incompatible. The two
issues are not at all in the same class as I see it.