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

Results of the 21 August 1982 Common LISP Meeting



The Common LISP Meeting started at 9:45 AM on 21 August 1982.
The following people attended the meeting: Guy Steele, Walter van Roggen,
Gary Brown, Bill van Melle, David Dill, Richard Greenblatt, Glenn Burke,
Kent Pitman, Dan Weinreb, David Moon, Howard Cannon, Gary Brooks, Dave Dyer,
Scott Fahlman, Jim Large, Skef Wholey, Jon L White, Rodney Brooks,
Dick Gabriel, John McCarthy, and Bill Scherlis.

One hundred and fifty agenda items had been previously prepared.
These were discussed and for the most part resolved.  Another eleven
items were brought up at the end of the meeting.  The meeting was
adjourned at 6:00 PM.

Following is a copy of the prepared agenda, annotated with the results
of the meeting, and the additional topics and their results.

--Guy


                     AGENDA FOR COMMON LISP MEETING
                             21 AUGUST 1982
               ANNOTATED WITH THE RESULTS OF THE MEETING

   1. What objects should be self-evaluating?  In particular,
      should a bit-vector self-evaluate, and should an (ARRAY (MOD
      4)) self-evaluate?  Suggestion:  everything should
      self-evaluate except for symbols, structures, and all objects
      other than numbers that have pointer components.

          GLS will make a proposal.  Symbols and lists do not
          self-evaluate, numbers and strings do.  Odd objects
          should be an error.

   2. Should something be done about the fact that BYTE specifiers
      use a start-count (actually, a count-start) convention, while
      the rest of the language uses a start-end convention?

          No.  This will be left as is.

   3. Shall keywords be self-evaluating, and kept in a separate
      package?  The motivation for the latter is that they will
      always be printed with a colon; for the former, that keyword
      argument names need not be written with a quote and a colon,
      but only a colon, which makes the call syntax consistent with
      that for macros.

          Keywords are symbols, but are kept in their own
          package.  SYMEVAL of a keyword works, and returns
          that same keyword.  INTERN must arrange for the value
          of a keyword to be that keyword when that keyword is
          interned in the keyword package.

   4. Should the third (tolerance) argument to MOD and REMAINDER be
      eliminated?

          Yes.

   5. Should all tolerance arguments be eliminated?  This would
      include elimination of FUZZY=.

          Yes.

   6. Should arrays of identical size whose elements match be
      EQUALP, even if their element storage format is different?
      (Example:  can a bit-vector be EQUALP to an array of pointers
      that happens to contain only the integers 0 and 1?)

          Yes, EQUALP descends into arrays and does this.  On
          the other hand, EQUAL descends essentially only into
          things that self-evaluate.  This will be clarified
          explicitly.

   7. While EQL is the best default test for the sequence
      functions, is it better to make MEMBER, DELETE, and ASSOC
      continue to use EQUAL for backward compatibility?  Perhaps
      alternative names for the general, EQL-defaulting case can be
      found?

          EQL will be used for everything.  Consistency is more
          important than compatibility here.

   8. Scope and extent of GO and RETURN.  Can one GO out from an
      argument being evaluated?  Can a GO break up special variable
      bindings?  Can a GO break up a CATCH?  Does GO work despite
      funargs?

          Yes to all of these.  The tags established by a PROG
          have dynamic extent and lexical scope; the same goes
          for RETURN points.  Compilers are expected to
          distinguish the obvious easy cases from the hard
          ones.

   9. Forbid multi-dimensional arrays to have fill pointers?

          Yes.

  10. Should updating functions be eliminated in the white pages in
      favor of consistent use of SETF?

          Keep RPLACA, RPLACD, and SETQ out of respect for
          tradition.  All the others can go.  This solves the
          controversy surrounding PUTPROP, as well as the
          difficulty with ASET and VSET differing in their
          argument order.

  11. Is the use of * in type specifiers satisfactory to indicate
      missing elements?  (RMS suggested use of NIL, but there is a
      problem: (ARRAY INTEGER ()) means a 0-dimensional array of
      integers, while (ARRAY INTEGER *) means any array of
      integers.)

          Yes.

  12. Should &KEY be allowed in DEFMACRO?

          Yes.

  13. Should complex numbers be required of every COMMON LISP
      implementation?

          There was discussion to the effect that the precise
          definitions of the branch cuts is still in a sate of
          flux.  There are minor differences between the APL
          proposal and the proposal by Kahan that encompasses
          proposed IEEE floating-point format.  Keep complex
          numbers in the manual, with a note that the precise
          definitions are subject to change and are expected to
          be tied down before January 1, 1984, at which time
          they will be required of all COMMON LISP
          implementations.

  14. Is the scheme outlined for DEFSTRUCT, wherein constructor
      macros can actually be functions because of a conventional
      use of keywords, acceptable?

          Yes.  Also note that the various functions may be
          automatically declared INLINE at the discretion of
          the implementation.

  15. Why should the DEFSTRUCT default type be anything in
      particular?  Let it be whatever is implementationally best,
      and don't mention it.

          Simply note that TYPEP of two arguments must work
          properly on structures in the default case.  For
          example, after SHIP is defined, and X is a ship, then
          (TYPEP X 'SHIP) must be true, and (TYPEP X 'ARRAY)
          may or may not be true.

  16. Proposed to flush DEFSTRUCT alterant macros, advising the
      user always to use SETF.

          Yes.  However, there must also be a way to provide
          one's own SETF methods via DEFSETF.

  17. Can we standardize on keywords always being used as
      name-value pairs?  The worst current deviants are
      WITH-OPEN-FILE and DEFSTRUCT options.

          Yes.  The Lisp Machine LISP group will make a
          proposal soon for OPEN, WITH-OPEN-FILE, and
          DEFSTRUCT.

  18. What types may/must be supertypes of others?  What types may
      overlap, and which must be mutually exclusive?  An explicit
      type tree is needed.  Examples: can bignums be vectors?  Are
      BIT-VECTOR and (ARRAY (MOD 2)) identical, disjoint, or
      overlapping?

          Let ``>'' means ``is a supertype of''.  Let ``#''
          mean n-ary ``is disjoint from''; ``A#B#C#D'' means
          that A, B, C, and D are pairwise disjoint.  Let ``#''
          have higher precedence that ``>'', so that
          ``Z>A#B#C'' means that A, B, and C are pairwise
          disjoint subtypes of Z.  Then:

              t > common > cons # symbol # array # number
                           # character
              number > rational # float # complex
              rational > integer # ratio
              integer > fixnum # bignum
              float > short-float
              float > single-float
              float > double-float
              float > long-float
              character > string-char
              array > quickarray/vector

          The four subtypes of FLOAT are such that any pair are
          either identical or disjoint.  The type COMMON
          encompasses all data types defined in the white
          pages; perhaps its definition should be made
          carefully so that, for example, an implementation can
          introduce new kinds of numbers without putting them
          under COMMON.  So, perhaps COMMON should instead be
          defined to be

              COMMON > cons # symbol # array # rational
                 # short-float # single-float # double-float
                 # long-float # standard-char # hash-table
                 # readtable # package # pathname # stream

          Anyway, you get the idea.

  19. Are there type names (for Table 4-1) such as RATIONAL,
      FUNCTION, STRUCTURE, PACKAGE, HASH-TABLE, READTABLE,
      PATHNAME, and so on?

          Yes, except for STRUCTURE.  Also, eliminate
          STRUCTUREP.

  20. How can one ask, ``Is this an array capable of holding
      short-floats?''?

          Invent a function that extracts this information from
          an array.

  21. Rename DEFCONST to avoid conflict with Lisp Machine LISP.  (I
      think the November meeting actually voted for DEFVALUE, but I
      forgot to edit it in.  --GLS) DEFCONSTANT would do.  What
      Lisp Machine LISP calls DEFCONST should go into COMMON LISP
      as DEFPARAMETER or something.

          Rename what the COMMON LISP manual now calls DEFCONST
          to be DEFCONSTANT.  Introduce a new construct
          DEFPARAMETER to do what Lisp Machine LISP DEFCONST
          does.  Retain DEFVAR with that name.

  22. Should one allow both required and optional keyword
      parameters?

          No; have only optional keyword parameters.  However,
          permit the use of ordinary &OPTIONAL parameters and
          &KEY parameters together, withg the former preceding
          the latter.

  23. Should &REST be allowed with &KEY after all?  How about
      &ALLOW-OTHER-KEYS?  (It turns out these features are useful
      for gathering up all your keyword arguments and letting some
      sub-function inherit them.)

          Yes.  Also, state that if a key is duplicated as an
          argument the leftmost one prevails and the others are
          ignored (a GET-like model).

  24. Should EQUAL be allowed to descend into arrays?  Vectors?

          No and yes.  See issue 6.

  25. Proposed not to attempt to standardize on a package system
      for COMMON LISP at this time.  Reserve the colon character
      for the purpose, and explain a bit about how to use it, but
      don't tie down all package details.

          Agreed.  State that there are packages, and that they
          are used as arguments to certain functions such as
          INTERN.  State explicitly that inheritance
          properties, if any, are undefined.  State that all
          uses of colon except for keyword syntax are reserved,
          but mention the general intent of the notation
          FOO:BAR.

  26. Various problems with pathnames: generic pathnames,
      interning, :UNSPECIFIC, logical pathnames.

          GLS and SEF will propose a very stripped-down subset
          of what is presently in the COMMON LISP manual.  RG
          and Symbolics may also make proposals.

  27. What is the maximum array rank?  Is it implementation-
      dependent?  If so, what is the minimum maximum?

          The minimum maximum shall be 63.

  28. What special forms may be documented to be macros, in order
      to minimize the number of special forms?

          There is agreement so to minimize the number of
          special forms.  GLS will make a proposal.

  29. Should a way be provided for the user to define functional
      streams?  If not, should DEFSELECT and SELECT-expressions
      remain in the language?

          COMMON LISP will, for now, not specify a way to
          create functional streams.  DEFSELECT and select-
          expressions shall be deleted.  HIC will propose
          within two weeks a simplified instance system similar
          to the ones in MACLISP and NIL intended to support
          object-oriented programming while remaining neutral
          with respect to inheritance issues, to encourage
          experimentation.

  30. Are COMMON LISP arrays stored in row-major order?  If not,
      what is the interaction with displaced arrays?

          Row-major order shall be used.

  31. It is silly to have two of every I/O function, one for
      integers and one for characters.  Flush one set (TYI, TYO,
      TYIPEEK, ...) and leave the other (INCH, OUCH, INCHPEEK,
      ...).

          Agreed to eliminate the TYI series and to rename the
          others to eliminate the ``cute'' names.  The new
          names will be:

              Old name            New name
              inch                read-char
              ouch                write-char
              in                  read-byte
              out                 write-byte
              inchpeek            peek-char
              (none)              peek-byte

  32. Should some value be reserved for eof-value to mean the same
      as not supplying any?

          All occurrences of an eof-value parameter shall be
          replaced by two &OPTIONAL parameters eof-errorp
          (defaulting to true) and eof-value (defaulting to
          NIL, and meaningful only if eof-errorp is false).

  33. FORCE-OUTPUT should not wait, but just initiate I/O.  There
      should be a FINISH-OUTPUT (which implies FORCE-OUTPUT) that
      does wait.

          Yes.

  34. Should all vectors have fill pointers?  If so, should nearly
      all functions consistently use the active-length?

          An array may or may not have a fill pointer.  Vectors
          (``quickarrays'') shall be defined as a subset of
          arrays in such a way that they have no fill pointers.
          All functions that use arrays will use the fill
          pointer to bounds-check and limit access, except AREF
          (and SETF thereof).  Array slots beyond the fill
          pointer are still alive and may not be gratuitously
          garbage-collected or otherwise destroyed.

  35. Should HAULONG be changed from its current definition
      ceiling(log (abs(integer)+1)) to the one proposed by EAK, namely
                 2

      if integer<0 then ceiling(log (-integer)) else ceiling(log (integer+1))
                                   2                            2

      ?  With either definition, a non-negative integer n can be
      represented in an unsigned byte of (HAULONG n) bits.  With
      EAK's definition, it is also true that an integer n (positive
      or negative) can be represented in a signed byte of (+ (HAULONG N) 1)
      bits.

          Adopt the EAK definition under the name integer-
          length.

  36. Should HAULONG and HAIPART be given more reasonable names?

          Eliminate both HAULONG and HAIPART.  Put
          compatibility notes under INTEGER-LENGTH and LDB.

  37. How should the IEEE proposed floating-point standard be
      accommodated?  In particular, what about the trichotomy of <,
      =, and >, and how might underflow/infinity/NAN values be
      handled?

          Agreed that COMMON LISP must permit the use of IEEE
          proposed floating-point format and operations.
          Statements about such matters as trichotomy must be
          carefully worded.  Suggestions will be solicited from
          RJF concerning such accommodation.

  38. If PROGV has more variables than values, proposed that the
      extra variables be initialized to ``unbound'' rather than
      NIL.  This is already done in MACLISP.

          Yes.  (It was suggested that a similar thing be done
          with LET and PROG: (LET ((A ()) B) ...) makes A bound
          to NIL, but B unbound (that is, an error to refer to
          it before it is set).  My notes are unclear as to
          whether this was agreed to.)

  39. Shall EXCHF be generalized to take n locations and
      left-rotate them?  Shall SWAPF be correspondingly generalized
      to take N locations and a value and left-shift them?  (Suzuki
      indicates that these are useful primitives and lead to more
      understandable code in some cases.)

          PSETF, a parallel SETF shall be introduced; so shall
          a multiple-pair sequential SETF.  GLS is to propose
          Suzuki-type primitives with better names that EXCHF
          and SWAPF.

  40. Shall TYPEP of one argument be renamed to something else, or
      eliminated?

          Rename it to be TYPE-OF.  Note that while the results
          are implementation-dependent, they can be used in
          portable code, for example, by handing the result,
          without further examination, to MAP or CONCATENATE.

  41. In pathnames, shall names and types also be allowed to be
      structured?

          Deferred.  See issue 26.

  42. Should the interpreter be required or encouraged to check
      type declarations?  At binding time?  At SETQ time?

          Encouraged but not required.  That is, violation of
          type declarations ``is an error'' but does not
          ``signal an error''.

  43. How should complex numbers be notated?  With #C syntax?
      Using an infix J?  In the form x+yI?  Examples: #C(0 1),
      #C(3.5E-7 -15/3); 0J1, 3.5E-7J-15/3; 1I, 3.5E-7-15/3I.

          Retain #C syntax.

  44. How about using :OPTIONAL instead of &OPTIONAL, and so on?

          No; retain &OPTIONAL.

  45. Rename CEIL and TRUNC to CEILING and TRUNCATE?

          Yes.

  46. Should minimum precision and exponent range be specified for
      each of the floating-point formats?

          Yes, but the table in the COMMON LISP manual does not
          accommodate Lisp Machine LISP short-floats and S-1
          LISP short-floats.  GLS will fix this.

  47. Should it be specified that if an implementation provides
      IEEE proposed floating-point format, that the single and
      double formats shall in fact be the IEEE single and double
      formats?

          Yes; however, carefully word it, because the IEEE
          proposed standard permits implementation of single-
          precision format without implementing double-
          precision format.

  48. Revise the format for vectors, structures, and so on, all to
      use #(...) syntax.  Boxed vectors can be #(V ...), arrays can
      be #(ARRAY ...), complex numbers #(C 0 1), and structures
      #(SHIP ...).  RMS says this will be easier for EMACS-like
      editors to parse.

          No; this was judged harder for people to read.  Let
          the editors be fixed.

  49. Are variables truly to be lexically, rather than locally,
      scoped?

          Yes.

  50. Are FLET, LABELS, amd MACROLET worth keeping?

          Yes.

  51. Rename multiple-value constructs to all have the same prefix,
      either MV, MV-, or MULTIPLE-VALUE-, consistently.

          The prefix ``MULTIPLE-VALUE-'' will be used
          consistently.

  52. Proposed to keep the names GET and REMPROP, and rename
      PUTPROP to PUT (revising argument order), rather than current
      names GETPR, PUTPR, and REMPR.

          The names GET and REMPROP will be used.  PUTPROP is
          eliminated in favor of SETF of GET.

  53. The definition of ADJUST-ARRAY-SIZE on multi-dimensional
      arrays seems to follow from implementation considerations,
      rather than because it is useful to a user.  ARRAY-GROW is
      more user-useful.  Flush ADJUST-ARRAY-SIZE?

          MOON has a proposal that a function of this kind
          should take keywords much as MAKE-ARRAY does, but
          also take an ``old array'' that is made to conform to
          the new specifications.  GLS will make a concrete
          proposal.

  54. Should things like CHARPOS and LINENUM be built in?

          No, eliminate them.

  55. Flush MAKE-IO-STREAM and MAKE-ECHO-STREAM; they are too
      simplistic and can't really handle the tight I/O coupling.

          Keep them, but find a better name for MAKE-IO-STREAM.
          They may be useful in simple cases.

  56. Should OUT be able to output other than positive integers?
      What about ways of putting other objects, such as
      floating-point numbers, out to binary files?

          No; it ``is an error'' for the argument to OUT (now
          named WRITE-BYTE) to be other than a positive integer
          that can fit into bytes of the size suitable to the
          stream.  GLS will make a proposal for other
          primitives to write floating-point numbers and other
          objects to binary files.

  57. Flush FQUERY, on the grounds that it is too hairy for simple
      things and not hairy enough for a general menu interface, for
      example?

          Yes, flush it.

  58. Should the INTERLISP SATISFIES type specifier be introduced?
      If so, perhaps it should take a function, not a form, as
      there are problems with when to evaluate the form.

          Yes.

  59. What about the proposed safety feature to prevent macros and
      special forms from being redefined as functions (signal a
      correctable error)?

          Eliminate this ``feature''.

  60. Proposed: (RESTART [block-name)] is essentially a jump to the
      top of the named block, a somewhat smaller sledgehammer than
      a full PROG with a GO.

          This appears to be a good idea; however, a more
          detailed proposal is required to clarify such points
          as whether a RESTART within a PROG unbinds and
          rebinds the variables.

  61. Proposed: (CYCLE . body) is like a BLOCK with no name and an
      implicit RESTART at the end.  This is a new name for
      DO-FOREVER.  Certain loops that are clumsy to do with DO are
      lots easier with this, without a full PROG.

          Yes, but call it LOOP, as this is a special case of
          the forthcoming LOOP proposal.

  62. If a GO or RETURN is permitted to pass out of a CATCH-ALL or
      UNWIND-ALL, what arguments does the catcher function receive?


          Eliminate the current CATCH-ALL and UNWIND-ALL.
          Introduce a new function CATCH-ALL that is just like
          CATCH but takes no tag and catches any attempt
          whatsoever to unwind.  The return values for a GO and
          other odd cases must be defined.

  63. Is the IGNORE declaration acceptable?

          Yes.

  64. Is the OPTIMIZE declaration acceptable?

          It is a good idea but inadequate as currently
          defined.  SEF will make a new proposal.

  65. How should symbols that belong to no package be printed?  A
      suggestion: ``#:pname''.  The reader should read this as a
      non-uniquized symbol.  If the same gensym appears several
      times in the same printed expression, that can be handled by
      the #= and ## syntax.

          Reserve this syntax pending a proper package
          proposal.

  66. Proposed to retract GCD of complex rationals, and restrict
      GCD to integer arguments.

          Yes.

  67. Is PUSHNEW as a predicate useful, or should the simpler
      definition be adopted?

          Use the simpler definition.

  68. PUSHNEW should take the :TEST keyword.

          Yes.

  69. Should the :TEST-NOT keyword be flushed for ADJOIN, UNION,
      INTERSECTION, SETDIFFERENCE, and SET-EXCLUSIVE-OR?

          Yes.

  70. What about pervasive package syntax?  Is ``SI:(A B C)''
      legal?

          Yes.  Actually, this syntax is reserved for whatever
          the package system looks like.

  71. For circular list syntax, should it be required that a
      reference #n# not occur before the #n= that defines it?

          Yes.  This restriction may be relaxed in the future.

  72. Rename the type STRING-CHAR to be STRING-CHARACTER.

          No.

  73. Rename the type RANDOM; that is an abuse of the word RANDOM.
      Suyggestion: INTERNAL.  It is not necessarily used at all; it
      is just a catch-all under which to put odd implementation-
      dependent things such as pointers into the stack or absolute
      memory.

          Eliminate the type RANDOM.  Introduce the new type
          COMMON (see issue 18).  Mention that there may be
          implementation-dependent data types.

  74. There needs to be a kind of BLOCK to which RETURN is
      oblivious.  It is primarily useful for macro definitions, so
      it need not have a simple name.  How about INVISIBLE-BLOCK?
          GLS and SEF will make a better proposal.

  75. Proposed to flush DEFMACRO-CHECK-ARGS: the macro should
      always perform this error check.

          Yes.  At least, whether the error check is done
          should be left to the implementation just as
          wrong-number-of-arguments-to-a-function is.

  76. Proposed to flush DEFMACRO-MAYBE-DISPLACE and macro-
      expansion-hook; the former is useless and the latter is not
      general enough.

          Deferred.

  77. Proposed to make MACROEXPAND-1 be the sole standard hook for
      getting at a macro expanding function; this means MACRO-P
      should not return the macro function.  This allows the
      implementation to provide whatever memoizing scheme
      appropriate.

          Interesting idea; deferred.  MOON and SEF will make
          proposals on this issue and the previous one.

  78. Need some kind of declaration to locally shadow a globally
      pervasive SPECIAL declaration.

          The pervasiveness of such declarations must be
          clarified.  Sample code for EVAL should appear in the
          COMMON LISP manual.  GLS will propose such code.

  79. Functions that take two sequences should not accept :START
      and :END, only :START1 and friends, to minimize confusion.

          Yes.

  80. All built-in MAKE- functions should take keywords.

          Yes.

  81. There should be only one function for creating hash tables,
      and it should take a :TEST keyword.

          Yes, but the value for this keyword is restricted to
          a small set of possibilities.

  82. One-argument FLOAT should either always return a single-
      float, or use the format specified by read-default-float-
      format.

          One-argument FLOAT will always return a SINGLE-FLOAT.

  83. Proposed to make the second argument (the divisor) to MOD and
      REMAINDER required, not optional.

          Accepted.  The one-argument case is obtained by
          providing 1 as a second argument, which is much
          clearer.

  84. If RANDOM can take two arguments, the first effectively
      optional and the second required, why cannot LOG do the same?
      How about EXP, too?

          The second (optional) argument to RANDOM shall be
          eliminated.

  85. TRUENAME of a string should look in the file system, not just
      return the string.

          Yes.

  86. WITH-OPEN-FILE should not be specified to ask the user; if
      anything, it should merely specify that an error is
      signalled.

          Yes.

  87. The keyword arguments to LOAD should be fixed up in a way to
      be proposed by MOON.

          MOON will make a specific proposal.

  88. Can DEFUN be used to define properties?  How about more
      general function-specs, as in Lisp Machine LISP?

          Function-specs are tentatively accepted pending a
          specific proposal.

  89. Let declarations and documentation-strings occur in any order
      in a DEFUN and similar forms.

          Yes.

  90. Provide a functional interface for accessing documentation
      strings, rather than mentioning the DOCUMENTATION property.

          Deferred for discussion by network mail.

  91. Clarify the status of the DOLIST/DOTIMES variable when the
      result-form is executed.  Proposed: for DOLIST, variable is
      bound and has NIL as its value; for DOTIMES, variable is
      bound and has as value the value of the countform.

          GLS will make a proposal.  Feelings were not strong
          except that the issue must be tied down.

  92. Is VALUES a function?  Or should it, like PROGN, really be
      regarded as a special form?

          It is a function.

  93. Should LOCALLY be retained, or should one simply write (LET
      () ...)?

          Retain LOCALLY.

  94. Extend THE to handle multiple values?  One way is to provide
      a limited type specifier so that one may write

          (mvcall #'+ (the (values integer integer) (floor x y)))

          Yes.

  95. Should compiler warnings of unrecognized declarations be
      required or merely recommended?  Perhaps required as the
      default, but a switch may be provided?

          Agrred that it is probably a good idea to require it,
          provided that a declaration may be made to indicate
          that a particular declaration is legitimate.  GLS
          will make a specific proposal.

  96. There should be a kind of FLOAT that accepts a type specifier
      instead of an example of that type.  (But the kind that takes
      an example is useful too.)

          The function TO should be renamed COERCE, take a type
          specifier as second argument, and be extended to
          other cases such as floats.

  97. Have a function that somehow extracts the fraction from a
      floating-point number and returns it as an integer.
      Proposed: FLOAT-FRACTION-INTEGER takes a floating-point
      number x and returns two integer values; the second is the
      precision p of the representation, and the first is a value j
      such that (= j (SCALE-FLOAT (FLOAT-FRACTION x) p)).  Or
      perhaps this should be two separate functions.

          MOON will make a proposal.  The term fraction should
          be replaced where appropriate by significand, as
          there can be confusion with integer-part/fractional-
          part.

  98. Flush MASK-FIELD and DEPOSIT-FIELD?

          No, keep them.

  99. Is the proposed definition of backquote acceptable?

          The printed copies of the COMMON LISP manual did not
          make backquotes visible.  GLS will send the proposal
          out by network mail for discussion.

 100. STRING-CHARP should be true of <space>.

          Yes.

 101. Rename GRAPHICP and ALPHAP to GRAPHIC-CHARP and ALPHA-CHARP.


          Yes.

 102. Introduce CHAR<=, CHAR>=, and CHAR/=, and let the character
      comparators take multiple arguments as for the numeric
      comparators. (But note that (char<= #\A X #\Z) doesn't
      guarantee that X is a letter.)

          Yes.

 103. In STRING-CAPITALIZE, should digits count as word-
      constituents, even though they don't have case?

          Yes.  (This is as in EMACS.)

 104. Do not have both DIGIT-CHARP and DIGIT-WEIGHT.

          Flush DIGIT-CHARP; let DIGIT-WEIGHT return NIL for a
          non-digit.

 105. Introduce a function MAKE-SEQUENCE taking a type, length, and
      a keyword :INITIAL-VALUE.

          Yes.

 106. CATENATE or CONCATENATE?  The OED says they are semantically
      identical.

          CONCATENATE it is.

 107. Be sure to add REMOVE-DUPLICATES and DELETE-DUPLICATES.
          Yes.

 108. Suggest letting NIL as a return type to MAP mean return no
      value, to get a MAPC-like effect.

          Yes.

 109. Flush :FROM-END keyword for the COUNT function?

          No, keep it for consistency, even though it is
          useless.

 110. What should be done about SUBST and SUBLIS?

          Have four functions SUBST, NSUBST, SUBLIS, and
          NSUBLIS.  All take the usual applicable sequence
          keywords, particularly :TEST.  They do operate on
          cdrs.  The non-destructive versions do maximal
          sharing; (SUBST () () X) will no longer be a good way
          to copy X.  Give a sample definition of SUBST in the
          COMMON LISP manual.

 111. Flush the restriction that the result of SXHASH be
      non-negative?

          Keep the restriction.

 112. What is the interaction of ARRAY-GROW and displaced arrays?

          This does the ``obvious right thing''.  Run-time
          access checks may be required if the displaced-to
          array is altered.

 113. Add WITH-INPUT-FROM-STRING and WITH-OUTPUT-TO-STRING?

          Yes, and note that the created stream has only
          dynamic extent.

 114. Should CLOSE take a simple flag or a keyword argument :ABORT,
      defaulting to NIL?

          A keyword argument: (CLOSE :ABORT T).

 115. Rename PRIN1STRING to be PRIN1-TO-STRING.

          Yes.

 116. Rename FILEPOS to FILE-POSITION.

          Yes.

 117. Rename COMFILE to COMPILE-FILE?

          Yes.

 118. Reconsider the problem of getting at file attributes, such as
      author.

          A single function GET-FILE-INFO should take a stream
          and a keyword indicating what is desired.

 119. Add COMPILER-LET?

          Yes.

 120. Rename the type SUBR to be COMPILED-FUNCTION.

          Yes.  Also rename SUBRP.

 121. Note that implementations may provide other &-keywords for
      lambda lists (these won't be portable, however).

          Yes.  Document the variable LAMBDA-LIST-KEYWORDS.

 122. Rename the ONEOF type specifier to be MEMBER.

          Yes, in principle; tie this to the outcome of MEMBER.
          (This came out all right (issue 7), so I take this to
          be an unqualified yes.)

 123. The syntax of ratios should be clarified.  Proposal:
      ratio ::= [sign] {digit}+ / {digit}+

          Yes.

 124. Proposed to call the page-separator character #\PAGE instead
      of #\FORM.

          Yes.

 125. Proposed that all COPY functions should be spelled COPY-.

          Yes, except if a function is named just ``COPY'',
          don't call it ``COPY-''!

 126. Proposed: a new FORMAT directive ~$, as in MACLISP, for
      better control over floating-point number printout.

          Yes.

 127. Proposed: a new FORMAT directive ~/.../, where ``...'' is a
      picture, for pictorial representation of integer and
      floating-point printout, as in PL/I and COBOL.  Details are
      to be determined, but as possible examples:

          Value      Picture               Result
          65.67      ~/$$,$$$,$$9.V99 CR/  "       $65.67   "
          0.0        ~/$$,$$$,$$9.V99 CR/  "        $0.00   "
          -65432.01  ~/$$,$$$,$$9.V99 CR/  "   $65,432.01 CR"
          -65432.01  ~/$*,***,**9.V99 CR/  "$***65,432.01 CR"
          -65432.01  ~/$Z,ZZZ,ZZ9.V99 CR/  "$   65,432.01 CR"
          6.5        ~/S9.V99999ES99/      "+6.50000E+00"
          .0067      ~/S9.V99999ES99/      "+6.70000E-03"
          456        ~/ZZZZZ9/             "   456"
          456        ~/999999/             "000456/

      Some study of existing picture formats would be necessary.
      If it's done right, EDIT instructions on machines such as the
      IBM 370 and DEC VAX might be applicable.

          General sympathy for this idea, but GLS must make a
          concrete full proposal.

 128. Proposed: a new FORMAT directive ~U that prints
      floating-point numbers in exponential form, with the exponent
      a multiple of three, and also outputs a standard metric
      prefix such as ``kilo'' to match.

          Yes, in principle; a complete proposal will be
          discussed by network mail.

 129. Proposed: a new FORMAT directive ~(...~) for case conversion.
      No flags means force to lower case; colon capitalizes all
      words; atsign capitalizes just the first letter, lower-casing
      all others; colon and atsign forces to upper case.  This is
      useful for such things as

          (defun foo (n) (format () "~@(~R~) error~:P detected" n))
          (foo 0) -> "Zero errors detected."
          (foo 1) -> "One errors detected."
          (foo 23) -> "Twenty-three errors detected."

          Yes, but better characters than ``('' and ``)''
          should be found.  GLS will make a proposal.

 130. Proposed: in FORMAT, eliminate ~[ from COMMON LISP, but
      retain the colon and atsign versions.

          No, keep it.

 131. Proposed: new FORMAT directive ~? to mean that an argument is
      to be interpreted as a control string, as if inserted at that
      point.  This is simpler than remembering to use ~1{~:}.

          Yes.  Look for a better character.

 132. Proposed: FORMAT directives to perform FORCE-OUTPUT and
      CLEAR-OUTPUT.

          No!  Fix the manual under FORCE-OUTPUT and
          CLEAR-OUTPUT.

 133. Should SETDIFFERENCE be renamed to be SET-DIFFERENCE?

          Yes.

 134. Should PUTHASH take arguments in the order key, hash-table,
      value?

          This is no longer relevant; see issue 10.

 135. Is it all right to make UNION and INTERSECTION take only two
      arguments, in order to accept the :TEST keyword?

          Yes.

 136. Consider changing BUTTAIL back to LDIFF.

          Yes.

 137. Is the definition of CHARACTER acceptable?

          Yes.

 138. Should GCD and LCM take any number of arguments, or exactly
      two?

          Leave them alone, taking any number.

 139. Should there be a DO-PROPERTIES to complement MAP-PROPERTIES?


          Flush them both.

 140. Should REMOB get a better name, say UNINTERN?

          Yes.

 141. Should there be a DEFPR to replace DEFPROP, or should this
      just be flushed?
          Flush DEFPROP.

 142. Should RANDOM take a RANDOM-STATE as an optional argument,
      rather than looking at a special variable?

          Yes; the optional argument defaults to the special
          variable now defined.

 143. Add a SUSPEND function?  What are its defined properties?

          No.

 144. Make the character-bag in STRING-TRIM optional, defaulting to
      the space character (alternatively, all whitespace
      characters).

          No; it would be too confusing, and it's not hard to
          specify the bag explicitly.  The character-bag may be
          any sequence containing characters.

 145. Should REMAINDER be renamed REM?

          No; too much chance of confusion with REMOVE or
          REMPROP.

 146. Should something be done about the fact that BYTE specifiers
      use a start-count (actually, a count-start) convention, while
      the rest of the language uses a start-end convention?

          This is a duplicate of issue 2.

 147. Syntax for non-decimal floating-point numbers?

          No.

 148. Shall PRIN1 be required or encouraged to print radix
      specifiers in lower case (e.g., #O instead of #O) for
      readability?

          Yes, required.

 149. Rename GET-PNAME to SYMBOL-PRINT-NAME.

          Yes.  Moreover, create a series of five parallel
          names:

              symbol-pname
              symbol-package
              symbol-plist
              symbol-function
              symbol-value

 150. Disposition of BOOLE: should it be as in MACLISP?  Should it
      remain two-argument?  Should it have the hairy EAK
      definition?

          As far as COMMON LISP is concerned, it takes two
          (that is, three) arguments.

      This is the last of the issues on the original agenda.  The
      following additional items were brought up at the meeting.

 151. Shall FIRST and its friends be provided?

          The following shall be added to COMMON LISP:  FIRST,
          SECOND, THIRD, FOURTH, FIFTH, SIXTH, SEVENTH, EIGHTH,
          NINTH, TENTH, and REST, all operating on lists only.

 152. Should 1E3 be considered to be floating-point syntax?
      MACLISP says no, Lisp Machine LISP and INTERLISP say yes.

          Yes.

 153. Should TRACE be a special form or a function?

          A function, taking a function spec and keyword
          arguments.  A proposal will be forthcoming.

 154. A proposal for CHECK-ARG-TYPE will be made.

 155. Should there be a predicate KEYWORDP?

          Yes.

 156. There will be a proposal for lambda macros and compiler-only
      macros (optimizers).

 157. Should there be a TREE-EQUAL predicate that takes a :TEST
      keyword for use on leaves?

          Yes.

 158. Consider the naming conventions of T:

         - XXX? instead of XXXP for predicates.

         - All special variables have names beginning and ending
           with ``*''.

          No action.

 159. Mention prominently in the section on the reader that the
      characters !?[]{} are reserved for user read-macros.

 160. DLW will propose an improved error-handling system.

 161. Should FUNCALL* be eliminated, and APPLY generalized to be
      FUNCALL*?

          Yes.
-------