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
