[antlr-interest] v4 "Honey Badger" teaser

Graham Wideman gwlist at grahamwideman.com
Thu Dec 29 18:27:10 PST 2011


A way to deal with case-insensitivity that is less noisy to read would be a great benefit, but I too was thinking along the lines of Sam:

At 12/29/2011 06:07 PM, Sam Barnett-Cormack wrote:
>Assuming unicode featureset, a proper semantic case insensitivity would 
>be lovely - so the unicode properties were used to determine whether 
>there was a case-insensitive match. Someone might have a use for other 
>unicode matching, though, like base-glyph matching (ignoring diacritics).

... which led me to think that a more flexible way to say "apply case insensitivity to this string" is needed, that could invoke either:

a) one or another built-in transformation, such as standard ASCII case insensitivity:  CI("AB") --> [Aa][Bb], and possibly other built-in standards for a range of unicode character sets.

b) or invokes a user-supplied plug-in: CI("AB", MyTrans) --> whatever MyTrans returns.

c) or, with syntax similar to (b), and to avoid code-language-dependency, invokes something specified elsewhere in the grammar file using regex or whatever.

I'm not particularly advocating the above syntax, just the general idea of facilitating shorthands for generating the fully-spelled-out series of character sets, and also advocating trying to avoid special-casing one particular variety of case-insensitivity within ANTLR syntax. 

Hmmm, this is sliding perilously close to ANTLR preprocessor.  :-)

-- Graham



More information about the antlr-interest mailing list