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.
On Tue, 17 Dec 2002, Marc Feeley wrote: >So you wouldn't mind having to implement (and use) these procedures: > > write > write-shared > pretty-print > pretty-print-shared > write-with-radix > write-shared-with-radix > pretty-print-with-radix > pretty-print-shared-with-radix > write-show-hidden > write-shared-show-hidden > pretty-print-show-hidden > pretty-print-shared-show-hidden > write-with-radix-show-hidden > write-shared-with-radix-show-hidden > pretty-print-with-radix-show-hidden > pretty-print-shared-with-radix-show-hidden > >And what happens when you add one more feature? Imagine the number >of SRFIs to write (and in your case review), the typos, the code >bloat, etc. Wait a minute. PrettyPrinting and radixes and hidden stuff are about formatting output. There's already a perfectly good formatted-write SRFI, and maybe ought to be another. But this IS NOT ABOUT formatting. This is output specifically to be read by a machine, and machines don't care about formatting. The reason this SRFI is needed isn't because some human wants a pretty notation to read with his or her eyeballs. The reason this SRFI is needed is because the (write) function as specified in R5RS doesn't record enough information to recover the actual structure of the data being written, and isn't guaranteed to be well-behaved. It's because writing some kinds of data can crash your scheme system or lock it into an infinite loop, and even if it works, it can get you a string that you can't get the data in its original structure back from. Look at this, please, from the perspective of having a well-behaved function that can write an external representation of data so that it can be read back in recovering the same structure, and you will see that it's a completely different issue from presenting the data in a particular style, format, or radix. Such details are irrelevant here. SRFI-38 is a compatibility issue, so that reading can get back data with the same structure as the data that was written. It is not a presentation issue for formatted output. Bear (wondering whether it should be named 'ugly-print' just so we're clear about what it's *NOT* supposed to care about).