On Thu, 25 Mar 2004, soo wrote:

> | Seriously, the word "formatting" conveys no information to me.
>
>The word reminds me of a procedure FORMAT.

Are you referring to Common Lisp FORMAT, or some other FORMAT?

>
> |What are you
> | formatting?
>
>Any object.
>
> |How?
>
>Through FMT procedure.
>
> |Why?
>
> The same as FORMAT.

You may understand how useless these so-called answers are to
someone who cannot see the FORMAT procedure in your head?  If
not, please consider it.

> |-- Answers to these questions should appear somewhere
> | in the SRFI document.
>
>Even though you are in the right, that's none of your business.

Soo, you are dead wrong here.

The review period exists because it's his business.  And mine.
And yours.  and the business of the entire community of people
who use Scheme. If you want to live in a world where it's nobody's
business but yours, then you must understand that in that world
this is a library you have developed for your own use, not a
SRFI.  Indeed, if your opinion is that it's not his business, then
please be consistent in your opinion and withdraw the SRFI.

> | I would rather see a keyword syntax, or pass in a record to fmt, or fix the
> | order of arguments.
>
>
>I have no ideas to express the function of FMT in those ways.
>Please, Let me show an example.

I think that he is right about fixing the order of arguments.
Fixing the order of arguments permits other people to extend
the function consistently without breaking the functionality
you're specifying now.  Your reference implementation needs to
handle the arguments in the order specified.  If it handles
arguments in other orders as well that's not a violation nor
something you must insist that every other implementation must
do as well.

> |The current approach 1) has no precedent as far as I'm
> | aware
>
>Have you never tried anything new?

In standardization efforts, we specifically try to avoid things
that are new.  When something is held up as a possible standard,
it should be something that has been used, if possible, for
several projects already and which is known to be useful and
complete.

If this is "new", as you say, then I would suggest developing some
projects with it and getting some experience with it before
submitting a SRFI.

> |2) is not extensible
>
>What is not extensible?

A procedure that takes its arguments in an unspecified order
and allows any argument to be omitted cannot be given additional
functionality to be triggered by a different argument signature.

Also, your function FMT makes no provision for output procedures
other than WRITE and DISPLAY, and therefore is not extensible
to data of types WRITE and DISPLAY don't know about.  E.G, if I
have a geometry package and I have defined a SRFI-9 datatype
named "point", which I want to display using square brackets, as
[coord1 coord2 coord3] -- I will do that by writing a display
routine GEOMETRIC-DISPLAY that understands points (and probably
several other geometric objects), and I will want to pass it into
FMT as an output procedure.

In fact, I may have a 3-d scene for a rendering engine defined
as a list of geometric objects and want to pass it to FMT with
a compiler that produces an instruction string for the renderer
as the output procedure.

Even among other SRFI's, you will find display routines such as
WRITE/SS, which provides a way of designating which structures
in scheme data are shared.  In fact, it is possible that in some
schemes WRITE/SS must be used instead of WRITE in order to avoid
endless loops.

> | I'm finding it very difficult to provide constructive feedback because I can't
> | discern from the document what your intentions are at all.  What problem does
> | this SRFI address?
>
>A Note in Preface is helpful.

A note in the preface might be helpful, if your SRFI had a preface.
But since you need to add one, why not just title it 'rationale'
and follow the established convention for such a helpful note?

				Bear