Email list hosting service & mailing list manager

Re: new function or modify read bear 17 Dec 2002 20:23 UTC

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.


(wondering whether it should be named 'ugly-print' just so we're
 clear about what it's *NOT* supposed to care about).