<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br>On 10 Dec 2015, at 14:00, James Noble <<a href="mailto:kjx@ecs.vuw.ac.nz">kjx@ecs.vuw.ac.nz</a>> wrote:<br><br><blockquote type="cite"><blockquote type="cite">Not requiring the second set of brackets is quite important,<br></blockquote><br>Yes...<br>Hopefully Michael can point out what the issue is...<br><br><blockquote type="cite">I think the issue is distinguishing between [ ] as an operator, ... and as a sequence denotation<br></blockquote><br>Again yes<br><br><blockquote type="cite">Two simple solutions are to keep [ ] as an operator, and use something else (like ⟨ ⟩) for sequences, or to appropriate [ and ] for sequences and remove them from the set of available operators.<br></blockquote><br>Operators have to be delineated by spaces in Kernan - which I've now got used to and like: it does makes things easier to read. So one option is that indexing operators cannot be preceded by spaces, but literals must be. <br></blockquote><div><br></div>I think that space sensitivity is daft. And using one rule for the * operator and the <i>opposite</i> rule for the [] operator is dafter. <div><br></div><div>Spaces around operator symbols do make the expression easier to read when there is only one operator and two operands. But when you have a complex arithmetic expression, the effect is to make it harder to read, because it falls off the end of the line. So this is something that I would rather leave up to the programmer to consider on a case-by-case basis.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Andrew</div><div><br><br></div></body></html>