[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

Sat Oct 22 01:46:56 CDT 2016

On Sat, Oct 22, 2016 at 1:37 AM, Nevin Brackett-Rozinsky via
swift-evolution <swift-evolution at swift.org> wrote:

> I just read through your new proposal, and I have to say it is extremely
> well-written. There is a vast quantity of information presented quite
> clearly, and it gives me a lot to think about.
>
>
> On Fri, Oct 21, 2016 at 5:38 PM, Jonathan S. Shapiro <jonathan.s.shapiro@
> gmail.com> wrote:
>
>> On Fri, Oct 21, 2016 at 1:54 PM, Nevin Brackett-Rozinsky via
>> swift-evolution <swift-evolution at swift.org> wrote:
>>
>>> I think it is plainly evident that the well-defined criteria you would
>>> like to use *have not yet been defined* by Unicode. That is a large part of
>>> why I recommend that we postpone a major overhaul of our operator
>>> characters.
>>>
>>
>> That's a feasible way to go, but keep in mind that the UAX31 changes are
>> being co-designed with and informed by the current discussion. There are a
>> bunch of things that have come up here that will allow UAX31 to side-step
>> some "might have happened" mistakes, so this discussion has been very
>> useful.
>>
>> The Swift community can and should make its own decision about whether to
>> remain engaged. The risk of disengagement is that messy compatibility
>> issues will probably have to be faced later that we can easily head-off now.
>>
>
> Ah, I had not previously understood that. Well then, in light of the fact
> that the Unicode recommendations may be influenced by our decisions, and
> given that Swift is an opinionated language, it follows that we ought to
> make our best effort at separating out what we have been calling “operator
> characters” (and your revised proposal calls “symbol identifier”
> characters).
>
> In particular, since there does not yet exist a categorization of symbols
> which fits our needs, and since our needs may help shape such a
> categorization as it forms, it behooves us to fully undertake the endeavor
> of defining which symbols we would like to see in which roles for Swift.
>
> Your proposal mentions and links to a set of 650 code points
> <http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%21%5C%24%25%5C%26*%2B%5C-%2F%3C%3D%3E%3F%5C%5E%7C%7E%0D%0A%0D%0A%5Cu00AC%0D%0A%5Cu00B1%0D%0A%5Cu00B7%0D%0A%5Cu00D7%0D%0A%5Cu00F7%0D%0A%0D%0A%5Cu2208-%5Cu220D%0D%0A%5Cu220F-%5Cu2211%0D%0A%5Cu22C0-%5Cu22C3%0D%0A%5Cu2212-%5Cu221D%0D%0A%5Cu2238%0D%0A%5Cu223A%0D%0A%5Cu2240%0D%0A%5Cu228C-%5Cu228E%0D%0A%5Cu2293-%5Cu22A3%0D%0A%5Cu22BA-%5Cu22BD%0D%0A%5Cu22C4-%5Cu22C7%0D%0A%5Cu22C9-%5Cu22CC%0D%0A%5Cu22D2-%5Cu22D3%0D%0A%5Cu2223-%5Cu222A%0D%0A%5Cu2236-%5Cu2237%0D%0A%5Cu2239%0D%0A%5Cu223B-%5Cu223E%0D%0A%5Cu2241-%5Cu228B%0D%0A%5Cu228F-%5Cu2292%0D%0A%5Cu22A6-%5Cu22B9%0D%0A%5Cu22C8%0D%0A%5Cu22CD%0D%0A%5Cu22D0-%5Cu22D1%0D%0A%5Cu22D4-%5Cu22FF%0D%0A%5Cu22CE-%5Cu22CF%0D%0A%0D%0A%5Cu2A00-%5Cu2AFF%0D%0A%0D%0A%5Cu27C2%0D%0A%5Cu27C3%0D%0A%5Cu27C4%0D%0A%5Cu27C7%0D%0A%5Cu27C8%0D%0A%5Cu27C9%0D%0A%5Cu27CA%0D%0A%5Cu27CE-%5Cu27D7%0D%0A%5Cu27DA-%5Cu27DF%0D%0A%5Cu27E0-%5Cu27E5%0D%0A%0D%0A%5Cu29B5-%5Cu29C3%0D%0A%5Cu29C4-%5Cu29C9%0D%0A%5Cu29CA-%5Cu29D0%0D%0A%5Cu29D1-%5Cu29D7%0D%0A%5Cu29DF%0D%0A%5Cu29E1%0D%0A%5Cu29E2%0D%0A%5Cu29E3-%5Cu29E6%0D%0A%5Cu29FA%0D%0A%5Cu29FB%0D%0A%0D%0A%5Cu2308-%5Cu230B%0D%0A%5Cu2336-%5Cu237A%0D%0A%5Cu2395%5D> that
> your group identified by hand as operators. It also links to the combined Sm
> and So categories
> <http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%5B%3ASm%3A%5D%5B%3ASo%3A%5D%5D>.
> However what you actually propose is the far-more-limited Mathematical
> Operators block
> <http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5Cp%7BBlock=Mathematical%20Operators%7D>
> .
>
> I will take it upon myself to go through code-points by hand and see what
> I can find.
>
> It is worth noting that your proposed “symbol identifier” category, by its
> very name, suggests it should have broader membership than just operators.
> I am not sure if that was intentional, however I will restrict my attention
> to symbols that may reasonably function as operators.
>
> After a preliminary glance through the code blocks, I believe there are
> operator-like characters in these blocks
> <http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5Cp%7BBlock%3DBasic+Latin%7D%0D%0A%5Cp%7BBlock%3DLatin-1+Supplement%7D%0D%0A%5Cp%7BBlock%3DGeneral+Punctuation%7D%0D%0A%5Cp%7BBlock%3DLetterlike+Symbols%7D%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5Cp%7BBlock%3DMathematical+Operators%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Mathematical+Symbols-A%7D%0D%0A%5Cp%7BBlock%3DSupplemental+Arrows-A%7D%0D%0A%5Cp%7BBlock%3DSupplemental+Arrows-B%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Mathematical+Symbols-B%7D%0D%0A%5Cp%7BBlock%3DSupplemental+Mathematical+Operators%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Symbols+and+Arrows%7D%0D%0A%5Cp%7BBlock%3DSupplemental+Punctuation%7D&g=&i=>
> :
> Basic Latin
> Latin-1 Supplement
> General Punctuation
> Letterlike Symbols
> Arrows
> Mathematical Operators
> Miscellaneous Technical
> Miscellaneous Mathematical Symbols-A
> Supplemental Arrows-A
> Supplemental Arrows-B
> Miscellaneous Mathematical Symbols-B
> Supplemental Mathematical Operators
> Miscellaneous Symbols and Arrows
> Supplemental Punctuation
>
> Furthermore, the following blocks
> <http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5Cp%7BBlock%3DBox+Drawing%7D%0D%0A%5Cp%7BBlock%3DBlock+Elements%7D%0D%0A%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A%5Cp%7BBlock%3DDingbats%7D%0D%0A%5Cp%7BBlock%3DBraille+Patterns%7D%0D%0A%5Cp%7BBlock%3DCJK+Symbols+and+Punctuation%7D%0D%0A%5Cp%7BBlock%3DYijing+Hexagram+Symbols%7D%0D%0A%5Cp%7BBlock%3DAncient+Symbols%7D%0D%0A%5Cp%7BBlock%3DMusical+Symbols%7D%0D%0A%5Cp%7BBlock%3DTai+Xuan+Jing+Symbols%7D&g=&i=>
> *may* have symbols that we want to allow in operators:
> Box Drawing
> Block Elements
> Geometric Shapes
> Miscellaneous Symbols
> Dingbats
> Braille Patterns
> CJK Symbols and Punctuation
> Yijing Hexagram Symbols
> Ancient Symbols
> Musical Symbols
> Tai Xuan Jing Symbols
>
> I think that covers all the blocks with potentially operator-like
> characters. When I have had time to go through character by character I
> will report back my findings.
>

A previous version of our proposal went through these blocks
character-by-character. It was not a fruitful exercise, and absent a
compelling use case, I would not recommend it, as Jonathan has made clear
that whatever UAX#31 ends up doing, it's definitely the case that Unicode
will not be adopting this character-by-character approach.

> Nevin
>
>
>
> On Sat, Oct 22, 2016 at 12:59 AM, Jonathan S. Shapiro via swift-evolution
> <swift-evolution at swift.org> wrote:
>
>> All:
>>
>> Jacob has already identified a *big* hole in the proposal, which is that
>> it doesn't define how operator-bound identifiers are treated by import.
>> That definitely needs to be addressed by the proposal. It's
>> straightforward, but easy to get wrong. I will address that early tomorrow.
>>
>>
>> Jonathan
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161022/3cfb1727/attachment.html>