[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Second Draft forthcoming, probably monday.
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
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
(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.