[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new function or modify read

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).