soo wrote:
>  | 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.

Others have provided alternatives and examples.  My concern is not so much how
the procedure should be designed, but that the current design is poor.

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

I've never tried something new and then standardized it.

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

Arbitrary omission and arbitrary ordering of unlabeled arguments.  You're
relying on the uniqueness of each arguments type to discern which variable to
bind it to.  It's not extensible because you cannot add arguments of any type
you've already used.  To compensate, you have to use incredibly specific types
to maintain uniqueness among arguments, or you have to fall back on imposing
an ordering among arguments of the same type.  You can see this already in fmt
with types like "symbol in {u,d,t}" vs "symbol in {b,d,o,x}" and "procedure
eq? to {write, display}" vs "procedure eq? to +" and "the first natural
number" vs "the second natural number".

I haven't taken a look at your other SRFI on rest lists, but if this is what
that SRFI specifies, I think it's a very bad idea.

> |3) makes it very difficult to read the uses of this
> | procedure and predict what the result will be.
>
> I don't think so.  Please check SPEC and EXAMPLES of this SRFI document.

The above gives some insight as to why it is so difficult to read uses of fmt.

When I read the use of this procedure I have to look at the arguments and ask,
of what type is it?  I must remember all of those specific types you've
specified in *both* overloadings of fmt.  This is complicated by the
specificness of the types you've provided.  Once I identify the type I must
ask, how many arguments of this type are there, and how many arguments of this
type have already appeared.  Then I can see, oh, <case> = downcase, and move
on to the next argument.

My head hurts.

> I know Scheme procedures can have a variable number of arguments.  If the
> function of the arbitrary order can be added, it will be more convenient to
> use the procedure.

> If read-line is defined in conventional way, it is used like this;
> (read-line)
> (read-line <input-port>)
> (read-line <input-port> 'concat)
>
> But if read-line is defined in FMT's way, it can be used like this;
> (read-line)
> (read-line <input-port>)
> (read-line 'concat)
> (read-line 'concat <input-port>)
> (read-line <input-port> 'concat)
>
> Why not convenient?

I see no convenience beyond getting #f "for free" below:

   (read-line #f 'concat)

I see all of the inconvenience above.

>>>| Why does fmt have two very distinct behaviors?
>
> Because the required optional arguments are different according to the type.

>>>| Why not have two distinct
>>>| procedures?
>
> Why must have two procedure?  Inspite of the same processing course and return
> type(string).

This significantly adds to the difficulty of reading uses of this procedure,
especially given the omission and ordering permissiveness.

>>>| Why have a <show> parameter when you can just apply that function to fmt's
>>>| result?
>
> To write an object to a string port.

What does the <show> parameter have to do with string ports?  (Doesn't say
anything in the spec.)

My point was, why not just call write or display (or any function) on the
value returned by fmt?  Why pass it in.

>>>|And further, why are you allowed to pass in only display or write?
>
> FMT needs only display and write.

Others have given good reasons why not to restrict it to display and write only.

>>>| Why have <string> parameters when you have string-append?
>
> For convenience.
> I would like to use FMT like this:
>         (fmt 123 (fmt 1234 '(1 1) ...) "string" (fmt ...) ...)
> instead of
>         (string-append (fmt 123) (fmt 1234 '(1 1)) ... "string" (fmt ...) ...).
> Do this incommode you?

I don't think this is worth the "convenience", but this is a minor concern for
me at the moment.

David