Details

Description

On the Clojure mailing list I wrote:

For guards, I wonder if the extra parens are really necessary. Couldn't the :when bind tightly to the previous pattern variable? Like Clojure FOR comprehensions. I think it would be easier to read that way. Same comment applies to :as. To cover the rare case of matching a literal :when or :as, you could quote it or use it as the first item in an OR pattern.

Activity

I attached a patch that groups the :when and :as terms appropriately given a "flattened" syntax. That is, [a :when even?] becomes [(a :when even?)] before being processed as usual. I only applied it to the top-level of the pattern row because I was concerned about recursive performance and things can get pretty complicated so maybe the magic isn't worth it.

Only :when and :as at the top level get any special treatment. No mangling for :seq or ::vector, etc. No mangling of nested patterns.

Steve Miner
added a comment - 12/Oct/11 10:35 AM I attached a patch that groups the :when and :as terms appropriately given a "flattened" syntax. That is, [a :when even?] becomes [(a :when even?)] before being processed as usual. I only applied it to the top-level of the pattern row because I was concerned about recursive performance and things can get pretty complicated so maybe the magic isn't worth it.
Only :when and :as at the top level get any special treatment. No mangling for :seq or ::vector, etc. No mangling of nested patterns.
I also added a couple of tests for my changes.

The patch tries to group the :when or :as if that makes sense. If it doesn't make sense [:when true nil], it leaves it alone so that would match the literal. In the rare case where it would be ambiguous, you would have to use a single OR pattern to get a literal match, such as [a (:when |) false]. I put something like that in one of my new tests.

Steve Miner
added a comment - 15/Oct/11 3:13 PM The patch tries to group the :when or :as if that makes sense. If it doesn't make sense [:when true nil], it leaves it alone so that would match the literal. In the rare case where it would be ambiguous, you would have to use a single OR pattern to get a literal match, such as [a (:when |) false]. I put something like that in one of my new tests.

By the way, it might be nice to allow a single element list to match that single pattern. That is, treat [(p)] the same as [p]. Right now, it's considered an error. It would also simply my patch, where I had to introduce interpose1 (as a variant of interpose) to handle an edge case with the OR pattern.

Steve Miner
added a comment - 15/Oct/11 3:18 PM By the way, it might be nice to allow a single element list to match that single pattern. That is, treat [(p)] the same as [p]. Right now, it's considered an error. It would also simply my patch, where I had to introduce interpose1 (as a variant of interpose) to handle an edge case with the OR pattern.