Second Draft forthcoming, probably monday.

[bear <bear@xxxxxxxxx>]

Hi. I'm getting ready to prepare a second draft of the SRFI,
based on the discussion we've had here.  I am planning to make
the following changes:


(1) Optional second argument is used as an output-port.

(2) state explicitly that if given a third argument,
    (write-showing-shared) must still produce finite output in
    finite time when writing finite data structures and must
    still produce an external representation that can be read
    by (read-showing-shared).  This allows some parameterization,
    but does not allow the basic functionality to be revoked.

(3) state explicitly that intertoken whitespace is not significant
   in the notation produced -- allowing implementations to
   prettyprint or otherwise format output somehow if they so
   desire, possibly based on the value of a third argument.

(4) Use the new reference implementation which Al Petrofsky has
   kindly given us in this thread -- with an extension for an
   optional second argument and an optional third argument. In
   the reference implementation the third argument will be ignored
   completely if present.

(5) State explicitly that (eq?) relationships among characters and
   numbers (and if an external representation is provided for procedures,
   for them as well), are not required to be preserved, but that a
   hypothetical implementation which preserves such relationships
   is compliant with the SRFI.

(6) Require a procedure named (read-showing-shared) which reads
    the notation that (write-showing-shared) creates.

(7) provide a reference implementation of (read-showing-shared).

(8) Add some discussion about efficiency vs. portability and point
   out to implementors that a MUCH more efficient version of this
   functionality is possible.

(9) Suggest or require shortcuts named (write/ss) and (read/ss)
    for those who don't care for long names.

This will not be the last draft of this document; it's just stuff
that looks like a good idea now that I've seen some discussion on
it.

Stuff I'm not really sure of yet includes:

(A) I'm not really sure about point (9) above.  It's there
    mainly because I think that folks who object to long names
    will probably do something similar to this anyway, and for
    portability's sake I want to reserve specific names for the
    shortcuts.

(B) (write-showing-shared) is an obvious and reasonable name for
    an output function, but (read-showing-shared) is not a logical
    name for an input function.  The names of the functions should
    be very clearly related, as in (write-XXX) and (read-XXX) but
    'showing-shared' may not be the best choice of XXX now that I
    look at the name of the read function it generates.  Of course
    changing it would most likely change the shortcut names too.

(C) It may be possible to provide a more efficient reference
    implmentation of (write-showing-shared) by using an atree
    instead of an alist. Since ordering of container types
    such as pairs and vectors involves considerable effort
    and possibly recursion, this may not in fact be a win.

				Bear