ERROR SIGNALLING FUNCTIONS

[GBROWN@DEC-MARLBORO.ARPA]

        I believe  that  use  of  the  error  signalling  macros  in
        sections  24.3  and 24.4 of the Common Lisp Reference Manual
        (Excelsior   edition)   will   diminish   the   quality   of
        applications  written in Common Lisp.  This note explains my
        reasoning.  I realize that the note comes quite late, but  I
        sent  in  a  similar  note  right  after Moon's proposal was
        distributed which appears  to  have  been  ignored.   Please
        recognize  that  my  opinions  are  not necessarily those of
        other people working on Common Lisp at Digital.

        My  basic  objection  is   that   the   macros   incorporate
        assumptions  about  error signalling and error messages that
        are inapropriate in most circumstances and hence should  not
        be  promoted  by  the language.  I feel quite strongly about
        this issue.  Here are my specific objections.


              o  check-type.  In all but the most trivial cases, the
                 user  will  have  no idea how to enter a new value,
                 and we wouldn't want the user to know anyway.   The
                 first  example in the reference manual, telling the
                 user that something is not a vector of integers, is
                 precisely  an  example of an error message I'd hate
                 for a user to  see.   The  error  message  fragment
                 alleviates this problem somewhat, but again only in
                 trivial cases.

                 The other problem with this macro is the use of  an
                 unevaluated  string for the error message fragment.
                 This is quite parochial, and certainly  would  only
                 suffice in the country in which the application was
                 written.  At Digital, for example, we like  to  put
                 our  messages  in  a file that can be edited by the
                 user, and invoke a function to obtain  the  message
                 when needed.

              o  assert.  This suffers from the same shortcomings as
                 check-type.   In  particular,  the error message is
                 actually part of the syntax, and thus  couldn't  be
                 evaluated in any case!  In addition, the assumption
                 is made that a rational message could  be  composed
                 from  one of the generalized-variable references in
                 order to prompt  the  user  for  a  new  value.   I
                 challenge  anyone  to  do this in a stylish fashion
                 (note that there were no examples of  this  in  the
                 manual).

              o  e(c)typecase.  I am  quite  surprised  that  Common
                 Lisp  implementors  were willing to accept the hair
                 involved in trying to compose a reasonable  message
                 for  this  function.   Imagine  trying  to word the
                 message for types such as a defstruct,  a  deftype,
                 or  even  the  relatively  simple type (or (mod 16)
                 (member t nil)).  And I hope we'd  agree  that  the
                 resulting  message would only confuse the user, who
                 would have no idea how to enter a new value.

              o  e(c)case.  Except in the situation where there  are
                 only   two   or   three  clauses,  I  doubt  if  an
                 application would want to  list  all  the  possible
                 values  from  which  the  user  can  choose.   Even
                 applications that list all possible commands (e.g.,
                 Visicalc) do it in their own special style.

              o  declarations.  It is not  clear  how  these  macros
                 interact with declarations.  If a function declares
                 the data item used as  the  key  in  one  of  these
                 macros,  it  may  be  that  Common Lisp has already
                 detected the error and,  in  many  implementations,
                 signalled it with some other obscure error message.
                 This  completely  circumvents  the  error   message
                 generated  by  the  macro,  and  renders  the macro
                 useless.


        Let us reconsider the inclusion of these  macros  in  Common
        Lisp.   They  address a problem, detection and alteration of
        incorrect input by the user, which is better addressed by an
        application-specific question asking facility.  If we retain
        these macros, I suggest that they be  used  only  to  signal
        uncorrectable internal logic errors.


        - Paul C.  Anagnostopoulos

-------