I did look at your list; as I said, I and others have made similar lists before and have discovered their specific weaknesses. Again, I very much think this is not going to be a fruitful on-list approach, and certainly it's not appropriate for this particular thread. I will reply offlist with specific insights. On Mon, Feb 6, 2017 at 21:05 Nevin Brackett-Rozinsky < [email protected]> wrote:
> Did you look at how my list is constructed? It is almost entirely built > from existing Unicode designations, with only a small number of exceptions. > To wit: > > Begin with the category: > > Symbol, math > > > Remove everything from the blocks: > > Superscripts And Subscripts > Miscellaneous Technical > Geometric Shapes > Miscellaneous Symbols > Alphabetic Presentation Forms > Small Form Variants > Halfwidth And Fullwidth Forms > Mathematical Alphanumeric Symbols > Arabic Mathematical Alphabetic Symbols > > > Remove everything from the subheadings: > > Variant letterforms and symbols > Letterlike symbol > > > Add everything from the block > > Arrows > > > Add everything from the subheadings: > > Double punctuation for vertical text > General punctuation, EXCEPT [U+203F U+2040 U+2045 U+2046 U+2054] > Archaic punctuation, EXCEPT [U+2E31 U+2E33 U+2E34 U+2E3F] > > > Add our existing ASCII and Latin-1 operators: > > [/ = - + ! * % < > & | ^ ~ ?] > > [¡ ¢ £ ¤ ¥ ¦ § © « ¬ ® ° ± ¶ » ¿], EXCEPT [¢ £ ¤ ¥ © ®] > > > Add the turned ampersand: > > U+214B > > > • • • > > This is hardly an ad hoc list, since it is built on existing > classifications and slightly modified to fit our purposes. To it we may add > the backslash (U+005C), and from it remove the empty set (U+2205) and > infinity (U+221E) symbols. Currency signs could go either way, so I have > left them unspecified (hence not operators) for now. > > Some discussion about whether to include the following subheadings may be > in order: > > Drafting symbols > Miscellaneous technical, EXCEPT [U+23E8] > > > Beyond that, I think it is fine to leave symbol-like glyphs unspecified > for now, neither operators nor identifiers. > > Nevin > > > > On Mon, Feb 6, 2017 at 9:34 PM, Xiaodi Wu <[email protected]> wrote: > > On Mon, Feb 6, 2017 at 7:36 PM, Nevin Brackett-Rozinsky via > swift-evolution <[email protected]> wrote: > > Given that the definition of operator characters in Swift is “part of > Swift”, it follows that any change to that set will go through the Swift > Evolution process, which includes discussion on this list. I do not see a > reasonable way to skip that, nor would I consider it desirable to do so. > Discussing on this list which characters should be operators in Swift is > *prima facie* a necessary part of changing them. > > In light of the fact that our current operator-character situation needs > to be fixed—meaning we will have to decide which characters should and > should not be allowed in operators—and seeing as any proposal to solve the > problem will be discussed on this list, the natural conclusion is that > discussing which characters should be operators is *exactly* what we ought > to do. > > Moreover, we are trying to decide which operators are right for *Swift*, > thus our goals include expressivity, usefulness, and enjoyability. Our > goals do *not* include being maximally conservative, and indeed I view > parsimony in operator-character availability as undesirable. > > We should aim to choose the *right* set of operator characters, for some > Swifty and opinionated value of “right”. If the recommendations that > Unicode settles on strike us as right for Swift, that is great. But those > recommendations do not exist yet, and so far it sounds like they could well > be defined in a way which is *not* right for Swift. > > Perhaps Unicode will add a new category for operators, and they will go > character-by-character to put certain glyphs in it. But if they don’t, then > as you say the existing categories are not sufficient for Swift’s purposes, > so their recommendations will not solve our problem. And if they do, we > still would need to verify that their decision matches our use-case. > > The past proposal to gut non-ASCII operators from Swift was rightly > blocked, for it would have damaged the language. My follow-up with a list > of 1,020 characters to use as operators has not seen much discussion. If > there were any controversial characters in it or omissions from it, I hope > someone would raise an objection. > > In any case, I think that discussing which characters are right for Swift > operators is an entirely proper and expected use of this mailing list, and > I suggest we do so during the Swift 4 timeframe because it affects source > compatibility. > > > You misunderstand my drift. Of course any such change to Swift would have > to go through this list, and of course that involves asking which > characters are right for Swift operators. The question is _how_ to > undertake a fruitful discussion. > > Consider this: that part of our previous draft which concerned adopting > UAX#31 received immediate and almost universal consensus. One technical > report has made it possible to adopt a cogent set of some 100,000-odd > characters for identifiers *without* analyzing each one, with the added > benefit that Swift would be able to parallel the evolution of Unicode in > that respect as the years go on. That analysis involved, exactly as you > say, asking exactly which characters make sense for Swift identifiers, but > did so by means of overarching principles (for example, should aspirational > scripts be included?). > > By comparison, that part of the previous draft which concerned matters not > yet settled by Unicode experts prompted vehement disagreement, with great > debate on the minutiae of individual codepoints that never reached > consensus. I too have made a list of 500-1000 operator characters. Several > versions in fact. So did other authors of the previous draft. Some of us > made character-by-character lists. Some also made block-by-block lists. We > carefully considered which operators might overlap with emojis, and which > were confusables, and whether operators require different Unicode > normalization from identifiers. We debated questions such as whether tiny > and miny were mathematical operators or something else. Make no mistake, we > reached no ultimate consensus on a lot of these questions even amongst the > authors. > > I have held off on re-introducing this proposal in part because I'm > seriously concerned that, without a better method, such an exercise is > exceedingly poor form on such a high-traffic list. After all, we don't go > line-by-line through draft implementations of proposed features on this > list. We need to be able to articulate useful principles by which > characters outside the ASCII range will be classified as operators; > Jonathan Shapiro has indicated that not even Unicode will proceed with an > ad-hoc character-by-character analysis. If we can come up with overarching > principles that are workable, then it is plausible that Unicode will follow > our lead. So yes, I agree with you absolutely, discussing which characters > are right for Swift operators is an entirely proper and expected use of > this mailing list. Now, _how_ to discuss it? I feel very strongly the > answer is not by scrutiny of a list of codepoints. > > In any case, again we've gone far afield. I'm supportive of adding \ as an > operator. That is a standalone proposal with its own merits; would love to > see that proposed and considered on its own. > > > Nevin > > > On Mon, Feb 6, 2017 at 7:05 PM, Xiaodi Wu <[email protected]> wrote: > > Indeed, I'd be thrilled to revise and reintroduce a proposal to update > identifier and operator characters, if co-authors of that proposal are OK > with it. Agree entirely with the principle you enunciate; that is exactly > how we tried to approach it previously. I take it that you agree that a > comprehensive revision of identifier characters cannot happen without > thinking about operator characters, and vice versa, and I believe we came > to that conclusion as well. > > Two difficulties arose. Jonathan Shapiro indicated that the Unicode > approach would invariably be to specify which characters are valid > identifiers, etc. not by code points or planes but by "categories," for > which there are none for operators but also for which there are problematic > ones for emoji (the numerals 0-9 belong to the emoji category, for > instance; there is another emoji_presentation category which has its own > tricks). Therefore, we considered that the most conservative way to > classify "definite operators," "definite identifiers," and everything else > was to leave emoji out (UAX31 does not include them as identifier > characters) and to roll back operator characters to the ASCII range. > However, both temporary measures were soundly rejected. > > There are a number of security issues to be ironed out with respect to > emoji. For instance, emoji modifiers such as skin tones and genders allow > different identifiers to be made that are visually identical or nearly so. > (And yes, I'm aware that you or I could come up with an ad-hoc solution to > this particular problem with emoji, but the issue is identifying all such > relevant problems and coming up with solutions that jibe with future > Unicode solutions to the same problems.) It would have been nice to leave > this out entirely for now until further guidance from Unicode experts, but > the community made it clear that emoji were a sine qua non. > > Likewise, every discussion on operator characters thus far has devolved > into a series of replies nominating specific characters for inclusion. I > continue to believe a character-by-character debate on this mailing list > would be exceptionally poor form. My point in replying to this thread is > only that we don't need to get into any of this (Unicode operators, > canonicalization forms, emoji, etc.--much as I would love to) in order to > consider the isolated addition of an ASCII-range operator \. That idea > seems very reasonable, independently useful, and limited in scope. > > > On Mon, Feb 6, 2017 at 15:28 Nevin Brackett-Rozinsky via swift-evolution < > [email protected]> wrote: > > Although there was, as you say, some push-back against revamping our set > of operator characters, there was also substantial push-forward. Many > people want to resolve the problematic situation we currently have > regarding the designation of operators and identifiers. > > And indeed, cutting back to ASCII-only operators would have been an > abominable choice. However waiting for the Unicode Consortium to draft > guidelines for operator characters means prolonging our existing > predicament. Additionally, in the discussion last fall it was mentioned > that Unicode personnel are aware of what we are doing with Swift operators, > and that our decisions may help to inform their classification of operator > characters: > > On Fri, Oct 21, 2016 at 5:38 PM, Jonathan S. Shapiro < > [email protected]> wrote: > > 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. > > > Given all these considerations, I think the principled approach is for us > to move forward with a 3-part categorization of characters into operators, > identifiers, and unspecified (to be determined). That way we need not > harangue ourselves over every controversial glyph, and may instead quickly > determine those characters which should definitely be operators and those > which should definitely be identifiers, while saving the difficult > decisions until such time as Unicode produces recommendations and/or we > decide to undertake a more comprehensive review. > > Nevin > > > On Sun, Feb 5, 2017 at 8:29 PM, Xiaodi Wu <[email protected]> wrote: > > IIRC, where we left the discussion last time was that there was work not > yet complete within Unicode on delineating identifier and operator > characters. As there was broad agreement to align identifier characters > with Unicode standards, and since the strict separation between identifiers > and operators means that no character should belong to both, there was > hesitation to declare an operator what Unicode may later deem to be an > identifier. > > There was strenuous objection to temporarily cutting back operators to the > ASCII range until Unicode completes its work, but also pushback in going > character-by-character above the ASCII range. > > In any case, \ seems perfectly reasonable as an additional operator > character that doesn't have to wait for Unicode. > > On Sun, Feb 5, 2017 at 19:02 T.J. Usiyan via swift-evolution < > [email protected]> wrote: > > +1 from me. > > I hope that operators get more work soon, especially with regard to math. > > On Sun, Feb 5, 2017 at 5:09 PM, Nevin Brackett-Rozinsky via > swift-evolution <[email protected]> wrote: > > +1 as well. I also support adding these four symbols: ⅀ ؆ ؇ ⅋ as > operators. > > There was substantial discussion last fall about revamping operators in > Swift, with the primary goal of removing characters that should not be in > the set. I went through the Unicode tables and compiled a list of 1,020 > characters that I think definitely should be operators [list of operator > characters > <http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%5B%3ASm%3A%5D%0D%0A%0D%0A-%5Cp%7BBlock%3DSuperscripts+And+Subscripts%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A-%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A-%5Cp%7BBlock%3DAlphabetic+Presentation+Forms%7D%0D%0A-%5Cp%7BBlock%3DSmall+Form+Variants%7D%0D%0A-%5Cp%7BBlock%3DHalfwidth+And+Fullwidth+Forms%7D%0D%0A-%5Cp%7BBlock%3DMathematical+Alphanumeric+Symbols%7D%0D%0A-%5Cp%7BBlock%3DArabic+Mathematical+Alphabetic+Symbols%7D%0D%0A-%5Cp%7Bsubhead%3DVariant+letterforms+and+symbols%7D%0D%0A-%5Cp%7Bsubhead%3DLetterlike+symbol%7D%0D%0A%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5B%2F+%3D+%5C-+%2B+%21+*+%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%5D%0D%0A%5B%C2%A1+%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A6+%C2%A7+%C2%A9+%C2%AB+%C2%AC+%C2%AE+%C2%B0+%C2%B1+%C2%B6+%C2%BB+%C2%BF%5D+-+%5B%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A9+%C2%AE%5D%0D%0A%5Cp%7Bsubhead%3DGeneral+punctuation%7D+-+%5BU%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054%5D%0D%0A%5Cp%7Bsubhead%3DDouble+punctuation+for+vertical+text%7D%0D%0A%5Cp%7Bsubhead%3DArchaic+punctuation%7D+-+%5BU%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F%5D%0D%0AU%2B214B%5D&g=&i=> > ] > > The effect of that would be to make 1,628 characters no longer usable as > operators [list of non-operator characters > <http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%2F+%3D+%5C-+%2B+%21+*+%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%0D%0AU%2B00A1+-+U%2B00A7%0D%0AU%2B00A9+U%2B00AB+U%2B00AC+U%2B00AE%0D%0AU%2B00B0+-+U%2B00B1%0D%0AU%2B00B6+U%2B00BB+U%2B00BF+U%2B00D7+U%2B00F7%0D%0AU%2B2016+-+U%2B2017%0D%0AU%2B2020+-+U%2B2027%0D%0AU%2B2030+-+U%2B203E%0D%0AU%2B2041+-+U%2B2053%0D%0AU%2B2055+-+U%2B205E%0D%0AU%2B2190+-+U%2B23FF%0D%0AU%2B2500+-+U%2B2775%0D%0AU%2B2794+-+U%2B2BFF%0D%0AU%2B2E00+-+U%2B2E7F%0D%0AU%2B3001+-+U%2B3003%0D%0AU%2B3008+-+U%2B3030%5D%0D%0A%0D%0A-%5B%5B%3ASm%3A%5D%0D%0A-%5Cp%7BBlock%3DSuperscripts+And+Subscripts%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A-%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A-%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A-%5Cp%7BBlock%3DAlphabetic+Presentation+Forms%7D%0D%0A-%5Cp%7BBlock%3DSmall+Form+Variants%7D%0D%0A-%5Cp%7BBlock%3DHalfwidth+And+Fullwidth+Forms%7D%0D%0A-%5Cp%7BBlock%3DMathematical+Alphanumeric+Symbols%7D%0D%0A-%5Cp%7BBlock%3DArabic+Mathematical+Alphabetic+Symbols%7D%0D%0A-%5Cp%7Bsubhead%3DVariant+letterforms+and+symbols%7D%0D%0A-%5Cp%7Bsubhead%3DLetterlike+symbol%7D%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5B%2F+%3D+%5C-+%2B+%21+*+%25+%3C+%3E+%5C%26+%7C+%5C%5E+~+%3F%5D%0D%0A%5B%C2%A1+%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A6+%C2%A7+%C2%A9+%C2%AB+%C2%AC+%C2%AE+%C2%B0+%C2%B1+%C2%B6+%C2%BB+%C2%BF%5D+-+%5B%C2%A2+%C2%A3+%C2%A4+%C2%A5+%C2%A9+%C2%AE%5D%0D%0A%5Cp%7Bsubhead%3DGeneral+punctuation%7D+-+%5BU%2B203F+U%2B2040+U%2B2045+U%2B2046+U%2B2054%5D%0D%0A%5Cp%7Bsubhead%3DDouble+punctuation+for+vertical+text%7D%0D%0A%5Cp%7Bsubhead%3DArchaic+punctuation%7D+-+%5BU%2B2E31+U%2B2E33+U%2B2E34+U%2B2E3F%5D%0D%0AU%2B214B%5D&g=&i=> > ] > > However, my strategy was to be conservative in accepting operators. There > are several Unicode blocks which contain some additional characters which > we may want to have as operators [list of characters in those blocks > <http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A%5Cp%7BBlock%3DOptical+Character+Recognition%7D%0D%0A%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%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Symbols+And+Arrows%7D%0D%0A%5Cp%7BBlock%3DYijing+Hexagram+Symbols%7D%0D%0A%5Cp%7BBlock%3DMusical+Symbols%7D%0D%0A%5Cp%7BBlock%3DAncient+Greek+Musical+Notation%7D%0D%0A%5Cp%7BBlock%3DTai+Xuan+Jing+Symbols%7D%0D%0A%5Cp%7BBlock%3DMahjong+Tiles%7D%0D%0A%5Cp%7BBlock%3DDomino+Tiles%7D%0D%0A%5Cp%7BBlock%3DPlaying+Cards%7D%0D%0A%5Cp%7BBlock%3DOrnamental+Dingbats%7D%0D%0A%5Cp%7BBlock%3DAlchemical+Symbols%7D%0D%0A%5Cp%7BBlock%3DGeometric+Shapes+Extended%7D%0D%0A%5Cp%7BBlock%3DSupplemental+Arrows+C%7D%5D%0D%0A&g=&i=> > ] > > I did not include the backslash because I decided not to mess with the > choice of ASCII operators, however I do support making backslash an > operator. I am not sure about currency symbols. > > Nevin > > > On Sun, Feb 5, 2017 at 1:20 PM, Dave Abrahams via swift-evolution < > [email protected]> wrote: > > > on Sun Feb 05 2017, Nicolas Fezans <[email protected]> wrote: > > > Dear all, > > > > This is a rather simple proposal to add '\' (backslash character) as a > > valid operator-head in the swift grammar. > > > > One argument for it, is that there exist a backslash operator in the > > MATLAB/Scilab/Octave languages. In this languages A\B solves the linear > > system A*X = B for X (or the least square problem associated to it if the > > system of equations is overdetermined). I am doing some numerical > > computation in Swift and it would be nice to be able to declare the same > > operator name for this functionality. > > > > I might have missed some arguments for not adding them, but I seems to me > > that until now the \ character is only used inside of string literals. If > > that is the case, both uses should never generate a conflict or be > > ambiguous, isn't it? (String literals keep their interpretation of \ and > \ > > used otherwise within the swift code will be interpreted as an operator > or > > as the beginning of an operator) > > > > I am curious to see what will be the feedback on this. > > +1 if it doesn't clash with the grammar. > > -- > -Dave > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
