It makes me worried, because the implementation now becamevery abstract, and it no longer conveys the intent: it doesn't tellthe reader how the "is" macro is meant to be used, which I thinkis a big price to pay -- especially given that the behavior that it enablesis questionable and discouraged and unlikely to be used in practice:As syntax-rules macros usually have to be written in convoluted ways, I don't think one should every take them as a definition of a new concept.I expect specialization of a single argument of a binary predicate
to be the most common use case, which in my view justifiesthe irregular behavior.(is _ < x < _) looks like a sensible application. It is a procedure of two arguments, say a and b, and returns #t if the interval [a, b] encloses x.
It also prompts to consider another interpretation, where "is" would alwaysbe returning a lambda, and so instead of (is x < y), one would need towrite ((is x < y)). I don't think there's any utility in such consistence,but I'm mentioning it for consideration.For consistency, I think it is very imported that the "is" macro does behave regularly. Either it should always return a procedure or never.
If you don't want to write ((is x < y)), I suggest to use two different syntaxes. (E.g., as previously suggested, (cute is ...) for the procedure case.