Issue READ-SUPPRESS-CONFUSING Writeup

Forum:		Public Review

Issue:		READ-SUPPRESS-CONFUSING

References:	Margolin's PR comment #2 (X3J13/92-1402)

		Margolin's PR comment #18 (X3J13/92-1418)

		Flanagan's PR comment #7 (X3J13/92-1907)

		Philpot's PR comment #1 (X3J13/92-2901)

		Barrett's PR comment #9 (X3J13/92-3109), part 2

		*READ-SUPPRESS* (X3J13/92-102 pp.23-21..22)

		Sharpsign P (X3J13/92-102 sec.2.4.8.14)

		Sharpsign C (X3J13/92-102 sec.2.4.8.11)

Category:	CHANGE

Edit history:	5 Jan 1993, Version 1 by Margolin

                22 May 1993, Version 2 by Loosemore (delete bogus reference

                  to ":" and "@" in dispatching macro syntax)

Status:		Proposal GENERALIZE passed 9-2 on letter ballot 93-302



Problem description:


  The description of *READ-SUPPRESS* is confusing and incomplete.  By

  specifying the behavior of particular read syntaxes rather than a simple,

  general strategy, some syntaxes (#C, #P, and#') have unintentionally been

  omitted.  And the wording of the description of the behavior of #(...) is

  unclear as to whether the vector syntax is parsed and ignored or a vector

  is actually constructed (there's a subtle difference between the CLtL and

  dpANS wording, due to the lack of a pair of parentheses in the dpANS).


  A strict reading of the current description of *READ-SUPPRESS* implies

  that the reader must still construct objects in response to these

  syntaxes (as well as user-defined reader macros that don't check the

  variable).  This is pretty wasteful considering that *READ-SUPPRESS*

  exists primarily to support #+ and #-, which discard what they read with

  *READ-SUPPRESS* true anyway.


  In the case of #P, the lack of specification of its *READ-SUPPRESS*

  behavior is a real annoyance, because some implementations have extended

  it to allow non-strings to follow it.  Users expect to be able to hide

  such extensions using #+, but this isn't valid.


Proposal (READ-SUPPRESS-CONFUSING:GENERALIZE):


  1) Replace the portion of the Description of *READ-SUPPRESS* from

  "Extended tokens" through the entry for "#A, #S, #:" with:


      When *READ-SUPPRESS* is true, READ, READ-PRESERVING-WHITESPACE,

      READ-DELIMITED-LIST, and READ-FROM-STRING all return a first value of

      NIL when they complete successfully; however, they continue to parse

      the representation of an object in the normal way, in order to skip

      over the object, and continue to indicate end-of-file in the normal

      way.  Except as noted below, any standard macro character (including

      dispatching macro sub-characters) that is defined to read a following

      object or token will do so, but not signal an error if the object

      read is not of an appropriate type or syntax.  Standard syntaxes and

      macro characters will not construct any new objects (e.g. when

      reading the representation of a symbol, no symbol will be constructed

      or interned).


      Dispatching macro characters (including #)


	  Dispatching macro characters continue to parse an infix numerical

	  argument, and invoke the

	  dispatch function.  The standard # dispatching macro characters

	  do not enforce any constraints on the value or existence of the

	  numerical argument.


  2) Create a Notes section that recommends that user-defined and

  implementation-defined macro characters behave analogously to the

  standard macro character, i.e. when *READ-SUPPRESS* is true they should

  ignore type errors when reading a following object and dispatching macro

  characters should allow NIL as an infix parameter.


  3) Change the specifications of #C and #P to specify that they are

  followed by the representation of an object.  Then specify how they are

  interpreted when those objects are a list of two real numbers (for #C) or

  a string (for #P).


Examples:


  (let ((*read-suppress* t))

    (dolist (string '("#(foo bar baz)" "#P(:type :lisp)" "#c1.2" "foo"))

      (unless 

        (ignore-errors

          (progn (print (read-from-string string))

                 t))

        (print 'error))))

  could print

  #(NIL NIL NIL)

  ERROR

  ERROR


Test Cases:


  (let ((*read-suppress* t))

    (mapcar #'read-from-string

            '("#(foo bar baz)" "#P(:type :lisp)" "#c1.2")))

  -> (NIL NIL NIL)


Rationale:


  1) Specifies a general behavior for *READ-SUPPRESS* that is applicable to

  all reader syntaxes that are described in terms of the representations of

  objects.


  2) Encourages implementors and users to extrapolate from this standard

  behavior.


  3) Specifies #P and #C in such a way that change 1 applies.


Current practice:


  For the Example form, Genera 8.1 prints NIL, NIL, NIL (it seems to

  implement the proposal); Lucid 4.1 and CMU CL 16d print NIL, ERROR, NIL;

  WCL 2.1 prints #(NIL NIL NIL), ERROR, ERROR.


Cost to Implementors:


  Should be minor.


Cost to Users:


  When *READ-SUPPRESS* is bound via #+ or #-, the change should be upward

  compatible, since any objects constructed by the reader will not be

  visible.  Direct users of *READ-SUPPRESS* may notice the difference, but

  it seems unlikely that anyone is depending on any of the current

  behaviors.


Cost of non-adoption:


  Users will have to avoid using some implementation-dependent syntaxes in

  #P macros.


Performance impact:


  Minor.


Benefits:


  More ability to include implementation-dependent syntax extensions in

  portable source code.


Esthetics:


  A general description of behavior is better than lots of specific cases.


Editorial Impact:


  Minor.  The changes are confined to the three sections mentioned above.


Discussion:


  Barmar originally wanted to specify that standard dispatching macros

  would parse the numerical argument but ignore it (always passing NIL to

  the dispatch function).  Flanagan convinced him to leave that part as it

  was originally (the numeric argument is parsed but standard dispatch

  functions don't enforce restrictions on it).  It doesn't seem to be a big

  deal either way.