[fset-devel] Rereading reader bug for collections with non-NIL defaults.

[Samium Gromoff]

On Thu, 30 Jun 2011 15:04:24 -0700, "Scott L. Burson" <Scott at 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)