Support restrictions for matches in more structured way about comby HOT 3 CLOSED

Indeed, there are lots of potential improvements around the syntax here. Did you perhaps have a chance to look at the rationale for comby sytnax?

after the match identifier.

In general I think this is a good idea. One thing I've observed after experimenting with syntax here is that adding lots of things right after the identifier (like POSIX character classes) tends to reduce readability. But perhaps that is unavoidable for "advanced filters", and an acceptable tradeoff.

• Character class

Yes, as you can see in the document I link above, the idea was to support something close to character classes. It gets problematic to support the full spectrum of character classes without break the well-formedness of balanced delimiters.

• Regular expression

Similar to above, and I give some examples about why supporting regular expression matching with holes is problematic in the document. A solution isn't yet clear to me how to handle handle those complexities.

• Predefined constraint

I think that's a neat idea! And it does not raise the same issues as the above two. It'd be nice to think more about how this could work.

from comby.

Comby now supports regular expressions which takes care of a lot of lexical matching/customization, and this solution seems to work for those cases.

from comby.

Thanks for your software extensions.

How will the corresponding documentation evolve further?

from comby.