Email list hosting service & mailing list manager

Rest and patterns David Van Horn (18 May 2005 20:47 UTC)
Re: Rest and patterns Neil W. Van Dyke (18 May 2005 22:00 UTC)
How about dropping semi-variable-arity? Petrofsky, The Reverend Al (19 May 2005 02:01 UTC)
Re: Rest and patterns David Van Horn (19 May 2005 16:40 UTC)
Re: Rest and patterns Neil W. Van Dyke (19 May 2005 18:22 UTC)

Re: Rest and patterns David Van Horn 19 May 2005 16:24 UTC

Neil W. Van Dyke wrote:
> 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.

But there's no precedent for the `rest' syntax in lambda.  And Al Petrofsky
pointed out an issue with using the lambda semi-variable-arity feature.

> My concerns with that would be: ...

I agree with your concerns about making this a general pattern matching SRFI;
such a SRFI would be quite an undertaking, and it doesn't help matters that
there is no way to define a datatype in R5RS.  (Luckily there is SRFI 57).

André van Tonder has been working on a pattern matching proposal for some
time, and I've tried to contribute to it.  In that proposal the language of
patterns is extensible.  The way `match' works is it examines the head of the
pattern.  If it is a keyword associated with a pattern rewrite rule (match
implicitly carries around an environment binding keywords to syntax
transformations), then the match expression is transformed accordingly,
otherwise it's interpreted as a regular variable.  Using the `values' keyword
in `let' would work seamlessly with this approach to pattern matching.

>>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?

I think my point was having a keyword at the head of the form is helpful, but
in particular whenever there are keywords within the form whose meaning
depends on the context.  Adding a `rest' keyword to `let' seems like a hack,
but adding a `rest' keyword to a `values' pattern seems appropriate.

But really all I wanted to do was point out that we're now talking about
pattern matching, even if only for multiple values.

David