[swift-evolution] [Proposal] Refining Identifier and Operator Symbology
Nevin Brackett-Rozinsky
nevin.brackettrozinsky at gmail.com
Fri Oct 21 15:54:17 CDT 2016
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.
Furthermore, just like during the Great Renaming—when we used some general
rules to automate the name changes, then went through and fine-tuned by
hand to deal with cases where the automated rules produced suboptimal
results—I think it will be great if we can classify the majority of
characters all at once with certain criteria, but we should expect and plan
to go through by hand afterward to clean up the edge cases that humans can
tell were misplaced by the broad rules.
It is more important that we get the definitions of operator and identifier
characters *right* than that we make them *rigidly conform to a certain
rule*. If our rule says “∞” should be an operator, but we as humans
recognize that to be a mistake, then we should change it. Heck, maybe we
should make “∞” parse as a floating-point literal!
The point is, bikeshedding over operators has been and continues to be
diverting our collective attention away from the rest of the proposal, such
as using the IDC_Start and IDC_Continue categories that you mentioned.
Nevin
On Fri, Oct 21, 2016 at 4:10 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> A few other thoughts:
>
> * One of our (or at least my) overarching goals for this proposal is to
> refine identifier and operator sets by moving away from an ad-hoc
> character-by-character approach to a systematic treatment that relies on
> well-defined criteria to select blocks of characters for inclusion. My
> personal opinion is that reverting to discussions of individual characters,
> such as the turned ampersand, means we're simply re-shuffling the current
> set of identifier and operator characters to a different one, having failed
> to discover any systematic basis for doing so. I think one of the strongest
> parts of this proposal is the straight-up statement that identifier start
> characters shall be IDC_Start and identifier continuation characters shall
> be IDC_Continue, modulo a few ASCII characters that require special
> treatment in Swift.
>
> * Particularly if the community insists on emoji being identifiers, we
> will have to critically evaluate how to proceed on that in tandem with
> operators, because there exist emojified operators and arrows, and certain
> emoji are encoded in blocks that are otherwise symbols, which Unicode is
> likely to deem as operators in the future. Moreover, IIUC, certain
> codepoints can be either emoji or non-emoji symbols and variant selectors
> can specify which they are, but in the absence of a variant selector
> *either* the emoji or non-emoji version can be correctly displayed
> depending on the platform. For some of these, the non-emoji version is
> either clearly or plausible an operator character. Therefore, without
> dealing *very* carefully with emoji and with operators at the same time, we
> are failing to address a key motivation of this proposal, which is to fix
> the incorrect separation between emoji operators and emoji identifiers.
>
>
> On Fri, Oct 21, 2016 at 2:36 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>> I disagree pretty strongly with this approach. Firstly because as you've
>> pointed out, changes to the operator characters will have effects on valid
>> operator character sets, secondly because a major question about operators
>> is whether it is feasible or no to manually exclude empty set and infinity
>> given that Unicode is likely to reject that approach. For these reasons I
>> feel very strongly that the reforming the operator and identifier
>> characters must move in tandem.
>>
>> On Fri, Oct 21, 2016 at 14:28 Nevin Brackett-Rozinsky via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>
>>> I think it is important that we as a community discuss the non-operator
>>> portion of this proposal. And, given the strong opinions about operators
>>> that have been expressed, I think it is unlikely we will do so while major
>>> operator changes are on the table.
>>>
>>> Thus I would suggest that either the operator changes should be
>>> separated out into their own proposal, or we should make only minor (and
>>> generally consensus-agreed) changes to the operator set as part of this one.
>>>
>>> Here is what I propose:
>>>
>>> Emoji shall be identifiers, not operators.
>>> The turned ampersand shall be an operator, not an identifier.
>>> The empty set and infinity symbols shall be identifiers, not operators.
>>>
>>> All other potential changes to the set of operator characters then go in
>>> their own proposal, which I am sure will receive a lot of attention.
>>>
>>> It may turn out that the non-operator portion of this proposal
>>> nonetheless touches characters that Swift has designated for operators, in
>>> which case we may address those as they arise.
>>>
>>> Does that sound like a reasonable way forward?
>>>
>>> Nevin
>>>
>>>
>>>
>>> On Fri, Oct 21, 2016 at 9:27 AM, Ben Rimmington via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>
>>> > On 21 Oct 2016, at 13:42, Benjamin Spratling wrote:
>>> >
>>> > Brackets and symbols are definitely operators. Different brackets are
>>> used to represent various quantum mechanical forms and operations.
>>>
>>> The brackets are mostly "bracket pieces":
>>>
>>> [:Math_Symbol:]
>>> - [:name=/\bANGLE\b/:]
>>> - [:Emoji:]
>>> - [:ID_Continue:]
>>> - [:NFC_Quick_Check=No:]
>>> & [:Script_Extensions=Common:]
>>> & [:Block=Miscellaneous_Technical:]
>>>
>>> <http://www.unicode.org/cldr/utility/list-unicodeset.jsp?a=%
>>> 5B%3AMath_Symbol%3A%5D%0D%0A-+%5B%3Aname%3D%2F%5CbANGLE%5Cb%
>>> 2F%3A%5D%0D%0A-+%5B%3AEmoji%3A%5D%0D%0A-+%5B%3AID_Continue
>>> %3A%5D%0D%0A-+%5B%3ANFC_Quick_Check%3DNo%3A%5D%0D%0A%26+%5B%
>>> 3AScript_Extensions%3DCommon%3A%5D%0D%0A%26+%5B%3ABlock%3DM
>>> iscellaneous_Technical%3A%5D>
>>>
>>> > Arrows are also useful as operators, including but not restricted to
>>> chemical reactions.
>>>
>>> Including arrows, there are 740 operators:
>>>
>>> [:Math_Symbol:]
>>> - [:name=/\bANGLE\b/:]
>>> - [:name=EMPTY SET:]
>>> - [:name=INFINITY:]
>>> - [:Emoji:]
>>> - [:ID_Continue:]
>>> - [:NFC_Quick_Check=No:]
>>> & [:Script_Extensions=Common:]
>>> & [[:Block=Arrows:]
>>> [:Block=General_Punctuation:]
>>> [:Block=Latin_1_Supplement:]
>>> [:Block=Mathematical_Operators:]
>>> [:Block=Miscellaneous_Mathematical_Symbols_A:]
>>> [:Block=Miscellaneous_Symbols_And_Arrows:]
>>> [:Block=Supplemental_Arrows_A:]
>>> [:Block=Supplemental_Arrows_B:]
>>> [:Block=Supplemental_Mathematical_Operators:]]
>>>
>>> <http://www.unicode.org/cldr/utility/list-unicodeset.jsp?a=%
>>> 5B%3AMath_Symbol%3A%5D%0D%0A-+%5B%3Aname%3D%2F%5CbANGLE%5Cb%
>>> 2F%3A%5D%0D%0A-+%5B%3Aname%3DEMPTY+SET%3A%5D%0D%0A-+%5B%
>>> 3Aname%3DINFINITY%3A%5D%0D%0A-+%5B%3AEmoji%3A%5D%0D%0A-+%5B%
>>> 3AID_Continue%3A%5D%0D%0A-+%5B%3ANFC_Quick_Check%3DNo%3A%
>>> 5D%0D%0A%26+%5B%3AScript_Extensions%3DCommon%3A%5D%0D%
>>> 0A%26+%5B%5B%3ABlock%3DArrows%3A%5D%0D%0A+++%5B%3ABlock%
>>> 3DGeneral_Punctuation%3A%5D%0D%0A+++%5B%3ABlock%3DLatin_1_
>>> Supplement%3A%5D%0D%0A+++%5B%3ABlock%3DMathematical_
>>> Operators%3A%5D%0D%0A+++%5B%3ABlock%3DMiscellaneous_
>>> Mathematical_Symbols_A%3A%5D%0D%0A+++%5B%3ABlock%
>>> 3DMiscellaneous_Symbols_And_Arrows%3A%5D%0D%0A+++%5B%
>>> 3ABlock%3DSupplemental_Arrows_A%3A%5D%0D%0A+++%5B%3ABlock%3D
>>> Supplemental_Arrows_B%3A%5D%0D%0A+++%5B%3ABlock%3DSupplement
>>> al_Mathematical_Operators%3A%5D%5D>
>>>
>>> -- Ben
>>>
>>> _______________________________________________
>>> 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/20161021/5a2b2129/attachment.html>
More information about the swift-evolution
mailing list