Number: 94
Date: 17-Mar-84 0':13':13
Submitter: roach.PA
Source:
Subject: Proposal to provide custom PRIN1
Lisp Version:
Description: '
'
'
PROPOSAL TO ALLOW USER TO CUSTOMIZE PRIN1 PNAMES'
'
'
I have a PRETTYPRINTMACRO which arranges for (QUOTE FOO) to'
print as ''FOO and SYSPRETTYFLG set to T. When I do'
(MKSTRING ''''FOO)'
I get "(QUOTE FOO)" instead of the correct "''FOO". This bug also'
causes TTYIN not to prettyprint forms I try to FIX, since TTYIN calls'
MKSTRING.'
I propose that Interlisp allow the user to customize PRIN1 pnames'
via PRETTYPRINT or any other prettyprint package of the user''s'
choosing. It does not seem unreasonable to use a strategy similar to'
MACLISP''s top level. (The top level functionality really ought to be'
available everywhere in MACLISP. I may be idealizing a bit here, but'
there is no reason to try to adopt MACLISP''s bugs.)'
MACLISP''s top level uses atom PRIN1 as a global hook. If atom'
PRIN1 is bound to NIL, the user gets the default PRIN1 behaviour. If'
atom PRIN1 is bound to FN, FN gets called on the args passed to PRIN1.'
The implementation would probably resemble the definition'
(DEFINEQ (PRIN1 (LAMBDA (X FILE)'
(APPLY* (OR PRIN1 (FUNCTION \PRIN1)) X FILE)))) where \PRIN1'
is the default function. PRINT is implemented in terms of PRIN1. The'
MACLISP user can do (SETQ PRIN1 ''PRETTYPRIN1) where PRETTYPRIN1 comes'
from any of the available pretty print packages. PRETTYPRIN1, when it'
is about to call PRIN1, PRINT, or a user hook into the pretty printer,'
lambda binds atom PRIN1 to NIL. Binding atom PRIN1 to NIL avoids'
infinite recursion. A function such as MKSTRING would cause the'
printer to print to core before returning its result. The pretty'
print user does not have to count on a flag like SYSPRETTYFLG being'
spread around in the right places in the system code nor count (or at'
least drastically lessen the need to count) on other user''s packages'
to make calls to pretty printing functions like SHOWPRINT.'
I do not find using (MKSTRING ''%''FOO) to get "''FOO" to be an'
acceptable substitute. In the case of TTYIN printing "(QUOTE FOO)"'
instead of "''FOO" when I try to FIX an old expression, it isn''t me'
that is calling MKSTRING, it is somewhere in the depths of TTYIN that'
the call to MKSTRING is made. Even in more direct use of MKSTRING,'
NCHARS, CONCAT, CHCON, CHCON1, NTHCHARCODE, etc. it is unreasonable'
that these functions not work on an arbitrary list strucutre when I'
have SYSPRETTYFLG = T. Conceivalby I might struggle to smash all'
subexpressions of the form (QUOTE Y) into atoms %''Y before calling'
MKSTRING, but as we take more and more PRETTYPRINTMACROS I have into'
account (e.g. prettyprintmacros for backquote & commas), it is clear'
that I would be better off to write my own MKSTRING and associated'
functions. I am best off if the existing system functions were'
improved.'
The suggestion that I use (MKSTRING ''%''FOO) to get "''FOO" has a'
further glitch to it. (MKSTRING ''%''FOO) indeed returns "''FOO", but in'
my environment, which escape quotes character "''", it ought to be'
returning the string "%''FOO". Quote "''" is escape quoted in my'
environment so that atom %''FOO can be correctly distinguished from the'
list ''FOO (pretty form for (QUOTE FOO)). So while it is generally the'
case (even in an ordinairy environment without pretty printing) that'
(EQUAL X (READ (MKSTRING X))) is true,'
(EQUAL ''%''FOO (READ (MKSTRING ''%''FOO))) fails!'
My knowledge about system code is a bit spotty, but I see no'
reason why a MACLISP-like approach couldn''t be used at the \PRINDATUM'
level in Interlisp. Functions like MKSTRING should print to a scratch'
{CORE} file before returning (it would be convenient to have the pages'
of this file be pages in string space). Since PRIN1, PRIN2, etc., are'
implemented in terms of \PRINDATUM, MKSTRING may continue to give only'
"the PRIN1 pname", but the user may through prettyprinting have'
control over what "the PRIN1 pname" and "the PRIN2 pname" turn out to'
be. I consider this problem to be independent of the problem'
interfacing DEDIT with PRETTYPRINT which I do not see as a road block'
to implementing MKSTRING et al correctly or striving for some higher'
goal such as giving the user a \PRINDATUM hook.'
If the user could set a MACLISP-like \PRINDATUM hook to'
PRETTYPRINT, then, MKSTRING would return the PRIN1 pname, but'
the PRIN1 pname is calculated using PRETTYPRINT. The SYSPRETTYFLG is'
not as flexible since I can only choose between two printers offered'
by the system. Any ideas that there might be independently defined and'
unalterable notion about what the PRIN1 pname of an object should not'
be forced on Interlisp users. The example with (MKSTRING ''%''FOO)'
returning "''FOO" instead of "%''FOO" when "''" has ESCQUOTE syntax'
indicates that the inadequate behaviour results from more than just'
not taking PRETTYPRINTMACROS into account.'
Summary':'
(1) I propose that Interlisp allow the user to customize PRIN1'
pnames via PRETTYPRINT or any other prettyprint package of the user''s'
choosing.'
(2) The current implementation is biased against using'
prettyprintmacros or packages like PQUOTE and BQUOTE.'
(3) (MKSTRING ''%''FOO) is not an acceptable substitute for'
(MKSTRING ''''FOO).'
(4) Functions such as MKSTRING should cause the printer to'
print to core before returning a result. (Functions like NCHARS,'
which may not print, must nevertheless be intimately tied into the'
printer to guarantee correct answers.)'
(5) SYSPRETTYFLG can be abandoned in favor of the user''s'
setting a MACLISP-like \PRINDATUM hook to the prettyprinters chosen by'
the user.'
Workaround:
Test Case:
Edit-By: Sannella.PA
Edit-Date: 21-Mar-84 17':21':18
Attn: Kaplan.pa
Assigned To:
In/By:
Disposition:
System: Language Support
Subsystem: Read and Print
Machine:
Disk:
Microcode Version:
Memory Size:
File Server:
Server Software Version:
Difficulty:
Frequency: Everytime
Impact: Annoying
Priority: Unlikely
Status: Wish
Problem Type: Design - Impl
Source Files: