[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rest and patterns




David Van Horn wrote:
> 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.
>
> 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.


The thought crossed my mind. In the end I decided that the problem I really
want to solve with this SRFI is making multiple values as convenient as they
can get in Scheme. Unfortunately, a general pattern language contributes
only very little towards this goal, so I dropped it quickly.

When chosing the syntax to propose, however, I did watch out not to close the
door on other possible extensions too early. In particular, Eli Barzilay's LET
from Swindle extends for local lambda-expressions. This is still fully compatible
with the current SRFI-71, with the restriction that procedure must not be called
VALUES.

Sebastian.








srfi-71-request@xxxxxxxxxxxxxxxxx

18-05-2005 22:47

       
        To:        srfi-71@xxxxxxxxxxxxxxxxx
        cc:        (bcc: Sebastian Egner/EHV/RESEARCH/PHILIPS)
        Subject:        Rest and patterns

        Classification:        




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.

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.

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.

David