[Egyptian] Two group joiners

[Mark-Jan Nederhof]

Dear Stéphane,

To support to what you wrote on coherence: A long time ago we passed beyond the stage of knowing 
we need certain primitives. The main question is how to fit them together into a coherent scheme with 
a syntax that is consistent and unambiguous, without sacrificing (too much) of the power of these 
primitives and how they can be combined.

> I understood that parentheses are very difficult in Unicode, but can’t we think of a kind of ‘glue’ operator (precedence, as in Mark-Jan’s et al. proposal, p. 8-9), e.g. with the dot, <s * in :. n> or <m [insert_top_right] x :. ib *. Z1>, that would create groups by bounding signs together. What would be the problem of such an approach (it was initially suggested by Serge, not my idea, I insist)? Can you explain me why it would be problematic?

With respect to the discussion in Section 9 of:
http://www.unicode.org/L2/L2016/16210-egyptian-control.pdf
the '.' above is a notational variant of the 'levels' of operator precedence, there achieved by 
having several copies of each primitive, for different levels. Here, for every '.' added behind 
an operator one goes up one level of operator precedence.

Some trick using operator precedence, either using the '.' or using several control characters per
primitive with different binding values, would be an alternative to having brackets. There is a 
relatively straightforward mechanical mapping from one notation to the other, so there should be 
no difference to the expressive power and I don't think that among us (TLA/Ramses/St Andrews) 
there is any firm commitment to brackets or otherwise.

But as explained in Section 9, there are costs to abandoning brackets. Specifying the syntax with
operator precedence formally would be a bit tricky, it might not be easy for the human to know 
when to use :... or *.. or insert_top_right. , and OpenType cannot really parse, as it is not a general 
purpose programming language, and trying to implement about a dozen different binding values 
(4 primitives times 3 levels of operator precedence) might be pushing our luck. 
My working assumption is that an input method editor would be used to edit hieroglyphic text in 
practice, so the actual syntax should not matter too much, as long as it is hidden from the user.

Best regards,
Mark-Jan