PROMPT-FORPROMPT-FOR with the following syntax:
(PROMPT-FOR typespec &optional format-string &rest format-arguments)
This function would prompt for an object for which (TYPEP object 'typespec) was true. Prompting would begin on a fresh line. The FORMAT-STRING and FORMAT-ARGUMENTS would be used to do prompting; if not supplied, the default prompt would be something like "Enter an expression of type <typespec>: ". The expression would be parsed by READ and checked to assure that it was of the appropriate type. If it was not of the appropriate type, the system would indicate the problem and ask the user for a correction. The entire interaction would take place on the stream in *QUERY-IO*.
2. Currently, this function could be written a user program: (DEFUN PROMPT-FOR (TYPESPEC &OPTIONAL FORMAT-STRING &REST FORMAT-ARGUMENTS) (FLET ((GET-INPUT () (FRESH-LINE *QUERY-IO*) (COND ((NOT FORMAT-STRING) (FORMAT *QUERY-IO* "Enter an expression of type ~S: " TYPESPEC)) (T (APPLY #'FORMAT *QUERY-IO* FORMAT-STRING FORMAT-ARGUMENTS))) (READ *QUERY-IO*))) (DO ((FORM (GET-INPUT) (GET-INPUT))) ((TYPEP FORM TYPESPEC) FORM) (FORMAT *QUERY-IO* "~&The object ~S is not acceptable.~%" FORM)))) However, such an implementation is at a severe disadvantage because:
a. The prompt and the call to READ are not closely coupled. If the user clears the screen in the middle of the READ -- an operation allowed by many rubout processors, there is no way to know that a prompt should have been redisplayed. By coupling prompting and reading into a single component supplied by the system, prompting can be accomplished using primitives that are beyond the scope of the current spec.
b. On Lisp Machines, for example, this type check could be accomplished from within the rubout handler, allowing the user to rub back into the expression to correct it rather than requiring that he be reprompted. In other implementations, such might not be possible, but it still might be desirable to stuff the input buffer with the offending expression on subsequent calls to READ so that it could be easily edited. That cannot currently be done from user code.
Some programs would have more useful prompting and error recovery behaviors.
The emerging Error System compounds the need for this because many kinds of error recovery strategies involve prompting for corrected data and verifying that the values read are of some particular type. As such, this primitive will probably eventually be in your Common Lisp either privately as an internal part of the error system or publicly. Since it is useful for a wider variety of things, it would seem worth making it standard.
KMP made this proposal, so he supports it.
In notes made by Pavel Curtis on the emerging error system, he complained that the READ-TYPED-OBJECT primitive used in many of the examples was not defined in the proposal. He didn't complain similarly for other more whimsical things not defined. KMP took this as implicit support for the idea that some sort of facility like this might be welcomed by the Xerox crowd.
Symbolics has recently introduced an extension called ACCEPT which does something similar, but uses stylized readers on a per-type basis. It should be clear that this proposal intends to propose that READ be used in all cases. The Symbolics ACCEPT primitive is very useful but requires more baggage than I think CL would be willing to accept at this time.