Re: new function or modify read

[David Rush <kumo@xxxxxxxxxxxxx>]

Marc Feeley <feeley@xxxxxxxxxxxxxxxx> writes:
> So in the end the "write-showing-shared" procedure still needs
> parameters.  

Depends. I am quite happy with it as it sits and am using the
reference implementation to dump suffix-trees of 200+ KB documents.
The suffix trees are actually circular gecause of Scheme's top-level
union type and I'm using a home-brewed shared-string library based on
SRFI-13, but write-showing-shared makes the data structure readable,
which is more than anybody's implementation of write does. It's
especially nice to think that I could use the same format to read the
suffix-trees back in later. I'm pretty tired of maintaining custom I/O
procedures that are only marginally faster than generating the data
structure in the first place.

> We don't yet know how many we need (and probably never
> will as the need for new features never ceases to grow).  This is why
> an API based on dynamically bound parameter objects is needed.
> Alternatively, explicit keyword parameters could also be used:
> 
>    (write obj port shared: #t pretty: #t)

I could live with that, but I have mixed feelings about keyword
parameters. 'Nuff said.

> I have also found readtables to be a good way to package up the
> parameters that are used by "write" and "read".  The readtable
> specifies the external representation and "write" and "read" use
> the readtable when generating the external representation or
> when parsing an object.  

> With readtables you would have:
> or
> 
>    (let ((rt (readtable-copy (current-readtable))))
>      (readtable-allow-sharing-set! rt #t)
>      (readtable-pretty-print-set! rt #t)
>      (write obj port readtable: rt))

I think I like this idea even better. Although I'd ditch the keyword
and just make it a second optional parameter.

david rush
-- 
Scheme: Because pure lambda calculus gets tedious after a while.
	-- Anton van Straaten (the Scheme Marketing Dept from c.l.s)