[Egyptian] Two group joiners

[Stéphane polis]

Dear Mark-Jan,

Yeap, I do agree.

As you can see, I’m simply trying to be imaginative and to think about the better possible consensus before the very close deadline (in order not to take the chance for everything to collapse or to go in unwarranted territories, because I do care). As such, I understand perfectly the cost of getting rid of parenthesis; my point is that, as we know that we need to make clusters (and there is not much room for discussion about this basic principle), the only alternative would be this ‘glue-precedence’ operator, discussed in Section 9 of the document, that has not yet been discussed by others. 

It’s one or the other, but there are logically no third option as far as I understand.
 
I would like to hear what you and others think about the ‘scope operator’ for the insertion, but to sum up, a basic consensus document for control characters could in my view contain only 8 control characters (and we know that we could handle most [if not all] of the cases discussed so far with these characters, that the scheme will be coherent, that it will be easy to expand with others operators without destroying everything, etc.), namely:

1) Vertical [:] // Already in MdC and in Bob’s proposal
2) Horizontal [*] // Already in MdC in Bob’s proposal

3) Groups (precedence operator) [.] // Needed for clusters (insertion, vertical, horizontal) and for avoiding the multiplication of group-joiners of various level in the future.

4) Top-left [⸥] // Agreed on by most (if not all)
5) Bottom-left [⸣] // Agreed on by most (if not all)
6) Top-Right [⸤] // Agreed on by most (if not all)
7) Bottom-Right [⸢] // Agreed on by most (if not all)

8) Scope operator [!] // A suggestion to be discussed

Maybe that a quadrat separator [-] should be added in order to avoid issues, e.g. with multiple corners insertions following one another (but this should be tested of course), and because after all, the basic unit of this writing system is the quadrat (not the sign, even if it happens that 1 sign = 1 quadrat).

These operators correspond to a very ‘flat’ and linear syntax (without ‘begin’ and ‘end’ markers that seem to be so problematic), which is a requirement from the Unicode specialists as I understand it.

If needed, I am ready to leave out of this ‘consensus’ document:
- The join
- The insert-center
- The stack
- The empty

Not because I think we don’t need them (I think it would be great to have), but (1) because I would like the discussion to focus on the 8/9 operators above, (2) because these additions are easy to make in a second step and will not impedes much for short term encoding.

That’s about it for me at the moment. I leave the floor to you, Bob and others. 

Let me stress that it’s probably difficult for me/us to make more steps in the direction of a consensus. At this stage, everyone should probably try and understand other’s point of view and accept that compromises are needed rather quickly...

As you can see in the summary above, the central point is about the group/precedence operator. 
Then the ‘scope’ operator and what you think about it.
The rest should be easily agreed on.

Unicode is not a one time thing, as Bob said, sure, but one decision can affect all the future developments.

Take care,

Stéphane

------------------------------------------------------
Chercheur qualifié F.R.S.-FNRS

Université de Liège
Service d'Égyptologie
Département des sciences de l’Antiquité
Place du 20-Août,
B-4000 Liège

http://www.egypto.ulg.ac.be
------------------------------------------------------



> Le 28 juil. 2016 à 11:32, Mark-Jan Nederhof <mn31 at st-andrews.ac.uk> a écrit :
> 
> 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
> 
> _______________________________________________
> Egyptian mailing list
> Egyptian at evertype.com
> http://evertype.com/mailman/listinfo/egyptian_evertype.com