[racket-dev] for/match construct?

I don't like either. I'd rather shadowing, as it is more consistent with how I would conceive of a * binding pattern.
-Ian
----- Original Message -----
From: Sam Tobin-Hochstadt <samth at ccs.neu.edu>
To: J. Ian Johnson <ianj at ccs.neu.edu>
Cc: dev <dev at racket-lang.org>
Sent: Tue, 25 Oct 2011 20:23:28 -0400 (EDT)
Subject: Re: [racket-dev] for/match construct?

Matthew and I talked about this today, and we decided that we should
create a parallel set of matchized versions of the `for' macros,
rather than my previous experiment which added an `in-match' form that
changed the semantics of `for' clause bindings.  I've started
implementing this; fortunately it doesn't require exposing
`define-for-variants'.

The one semantic question is about match failure, should that be
treated as dropping the element from the sequence, or as a dynamic
error.  For the parallel, ie non-* variants, I don't think it makes
sense.  For the nested versions, it would make sense, but I'm unsure
about whether it's a good idea.

Any thoughts, particularly in the form of use cases, are welcome.

On Tue, Oct 25, 2011 at 6:42 AM, J. Ian Johnson <ianj at ccs.neu.edu> wrote:
> I'm considering putting in some effort to generalize the binding construct in for-clauses so that we can have for[*]/match/X macros. This will require modifying and exposing define-for-variants (due to circularity in requiring match in for). Does anyone object? I'll of course need the code reviewed by those more familiar with for, but I'm hoping I don't need to mess with complicated implementation details such as taints.

-- 
sam th
samth at ccs.neu.edu