This page is part of the web mail archives of SRFI 38 from before July 7th, 2015. The new archives for SRFI 38 contain all messages, not just those from before July 7th, 2015.
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