[racket-dev] for/match construct?
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. Example: Here the significantly new behavior is that name should match in the for/match clauses in order to run the body. (for* ([mch (redex-match L some-pat some-term)] [bnds (match-bindings mch)] [use-names (in-value use-names)]) (for/match ([(bind name exp) bnds] [name use-names]) ...code...)) What this looks like without for/match is (for* ([mch (redex-match L some-pat some-term)] [bnds (match-bindings mch)] [use-names (in-value use-names)]) (for ([bnd bnds] [name use-names] #:when (match* (bnd name) [((bind nm _) nm) #t] [(_ _) #f])) (match-define-values ((name exp) name) (values bnd name)) ...code...)) Notice the unnecessary second match. -Ian _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
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 i...@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 sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [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 sa...@ccs.neu.edu To: J. Ian Johnson i...@ccs.neu.edu Cc: dev dev@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 i...@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 sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
