<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 21, 2016 at 11:37 PM, Nevin Brackett-Rozinsky <span dir="ltr">&lt;<a href="mailto:nevin.brackettrozinsky@gmail.com" target="_blank">nevin.brackettrozinsky@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div>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).<br></div></span><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>The Unicode standard has a four well-established and general categories for symbols:<br></div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>Sc: Symbols, Currency</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Sk: Symbol, Modifier</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>Sm: Symbols, Math</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>So: Symbols, Other</div></div></div></blockquote><div><br></div>For our purposes these aren&#39;t a terribly helpful set of assignments. The assignments in some places were arbitrary between categories S and P, and the conceptual model used wasn&#39;t necessarily appropriate for programming purposes. It might be a good idea to start by reading Chapter 22 (<a href="http://www.unicode.org/versions/Unicode9.0.0/ch22.pdf">Symbols</a>) of the current Unicode standard.<div><br></div><div>It would be a mistake to equate symbol identifiers with operators (which are verbs). For example: my initial thought was to want to exclude the LetterLike symbols block, but once the notion of operator and symbol identifier are distinct it is no longer clear to me that this should be done. The more pertinent question would seem to be &quot;What kind of identifiers should Letterlike Symbols be?&quot; That seems to be driven more by whitespace considerations than anything else. If we want to be able to write something like</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>3*ℇ  // three times the Euler constant (U+2107)</div></blockquote><div><br></div><div>without white space, then we want ℇ to fall into normal identifiers. What we&#39;d ideally like to have is &quot;noun identifiers&quot; and &quot;verb identifiers&quot;, because this would correspond to the best white space outcome. Unfortunately that ship sailed well before FORTRAN was standardized, and the best we can do now is &quot;get it right enough&quot; and accept the need for white space when that can&#39;t be done adequately. The conceptual difficulty with defining symbol identifiers as nouns or verbs is that symbols in mathematical use are assigned to meanings arbitrarily on a case-by-case basis for the convenience of that individual paper. There really <i>isn&#39;t</i> a general consensus in mathematical symbols about what is a noun and what is a verb,. There <i>certainly</i> isn&#39;t a consensus for symbol identifiers involving more than one glyph; the style of formal mathematics favors single-letter variables in various scripts with decorative modifiers. For this reason, the best outcome we can achieve will be &quot;right enough&quot; rather than perfect, and white space will still be required in some cases.</div><div><br></div><div>I&#39;m coming around to the view that a new Unicode property is actually warranted, but that will take time. My reasoning in proposing that start with the Mathematical Operators block had four parts:<br></div><div><ol><li> It&#39;s enough to make forward progress<br></li><li>It allows most existing code to survive without breakage</li><li>All of the code points in that particular block are pretty clearly things that want to be in symbol identifier</li><li>It buys time for the Unicode group to negotiate the creation of a new property.</li></ol><div class="gmail_extra"><div class="gmail_quote"><div>If we really want a good, fine-grain organization of code points, we need to buy time for a property definition to happen over in Unicode-land, and we need to avoid stepping on future backward-compatibility issues while that happens. For this reason, I think we should be looking to define the smallest set of symbol identifier codepoints that we think we can live with for now given the current state of source code in the field. Everything we add poses a risk of future backwards compatibility concerns.</div><div><br></div><div>What <i>would</i> be useful would be to go through each of the blocks mentioned at the top of Chapter 22 of the standard, and characterize each one as &quot;mostly normal identifier&quot; or &quot;mostly symbol identifier&quot;. We can then go through and identify the exceptions in each block. We should <u>avoid</u> the Punctuation category and associated blocks at this time; category assignments in that space were pretty arbitrary, so those will take a fair bit of work to sort out.</div><div><br></div><div>Ideally, I&#39;d like to see all of Sc (currency symbols) end up in &quot;identifier symbols&quot; for consistency. The hold-out at the moment is &#39;$&#39;. As it turns out, we could probably get away with adding decimal digits to symbol-identifier-continue and then admit &#39;$&#39; in symbol identifiers rather than conventional identifiers without breaking existing code, but I&#39;m not sure this clean-up is worth the consternation and worry that it will cause.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>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.</div></div></div></blockquote><div><br></div><div>That is very much intentional. Our attention should <i>not</i> be restricted solely to operators. It&#39;s a general identifier space.</div><div><br></div><div><br></div><div>Jonathan</div></div></div></div></div>