Walter,

> Maybe somebody can explain me what is the use of this SRFI.

Finally somebody who raises the most important issue of
this SRFI. Thank you for that!

The mechanism proposed in the SRFI is an attempt to
make some (!) of the common cases cropping up in "daily
programming with Scheme" more likable.

The SRFI aims at specializing a subset of the parameters
of a Scheme procedure, only. As you have observed, it is
not possible to reorder, remove or duplicate arguments---
and this is indeed the intention. If you need to process a
procedure in a more profound way than offered by the SRFI
you are to use the full power of a lambda expression or,
in case it is frequent, define and use a differnt mechanism.

The idea of the SRFI grew out of the observation that Scheme
is very modest, in a certain sense too modest, with respect
to special cases of its primary mechanism (beta conversion).

In this sense, I do not see the SRFI in conflict with
other mechanisms that deal with special cases. There is
no 'exclusive or' to me.

For example, your macro f (implementing a suggar-free version
of ARC's []-notation) is the mechanism of choice to define
complicated single-argument procedures when the name of the
argument is irrelevant:

>    (define quadratic (f + (* _ _ 2) (* _ 3) 4))

Your macro fn on the other hand provides the full power of
lambda but with numbered (instead of named) variables.
This could be useful, for example, if there are very many
arguments and the task is merely to permute them:

        (fn list $2 $3 $4 $5 $6 $7 $8 $9 $1).

From a more abstract point of view, I see three main aspects:

* How does the mechanism refer to the residual parameters?
        currying: by leaving them out
        SRFI-26:  by indicating an omission (a 'slot')
        ARC's []: not at all (result is unary by definition)
      fn:       not at all (arity/signature unspecified)
      lambda:   by listing symbols for them

* How does the mechanism refer to the actual arguments?
        currying: not at all (you only wrote constants)
        SRFI-26:  by the position of the slot in the call
        ARC's []: by a fixed special symbol _
        fn:       by numbered symbols $1, $2, ..
      lambda:   by refering to the symbol

* What computation depending on parameters does it allow?
        currying: none
        SRFI-26:  none
        ARC's []: any
        fn:       any
      lambda:   any

So much about theory. Now for something completely different...

Why would anybody want to write code using SRFI-26?

Well, as I did not do statistics on all Scheme code in
the world, this matter will have to be settled by looking
at myself and a certain amount of speculation about a
few other people. In the end, I cannot prove anything.

The main use of the macro proposed in the SRFI is to
make explicit that the expression denotes a specialized
form of a procedure in a situation that would probably
be dealt with by currying in other languages. (My first
notation for it did not even allow specializing an
arbitrary subset but only the first few arguments---but
I relaxed that when I observed that the 'point of no return
with respect to confusion' is only when permutation, omission
or duplication comes into play.)

A secondary aspect is a succinct and (the bad word again)
"intuitive" notation. This usually comes as a package-deal
with a painful discussion about the choice of identifiers.
Please refer to the SRFI-26 archive (srfi.schemers.org/srfi-26)
for that. This is certainly the most controversal issue yet
and I do not want to interfere with the discussion going on
right now.

---

So to summarize, the SRFI is just *a* mechanism and
useful in cases where curried languages would allow
dropping arguments. As this itself is not very useful
in a strict language like Scheme, I have tried to
find a notation with relatively little overhead and
the SRFI is essentially the result of that.

You seem to have considerable experience with related
tools. What do you use in practice?

Sebastian.