zyxw59 / rssc Goto Github PK

The current syntax (&(a_b |(c_ _d)) is unintuitive and a bit hard to read. It would be nice to have an infix syntax. The main challenge is grouping — ( is already a valid character to start a regex, so there's some parsing ambiguity if it's also used to group environments.

Currently, the tokenization and parsing functions return errors saying what went wrong if something fails to tokenize or parse properly, but don't say where it went wrong (e.g. line or character numbers).

README should describe the current state of development, and once there is a usable binary, describe its usage similarly to the README for the Go version of this project

Currently, the plan is to use LALRPOP to generate a parser for the rule file grammar. However, I don't know how easy it is to use LALRPOP with the custom tokenizer in the token module. Additionally, LALRPOP itself takes a long time to compile and has a lot of requirements, so it would be nice to cut it out.

I think using regex (even the current custom implementation) is not actually a great fit for matching sound change rules. A bespoke engine that tracks exactly the state required to confirm or reject a match would be easier to work with and optimize.

The engine should work similarly to the regex engine, stepping thru the input string one token at a time while maintaining the state of the match. It should also handle collapsing identical states to reduce blowup.

The state should include:

• Current location in the search (like the regex instruction pointer)
• Current value of any indexed category matches ({0:C} and the like)
• Start and end points of the part of the match to be replaced.

For a rule with a single positive environment, it should be included in the search. Negative environments probably need to be handled afterward, since a token-by-token approach isn't great at looking for what shouldn't be there. If there are multiple positive environments joined by an 'and', they might also have to be handled afterward, unless we can find a way for the engine to fail a search based on the results of another search.

The replacement function should take a Vec<rule::re::Engine>, a CategoryMap, and a TokenString, and produce a new TokenString by applying all applicable Engines.

Will need to prune the Engines by only selecting the first applicable Engine for each position in the input, including dealing with overlapping matches.

Syllable boundaries would be represented by some character that could be inserted by rules into words, and also match at word boundaries. I don't think attempting to dynamically syllabify input words is feasible.

There needs to be some syntax to declare user-defined tokens (e.g. a user might want to treat sh as a single token if it represents a single phoneme in their language).

I'm not sure how I want to do this. Token declarations have to be parsed before the rule file is tokenized. The options I've thought of are:

• A section at the top of the rule file. This would need some delimiter to separate it from the rest of the document, perhaps a blank line?
• Inclusion of an external file (e.g. tokens path/to/file)

These two options are not mutually exclusive though, and it would be nice to allow both forms.

Currently, src/rssc.lalrpop just defines the syntax for regular expressions, but not syntax for:

• Rules
• Category definitions
• Token declarations
• Any other constructs that might be added