[noise] Machine-readable pattern list

Rhys Weatherley rhys.weatherley at gmail.com
Tue Oct 4 14:31:59 PDT 2016


Since we're making some adjustments to the tokens, perhaps we can do some
other things at the same time.

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.

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:

- The two-column format in the specification makes it hard to cut-and-paste
the details out for a specific pattern.
- I have to manually split the definition into header, pre-message, and
body because the syntax is context-dependent.

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.

As an example of the context-dependency, consider KN:

    Noise_KN(s):
       -> s
       ...
       -> e
       <- e, ee, se

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:

    Noise_KN(s):
       => s
       ...
       -> e
       <- e, ee, se

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.

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.

Thoughts?

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20161005/f4d04cbb/attachment.html>


More information about the Noise mailing list