[plt-dev] problems with extending `for' syntax

At Sun, 22 Feb 2009 17:44:42 -0500, Sam TH wrote:
> I'd like to write a sequence syntax that uses `match'-style pattern
> matching.  Unfortunately, this doesn't seem to be currently possible,
> but it's close.
> 
> First, something like this is ruled straight out:
> 
> (for/list ([(? (lambda (x) #t) x) (:match (list 1 2 3))]) x)
> 
> since (lambda (x) #t) is not an identifier.  This is ruled out
> *before* the `:match' expander is given control.
> 
> Second, it's not possible to distinguish between the client writing this:
> 
> (for/list ([x (:match e)]) ...)
> 
> and this:
> 
> (for/list ([(x) (:match e)]) ...)
> 
> which, while they have the same semantics for `in-list', would have
> very different semantics for `:match'.
> 
> I think the easiest solution would be to (1) accept any pattern in the
> binding position, and have individual sequence-syntax forms rule them
> out (perhaps `define-sequence-syntax' could make this easy), and (2)
> provide a lower-level form which is given the raw pattern, without any
> transformation.
> 
> I'll write up a patch, provided anyone is interested.

It sounds worth trying, but I'm not sure it will work easily.

The existing `for' forms were designed with the idea that the
right-hand side of a binding is always an expression. If the expression
has a certain shape, then you might get better performance, but the
shape of the expression doesn't affect the binding.

A benefit of that design is that you can derive new `for'-like forms
that wrap some right-hand sides with sequence converters. For example,
a derived form might wrap a right-hand side with `stop-before'. If I
remember correctly, then some of the `for' forms (perhaps `for/or' or
`for/and') are implemented that way.

In other words, the constraint that the right-hand side is always an
expression might be built deep enough into the design that it's
difficult to change. But I'm not sure.