FORMAT-STRING-ARGUMENTSPRETTY-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.
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.
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.
FORMAT anyway. Both proposals probably involve changes to documentation.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.
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.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.