On Thu, 30 Jun 2011 15:04:24 -0700, "Scott L. Burson" <Scott@sympoiesis.com> wrote:
Thanks for the bug report! I think it's the first that's ever been sent to this list :-)
I think I know the feeling : -) FSET more than deserves more visibility and public attention..
So you're actually using the reader macros? I wasn't sure anyone would. (I haven't even been using them myself.)
Yes, the kind of simple, observable and robust serialisation/deserialisation provided by PRINT/READ fits nicely for my current task.
Do you need a fix quickly?
Not really -- I've opted for a low-intrusivity workaround and the fix surely isn't critical in any sense. What I'm struggling now with is "sharing abbreviation", as mentioned in CLHS[1]: CL-USER> (read-from-string (write-to-string (let ((c (cons nil nil))) (cons c c)))) (#1=(NIL) . #1#) I'm trying to convert PRINT-* functions in fset.lisp to use PPRINT-LOGICAL-BLOCK, but am hitting some unexpected problems. Note that PPRINT-LOGICAL-BLOCK deals with *PRINT-LENGTH* and *PRINT-DEPTH* (which FSET was dealing with on its own), but requires the "logical contents" to be arranged as a list of conses -- which I think is a small price to pay. -- 1. http://cs.hbg.psu.edu/LOCAL/HyperSpec/Body/mac_pprint-logical-block.html -- regards, Samium Gromoff -- "Actually I made up the term 'object-oriented', and I can tell you I did not have C++ in mind." - Alan Kay (OOPSLA 1997 Keynote)