Marc Feeley <xxxxxx@IRO.UMontreal.CA> writes:
> > Marc Feeley <xxxxxx@IRO.UMontreal.CA> 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.
>
> SRFIs should not be designed with a single user in mind, otherwise you
> end up with a tool that is too special purpose.

Duh.

> When a tool (such as a procedure for writing data) has obvious
> extensions, then the design has to allow such extensions.

Actually I'm not sure that I agree that I/O procedures fall into ths
category. I/O procedures tend to be *very* narrowly focussed because
their intent is communication with a particular external entity.

> Naming is important.  I claim that procedures named
> "write-showing-shared" or "write-with-pretty-printing" can't be fully
> extensible, whatever their actual specification, because their name
> suggests that their parameters (explicit or not) cannot modify their
> main purpose (the use of an external representation that shows sharing
> or the use of a pretty-printing format).  For maximal extensibility
> the name has to be neutral, and this is why "write" is appropriate.
> It allows features that are orthogonal (sharing notation, pretty
> printing, case sensitivity, etc) to be specified independently with no
> bias towards a particular feature.

I also have a bit of difficulty with the notion that even the features
that you mentioned are orthogonal. Sharing notation and
case-sensitivity, in particular, strike me as having significant
overlap. It really just bring me back to my original point: it is in
the lambda-nature of I/O procedures to be specific, not generic. From
that POV, write-showing-shared is a useful addition to the toolbox.

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