[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new function or modify read
Marc Feeley <feeley@xxxxxxxxxxxxxxxx> writes:
> So in the end the "write-showing-shared" procedure still needs
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:
> (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.
Scheme: Because pure lambda calculus gets tedious after a while.
-- Anton van Straaten (the Scheme Marketing Dept from c.l.s)