User-defined format control codes

[barmar@Think.COM (Barry Margolin)]

    Date: Fri, 28 Jun 1991 10:28 EDT
    From: curte@beowulf.Jpl.Nasa.Gov (Curt Eggemeyer)


    I think I found a situation in Steele's 2nd edition that I don't like.  It
    concerns the use of one's own formatting functions within the format control
    string (ie: (format t "~/my-function/" arg)).  If you create an elaborate
    system in its own package in which you wish to utilize your own format control
    codes, WHY do I need to always precede their invokation in the format control
    string with that package (EVEN THOUGH I AM IN THAT PACKAGE)!  This really sucks!
    Instead of having the format dispatcher always going to the user package when
    it sees your non-package prefix control code, it should go to the presently
    bound package. In package My-Package I still have to ...
    (format t "~/My-Package:my-function/" arg) when I should be able to
    (format t "~/my-function/" arg) ... I think the committee missed the boat on
    this one.  What's the point of defining your own functions if you have to either
    preface them with a package qualifier or have an echoing function in the user
    package.  This sucks!   Comments anyone!

The problem is that packages are normally processed when a file is read.
However, the format strings aren't interpreted until FORMAT is called,
and the current package may be different then.  Consider the following:

    (in-package :pkg-1)
    
    (defun my-function ...)
    
    (defun print-thing (thing)
      (format t "~/my-function/" thing))
    
    (in-package :pkg-2)
    
    (defun my-function ...)

    (print-thing 'foo)

Presumably the intent is that PRINT-THING should invoke
PKG-1::MY-FUNCTION.  However, when PRINT-THING is called, the current
package is PKG-2.  With your proposal, this would cause
PKG-2::MY-FUNCTION to be invoked.

Since format control strings aren't parsed at read time, it is necessary
to specify a global default package.

By the way, the SLUG mailing list is not really appropriate for general
Common Lisp language discussions.  SLUG has no official connection with
X3J13 (Symbolics and Thinking Machines are on the committee, though).
The above message, and yesterday's message about ROUND, should have been
sent to common-lisp@mcc.com instead of slug.

                                                barmar