#

## Issue EVAL-OTHER Writeup

    Issue:        EVAL-OTHER
    References:   5.1.1 Self-Evaluating Forms (p55)
    Category:     ADDITION/CLARIFICATION
    Edit history: 07-Mar-88, Version 1 by Pitman
    		   8-Jun-88, Version 2 by Masinter (correct typo, add to discussion)

    Problem Description:

      CLtL does not specify what the evaluation behavior of some data types.

    Proposal (EVAL-OTHER:SELF-EVALUATE):

      Standard data types (those mentioned by CLtL) other than those for which
      a more explicit evaluation rule exists would be defined to self-evaluate.
      Such data types include, for example, structures, arrays, vectors, and
      pathnames.

      Structure types defined by users using DEFSTRUCT should also self-evaluate
      unless an explicit implementation type for the structure is given in the
      DEFSTRUCT, in which case the rule for evaluation of that type should be
      used. (This is important in the case of type LIST.)

    Test Case:

      (LET ((TEMP (MAKE-PATHNAME)))  (EQ TEMP (EVAL TEMP))) => T
      (LET ((TEMP (MAKE-ARRAY NIL))) (EQ TEMP (EVAL TEMP))) => T

    Rationale:

      There are numerous possible positions that could be taken, from
      requiring that an error be signalled for all of these cases to
      requiring that these all have some useful behavior.

      By making implementations agree, code portability is enhanced.
      By biasing the decision away from the "signal
      an error" end of the choice spectrum, the least interruption is
      caused to implementations which already have working code.

      There is still some chance that implementations will have some other
      behavior than either signalling an error or self-evaluating, but there
      are probably few if any.

    Current Practice:

      In many implementations, the other data types besides those mentioned in
      CLtL will self-evaluate.

    Cost to Implementors:

      The cost is probably small. This is probably an "upward compatible"
      change for most or all implementations -- a few lines of change in the
      interpreter and/or compiler. Some code walkers may be affected as well.

    Cost to Users:

      None, if they are not exploiting implementation-dependent features of
      some implementation that is being forced to make an incompatible change.

      There should be no performance impact since the evaluator's test for these
      new data types can simply be made to follow other tests already in place,
      so existing code will not be slowed.

    Cost of Non-Adoption:

      Implementations will continue to differ in this relatively
      user-visible way.

    Benefits:

      Portability will be enhanced because implementations will tend to agree
      in places where they have traditionally not always agreed.

    Aesthetics:

      Some fans of 3LISP may find this invasive to their sense of distinction
      between objects and the notation used to describe objects. In general,
      however, this is a fairly picky detail that is not likely to trouble the
      average programmer.

    Discussion:

    This idea for this proposal was suggested by the Japanese community.
    Pitman drafted the formal proposal and supports EVAL-OTHER:SELF-EVALUATE.

    Fahlman: "... I do remember the original design discussions.  It was
    proposed that everything but lists and symbols evaluate to themselves,
    but at the time (this was quite early in the process) some people felt
    that this might close out interesting parts of the design space that
    might turn out to be useful for something.  This hasn't happened, and
    I think it would be reasonable to close this door now.  Some users do
    find it confusing that you have to quote vectors but not strings."

    There has been some additional discussion of this proposal (for example,
    an explaination of why a similar proposal in Scheme might be a bad design.)

Copyright 1996-2001, Xanalys Inc. All rights reserved.