Translit rule syntax possibilities

RFE assigned to alan target: unscheduled

• 11/02/01 20:29:00 schererm changed notes
• 11/02/01 20:29:02 schererm moved from incoming to feature
• 12/10/01 17:35:58 alan moved from feature to transliterate
• 04/12/02 17:47:13 alan sent reply 1
• 04/12/02 17:48:00 alan changed notes
• 07/31/02 19:09:37 schererm changed notes
• 10/29/02 15:57:58 hshih changed notes2
• 10/29/02 15:57:58 hshih changed notes
• 05/30/03 10:13:11 hshih changed notes2
• 05/30/03 10:13:11 hshih changed notes
• 07/12/04 18:46:32 andy changed notes2
• 07/12/04 18:46:32 andy changed notes
• 07/12/04 18:56:33 andy changed notes2
• 07/12/04 18:56:33 andy changed notes

A good way to write the syntax might be:

alpha : a > b; c > d; e > f : beta; g > h;

beta: q > r; s > t;

That is, it will get tedious to have to repeat the left state tag. So once a left state tag has been seen, it should repeat until a different left state tag is seen.

Furthermore, the default right state tag shold probably be the current left state tag. That way the "c > d;" rule above works in state "alpha" and stays in state "alpha".

I also propose that the state tags be alphanumeric identifiers, not numerals, like C or Java labels. And the default state tag can be "main", following C++ and Perl conventions.

ISSUE: Should the transliterator become stateful between calls to incremental transliterate()? That is, if I get a partial match, and I'm in state "foo", should the transliterator remember this, and then be in state "foo" when the next bit of text comes in? I think it must for this to work correctly.

Implementation probably consists of 2 new data members on each rule, a left tag and a right tag. These can be integers created by the parser. If we want pretty output we can keep the strings<->integer mapping in the core data object.

Then the RBT object needs a new data member encoding the current state, for

incremental operation.