[Openmcl-devel] format string compression

[Gary Byers]

Since you generally don't know what values the printer control
variables (and other things that affect printing) will have at some
arbitrary point in time, you may need to ensure that any printing
that you do is done in a predictable dynamic environment.

If only CL offered a way of printing things with standard I/O
syntax (well-defined, default values of global variables that
affect printing) in effect ... oh wait: it does.

WITH-STANDARD-IO-SYNTAX might be overkill (it binds *PACKAGE* and
the readtable, among other things), but in general it's much wiser
to do something like:

(let* ((*print-circle* nil))
  ;; Don't know why *PRINT-CIRCLE* is enabled in the environment
  ;; where this runs, but want it off here:
  (print-some-stuff))

than it would be to do:

(progn
   ;; Don't know why *PRINT-CIRCLE* is enabled in the environment
   ;; where this runs, and might as well break any code that
   ;; might depend on that.  I can always claim ignorance as a
   ;; defense.
   (setq *print-circle* nil)
   (print-some-stuff))

As to why *PRINT-CIRCLE* gets bound to T when errors are being
handled, consider:

(defvar *circular-list* (let* ((a (cons nil nil)))
                           (setf (cdr a) a)))

? (+ pi *circular-list*)

> Error: value #1=(NIL . #1#) is not of the expected type NUMBER.

is almost certainly preferable to getting a stack overflow while
trying to print the message (and then having to crawl through
thousands of stack frames to see what the real problem was.)

There might be other ways of avoiding stack overflow (perhaps by
binding *PRINT-LENGTH* and *PRINT-LEVEL* appropriately), and there
are certainly tradeoffs involved.  It doesn't seem unreasonable
for the implementation to want to do -something- to guard against
secondary stack-overflow errors, and whatever it does might mean
that printer defaults are different in the context in which an
error is being handled than in other contexts.

Regarding watchpoints: I've sort of assumed that being able to
exploit hardware watchpoints required OS-level support (likely
related to ptrace) and was really only practical in a debugger.
I'd love to be wrong about that.







On Thu, 26 Feb 2009, Derrell Piper wrote:

> Brian,
>
> That was it.  Any idea what turned *print-circle* on?  Any way to set
> a watchpoint on it?
>
> If it's relevant, this particular code's running in a restart-bind
> handler.
>
> Derrell
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>