Issue FORMAT-STRING-ARGUMENTS Writeup

Issue:               FORMAT-STRING-ARGUMENTS

References:          

Related issues:      Issue PRETTY-PRINT-INTERFACE

Category:            CLARIFICATION, CHANGE

Edit history:        V1, 10 May 90, Sandra Loosemore


Problem description:


Issue PRETTY-PRINT-INTERFACE says that

    The function FORMAT is extended so that it can accept a

    function instead of a FORMAT string.  (This change is also made

    in the other functions that accept FORMAT strings such as ERROR

    and WARN.)


The pretty printer proposal did not explicitly address whether

this also affects the :FORMAT-STRING slot of simple-condition 

objects, and whether any macros (as well as functions) specified 

in the standard were affected by the change.


Also, there is potential for confusion in using the terminology

"format strings" to refer to objects that are now permitted to

be either strings or functions.


There are two proposals, SPECIFY and RETRACT.


This is issue #1 from Loosemore's list.


Proposal (FORMAT-STRING-ARGUMENTS:SPECIFY):


  (1) Clarify that the following functions and macros which formerly were

  specified to take format strings as arguments now accept either

  a format string or a format function:


  ASSERT (datum; treated like a string argument is now)

  BREAK (format-string)

  CERROR (both continue-format-string and datum arguments)

  DEFINE-METHOD-COMBINATION (:DESCRIPTION argument)

  ERROR (datum; treated like a string argument is now)

  FORMAT (control-string)

  INVALID-METHOD-ERROR  (format-string)

  METHOD-COMBINATION-ERROR (format-string)

  SIGNAL (datum; treated like a string argument is now)

  WARN (datum; treated like a string argument is now)

  WITH-SIMPLE-RESTART (format-string)

  Y-OR-N-P (format-string)

  YES-OR-NO-P (format-string)


  (2) Clarify that the :FORMAT-STRING argument passed to MAKE-CONDITION

  to construct a condition which is a subtype of SIMPLE-CONDITION

  may be either a string or a function, and the accessor 

  SIMPLE-CONDITION-FORMAT-STRING can return either a string or a function.


  (3) Change the name of the :FORMAT-STRING argument to MAKE-CONDITION 

  associated with SIMPLE-CONDITION types to :FORMAT-CONTROL, and

  rename the accessor function to SIMPLE-CONDITION-FORMAT-CONTROL.  As

  an editorial matter, change all references to arguments now

  named "format-string" to "format-control".


  Rationale for proposal SPECIFY:


  Items (1) and (2) were probably what was intended by the

  PRETTY-PRINT-INTERFACE proposal.  Item (3) is a logical

  extension; since the arguments need not be strings, calling

  them "format-strings" is a misnomer.



Proposal (FORMAT-STRING-ARGUMENTS:RETRACT):


  (1) Retract the part of issue PRETTY-PRINT-INTERFACE that required

  FORMAT, related functions such as ERROR and WARN, and the ~?

  and ~{~} directives to accept format control functions as well

  as strings.


  (2) Remove the FORMATTER macro from the language.


  Rationale for proposal RETRACT:


  It is easier to remove this feature than to try to fix the rest

  of the language to be consistent with it.  Having a macro to

  "compile" format strings into functions is probably not useful

  in the absence of the extensions to FORMAT.

  


Current Practice:


  Unknown.  The pretty printer specification is a fairly recent

  addition to the language and it probably hasn't been fully

  integrated into any implementation yet.


Cost to Implementors:


  The actual implementation cost of extending the listed functions 

  and macros to accept function arguments is probably small, since

  in most cases they just pass the argument to FORMAT anyway.

  Both proposals probably involve changes to documentation.

  

Cost to Users:


  For proposal SPECIFY, the incompatible change to the name of the 

  :FORMAT-STRING slot of SIMPLE-CONDITION objects may cause some 

  problems for users who have started using the condition system

  in their code, but these ought to be fairly straightforward to 

  track down and fix.


  Proposal RETRACT may cause some problems for users who have

  started writing code which uses the FORMATTER macro and the

  extension to FORMAT to accept functions, but again the

  problems should generally be easy to find and fix.

  

Cost of non-adoption:


  Parts of the language are poorly specified.


Performance impact:


  The ability to "compile" format strings into functions in advance can

  potentially lead to greater runtime efficiency.  On the other

  hand, some implementations might implement FORMATTER in such a

  way that it is less efficient than passing a format string

  directly.  Furthermore, even without FORMATTER in the language,

  it is still possible for implementations to do a compile-time

  transformation to "compile" constant string arguments to FORMAT

  and related functions.


Benefits:


  The language is better specified.


Esthetics:


  Either proposal would be an improvement over the current

  situation.


Discussion:


  Conceivably, the FORMATTER macro could be left in the language

  even while removing the extensions to FORMAT and friends, but it's 

  not clear how useful this would be to users.


  Loosemore opposes other partial solutions (like requiring FORMAT 

  to accept both strings and functions but specifying everything else 

  to accept only strings) on the grounds that they would

  introduce additional, unnecessary complexity and inconsistency

  into the language.  If the feeling is that this feature belongs

  in the language, we ought to bite the bullet and do it

  properly.