David Van Horn <xxxxxx@cs.uvm.edu> wrote at 2005-05-18T16:30:50-0400:
> The recent discussion over binding the "rest" of the values seems to
> me to be a proposal for a (very small) pattern language, and an
> extension of `let' to allow for patterns in the LHS of each clause.

First, good observation.

Although, as devil's advocate, I'd point out that the "lambda" syntax
has N-terms-plus-rest as one pattern language.  So, if "let" uses
N-terms-plus-rest and nothing else, there is at least precedent.

> So, perhaps this SRFI would be better suited by developing a thorough
> pattern language, which `let' could be extended to use.  The "values"
> part of this proposal would simply fall out of such an approach.

My concerns with that would be:

1. I think the R6RS people might be considering a pattern language, so I
   wouldn't want to try to add a pattern-language to "let" SRFI until I
   knew more about R6RS plans.

2. I think that a "thorough" pattern language might threaten the
   adoption of the SRFI in several ways:

     a. This is a big design and (reference) implementation task, which
        might delay SRFI finalization long enough for people to loose
        interest, which might be an abandoned SRFI or one that isn't
        well vetted.

     b. This would result in a much harder implementation task for
        Scheme implementors, which would discourage adoption.

     c. This might be more controversial, which would discourage
        adoption.

   SRFI-71 is already undertaking some important enhancements, and
   adoption is everything.  If SRFI-71 isn't widely adopted, it's all
   but moot.

> Or, on the other hand, perhaps this SRFI should remain within it's
> current scope, but in that case I would suggest leaving the extension
> of `let' in such a way that it is still possible to extend `let' to
> use patterns in the future.  For this reason, I suggest keeping the
> `values' keyword that Neil W. Van Dyke recently argued against.

I don't immediately see how this "values" syntax would be a natural part
of the future TBD pattern language, nor how the "(rest VAR)" syntax
precludes a future TBD pattern language.  If you are asserting one of
those, could you say a bit more about that?

--
                                             http://www.neilvandyke.org/