[antlr-interest] Customizing token separators without recompiling

[Dukie Banderjee]

Hi everyone,

I'm new to the list and new to ANTLR. I have a specific problem I need to solve and I hope ANTLR can help.

Our client has several end-customers who all have slightly different document formats used for data interchange.

All the documents are basically 'standard' EDI documents, meaning they have the same basic syntax. However, some customers will use a '+' to separate values, some will use '*', others will use '~', etc. (I'm reminded of the old saying, "The great thing about standards is that there are so many to choose from!")

So, basically, the following inputs are all basically the same, except for the character used to separate tokens:
FST*4290*D*W*20070607
FST+4290+D+W+20070607
FST~4290~D~W~20070607

The thing is, we don't know ahead of time which separator characters might be used in the future, and we need to be able to tweak each end-customer's file format without re-compiling the lexer/parser. For example, a year from now there might be a customer who decides to use '_' or '$' or whatever, and we need to provide our client with a simple way (e.g. a per-customer configuration file) to customize the lexer/parser for such situations, without re-generating/re-compiling.

So, is this possible with ANTLR? How would I do this? Would it require a custom Lexer subclass with constructor parameters (e.g. new CustomLexer('_')) or something? How would this mesh with the generated lexer code from ANTLR?

I'm quite new to tools such as ANTLR (and parsers in general), so any help would be much appreciated. I really don't know where to start with this problem. For a hand-coded parser it's fairly simple, but I don't know enough about the workings of ANTLR to see where I would need to tweak it.

Thanks,

Rob

_________________________________________________________________
Create a cool, new character for your Windows Live™ Messenger. 
http://go.microsoft.com/?linkid=9656621
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20090607/2acef489/attachment.html