<div dir="ltr">On Thu, Jan 12, 2012 at 17:33, Donn Cave <span dir="ltr">&lt;<a href="mailto:donn@avvanta.com">donn@avvanta.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Quoth Brandon Allbery &lt;<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>&gt;,<br>
<div class="im">&gt; On Thu, Jan 12, 2012 at 17:14, Donn Cave &lt;<a href="mailto:donn@avvanta.com">donn@avvanta.com</a>&gt; wrote:<br>&gt;&gt; &quot;Spaces or unicode&quot; would be the worst idea yet, but hopefully that<br>

&gt;&gt; isn&#39;t what you meant.<br>
&gt;<br>&gt; Thing is, I think the spaces idea is considered acceptable because it&#39;s<br>
&gt; *already there*.  Take a look at how GHC decides whether (.) is the<br>
&gt; composition operator or a module qualification.<br>
<br>
</div>... what is the rationale for an additional unicode dot?<br>
<br>
That&#39;s why I more or less assume that wasn&#39;t what he meant, that<br>
both &quot; . &quot; and &quot;&lt;unicode dot&gt;&quot; would be supported at the same time<br>
for composition, but rather just that one or the other would be<br>
chosen.</blockquote><div><br></div><div>Seems obvious to me:  on the one hand, there should be a plain-ASCII version of any Unicode symbol; on the other, the ASCII version has shortcomings the Unicode one doesn&#39;t (namely the existing conflict between use as composition and use as module and now record qualifier).  So, the Unicode one requires support but avoids weird parse issues.</div>
</div><div><br></div>-- <br>brandon s allbery                                      <a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a><br>wandering unix systems administrator (available)     (412) 475-9364 vm/sms<br>
<br>
</div>