[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


    Date: 29 May 87 21:20 PDT
    From: Masinter.pa@Xerox.COM

    Issue:        IGNORE-ERRORS

    KMP thinks that in spite of the perceived optimism about the emerging error
    proposal, it's wise to have a safe and credible interim position.
    Masinter wonders why KMP isn't spending more time on the error proposal.

I'd like to encourage you to remove this somewhat random comment, which may
be viewed by outsiders as being more critical than you hopefully meant. In 
fact, KMP is spending a -lot- of time on the error proposal.

The problem is that KMP has what he thinks is a clear understanding
both of the length of time it takes to get things of that size through
a political mechanism such as X3J13 even under ordinary circumstances,
and is -very- leary about potential last-minute snags due to the 
emergence of CLOS in parallel and the fact that people will likely 
want last-minute "small changes" to make it take more advantage of CLOS.

The presence of this item as a place-holder while all the business of
acceptance is in progress is particularly important to me. The more vendors
who provide this as a private extension in the very near term, the fewer
utterly random interfaces they'll conjure instead. Like it or not, existing
code has to interface to the private extensions until this standard is marked
approved, but we can do a lot to improve quality of life by at least hinting
that this is coming. In Macsyma, there's a definition of IGNORE-ERRORS that

            (ZL:SYS:ERROR (VALUES NIL -ERROR-)))
 #+(OR ...other-systems...)
 #+(OR ...more-other-systems...)

Each new case added requires careful study of the host error system to
figure out how to attach an IGNORE-ERRORS. If everyone had the idea that
at least IGNORE-ERRORS was worth latching onto, I think they'd at least
do that even if they weren't sure of the rest of the emerging error system,
and I think the resulting convergence would be very useful.