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

When a tool (such as a procedure for writing data) has obvious
extensions, then the design has to allow such extensions.  I'm not
saying that all extensions have to be specified right now.  I'm saying
the specification must provide a path for extension that is elegant
(i.e. not a future patch).  Claiming that "write-showing-shared" is
extensible because we can always add an explicit parameter for
variation A, another for variation B, and so on for other variations
is not a good argument because there are too many variations in this
case ("if your procedure has 10 arguments then you've forgotten one").

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.

Dynamically scoped parameter objects are interesting here because they
do not require a change to the explicit parameters of "write".  SRFI
38 could simply say "an implementation conforming to this SRFI
provides the parameter write-shared which affects the behavior of the
write procedure in the following way ...".  Another SRFI for
pretty-printing could also simply say "an implementation conforming to
this SRFI provides the parameter write-prettily which affects the
behavior of the write procedure in the following way ...".  Users can
then combine features.  If there are N features, only N SRFIs have to
be written, not 2^N - 1.

Marc