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 <[email protected]> To: J. Ian Johnson <[email protected]> Cc: dev <[email protected]> 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 <[email protected]> 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 [email protected] _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
