[noise] Machine-readable pattern list

[Naveen Nathan]

On Wed, Oct 5, 2016, at 08:31 AM, Rhys Weatherley wrote:
> 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.
I would welcome this addition to the spec. I have been working on a
python implementation and found manually writing the patterns both error-
prone and tedious.

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