Re: Enhancement suggestion: prin1 extension mechanism

[Helmut Eller]

* Stefan Monnier [2008-09-14 21:35+0200] writes:

>>> I fear it'd be difficult to make it work without incurring a significant
>>> performance overhead.
>
>> If the table is nil you could use the default hardcoded printer without
>> lookups.
>
> In many important cases (e.g. CL has been loaded), the table wouldn't be
> nil, and performance should still be good.

Why?  It could be nil by default, just like print-circle is nil by
default.

>> If the entries in the table can be accessed from Lisp code, we could
>> remember the default print function for a type before installing a
>> custom printer.  E.g. if a vector doesn't have the special symbol in the
>> first entry, we could call the previously remembered default printer
>> instead of iterating manually over the vector.  Recursive calls to print
>> would again use the custom print function.
>
> I don't know what you're talking about.  I'd probably understand better
> with a piece of code.

(defvar my-printer-table 
  (let* ((table (make-pprint-dispatch-table))
         (default (get-pprint-dispatch table 'vector)))
    (set-pprint-dispatch table 'vector 
                         (lambda (obj stream)
                           (if (eq (aref obj 0) 'my-type)
                               (princ "#<my-type>" stream)
                               (funcall default obj stream))))
    table))

(defun my-prin1 (obj stream)
  (let ((pprint-dispatch-table my-printer-table))
    (prin1 obj stream)))

The interface functions would be make-pprint-dispatch-table,
get-pprint-dispatch, and set-pprint-dispatch. pprint-dispatch-table
contains the current table in use.

>> And if someone produces so much output the that it takes to long to
>> print, he probably doesn't want to read it anyway :-)
>
> But it's difficult for Emacs to find ou before it's too late.

The user can press C-g if it takes to long.  Oh wait, print isn't
interruptible.  To bad.
 
Helmut.