This page is part of the web mail archives of SRFI 71 from before July 7th, 2015. The new archives for SRFI 71 contain all messages, not just those from before July 7th, 2015.
David Van Horn <dvanhorn@xxxxxxxxxx> 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/