<div dir="ltr"><div>Since we're making some adjustments to the tokens, perhaps we can do some other things at the same time.</div><div><br></div><div>When adding a new pattern to Noise-C/Java, I have been hand-converting the pattern into a sequence of tokens and a set of pattern requirement flags.  This is error-prone of course.</div><div><br></div><div>To reduce errors, the unit tests cut-and-paste the raw pattern definition from the specification.  Using a custom parser, I cross-check the definition against the converted token sequence.  However, this is still very manual:</div><div><br></div><div>- The two-column format in the specification makes it hard to cut-and-paste the details out for a specific pattern.</div><div>- I have to manually split the definition into header, pre-message, and body because the syntax is context-dependent.</div><div><br></div><div>It is also becoming clear to me that hard-wiring the pattern definitions into the library isn't flexible enough.  When it was only 15 to 20 patterns it was OK, but now with pattern transformations the list is potentially endless.  User-defined patterns are going to be a must, but I don't want to push the error-prone hand-conversion process onto the user.  The specification says that "message_patterns" is a sequence of token sequences but it still requires the user to do the conversion.  It would be easier if the user could provide the pattern string from the specification directly, with the library parsing and verifying it.</div><div><br></div><div>As an example of the context-dependency, consider KN:</div><div><br></div><div>    Noise_KN(s):</div><div>       -> s</div><div>       ...</div><div>       -> e</div><div>       <- e, ee, se</div><div><br></div><div>This cannot be parsed with a straight-forward LL(1) parser because it is unclear whether the first "->" is introducing a pre-message or a message body until the "..." token is encountered later.  Might I suggest instead:</div><div><br></div><div><div>    Noise_KN(s):</div><div>       => s</div><div>       ...</div><div>       -> e</div><div>       <- e, ee, se</div><div><br></div><div>That is, use a different arrow marker for pre-messages.  Now the syntax is context-free.  Any off the shelf parser-generating tool can be used to create the parser.  I'm happy to provide the grammar.</div><div><br></div><div>As well as cleaning up the syntax, I'd like the patterns to be provided in a machine-readable "patterns.txt" file in parallel with the specification.  This will make it easier to bulk-convert patterns and to write analysis tools to validate patterns and apply transformations.  Sections 8.4 and 8.5 in the specification list various properties - a tool would be better suited to generating that list, especially for new patterns.</div><div><br></div><div>Thoughts?</div><div><br></div><div>Cheers,</div><div><br></div><div>Rhys.</div><div><br></div></div></div>