<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 2, 2016 at 1:26 PM, Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":hu" class="a3s" style="overflow:hidden">I want to also voice my support for Unicode support.<br>
<br>
I don't know why everytime unicode is brought up in this mailing list a bunch of people suddenly fear having to edit code in a language they don't understand.  This has been possible already for a long time (as pointed out by the list of languages José added there). I think last time someone was being preemptively angry because they could be buying a business where code was in a different language and then they would be screwed! The horror.</div></blockquote></div><br></div><div class="gmail_extra">I'm in favor of Unicode support for atoms as well as a generic construction. Squint your eyes enough and an atom() is merely a string literal of a specific kind. It makes sense to allow these to vary inside the Unicode world.<br><br></div><div class="gmail_extra">When used as an "identifier" it may be necessary to define certain restrictions as to what symbol is allowed. The Go language defines that an identifier must start with either '_' or a Unicode symbol from the Letter class in order to avoid certain notational headaches such as the symbol '123' which cannot be written as 123 in Erlang either. In go, you could write _123, but that will get through the erlang parser: it is a variable since it starts with the wildcard character.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">There are some places where notation can help a lot. When transcribing math algorithms, it is often more readable to use the symbols used in the mathematical text directly in the source code as binding values. And the above remarks also suggest it is better to give the programmer the freedom to choose here, rather than restricting what the user can do.<br><br></div><div class="gmail_extra">Syntax is nothing, semantics is everything :)<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">J.</div>
</div></div>