<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 5, 2016 at 4:01 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Maybe, but if the only benefit here is that a tool that works with<br>
text patterns can avoid scanning for "...", that's not that much of a<br>
gain.<br>
<br>
There's not that much cost to this proposal either. But the visual<br>
appearance would be a little messier (we're indicating the same<br>
information 2 different ways).<br></blockquote><div><br></div><div><div>I'd argue that it is not the same information. Pre-message tokens come from a more restrictive set
("e", "f", and "s" only) and can only occur in certain orders. The
grammar can enforce these rules if it knows early enough.<br><br></div>It
is possible to write an LALR(1) parser in Bison with the same arrows for both
(I know because I just did so) but to avoid reduce/reduce conflicts it is
necessary to optimistically parse the pre-messages as full messages and
then later go back during semantic analysis to eliminate bad pre-messages and messages. With double-arrows, the grammar can enforce the rules in one pass.<br><br></div><div>I can live with it either way I suppose, but the more context-free the better from a langsec point of view.<br></div><div><br></div><div>ABNF for the grammar is appended. Basic tokens only, no hybrid. Extending it to hybrid tokens is obvious.<br></div><div></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, currently you can think of "->" and "<-" as arrows, rather than<br>
text, and I've done this sometimes:<br>
<br>
<a href="https://noiseprotocol.org/docs/noise_stanford_seminar_2016.pdf" rel="noreferrer" target="_blank">https://noiseprotocol.org/docs<wbr>/noise_stanford_seminar_2016.<wbr>pdf</a><br>
<br>
With "=>" notation this isn't as easy - you'd need a fat and skinny<br>
arrow, or an arrow with two tails?<br></blockquote><div><br></div><div>Unicode has lots of arrows to choose from for fancy presentations. :-)<br></div></div><br><a href="https://en.wikipedia.org/wiki/Template:Unicode_chart_Arrows" target="_blank">https://en.wikipedia.org/wiki/<wbr>Template:Unicode_chart_Arrows</a><br><br></div><div class="gmail_extra">Cheers,<br><br></div><div class="gmail_extra">Rhys.<br><br></div><div class="gmail_extra">---- ABNF ----<br>; Defined using the ABNF syntax from RFC 5234. The character set is US-ASCII.<br>;<br>; The "pattern-file" element is intended for a pattern dictionary file that<br>; contains multiple pattern definitions.<br>;<br>; The "pattern-single" element is intended for applications that wish to<br>; provide an API to define the specific pattern to use in a handshake.<br><br>; Syntactic elements<br><br>pattern-file = *(wsp pattern) wsp<br><br>pattern-single = wsp pattern wsp<br><br>pattern = header wsp [pre-message wsp] messages<br><br>header = name wsp "(" wsp params wsp ")" wsp ":"<br><br>params = param *(wsp "," wsp param)<br><br>param = "e" / "s" / "re" / "rs"<br><br>pre-message = pre-message-init [wsp pre-message-resp] wsp "..." /<br> pre-message-resp wsp "..."<br><br>pre-message-init = "=>" wsp pre-message-tokens<br><br>pre-message-resp = "<=" wsp pre-message-tokens<br><br>pre-message-tokens = "e" / "s" / "e" wsp "," wsp "s"<br><br>messages = *(message-pair wsp) message-init / message-pair<br><br>message-pair = message-init wsp message-resp<br><br>message-init = "->" wsp message-tokens<br><br>message-resp = "<-" wsp message-tokens<br><br>message-tokens = message-token *(wsp "," wsp message-token)<br><br>message-token = "e" / "s" / "ee" / "ss" / "se" / "es"<br><br>; Lexical tokens<br><br>name = "Noise_" name-component *("+" name-component)<br><br>name-component = 1*(ALPHA / DIGIT)<br><br>wsp = *(WSP / eol / comment)<br><br>comment = "//" *(VCHAR / WSP) eol<br><br>eol = CRLF / LF<br><br>; Imported from core ABNF (RFC 5234): VCHAR, WSP, CRLF, LF, ALPHA, DIGIT<br><br></div></div>