<div dir="ltr">On Thu, Jan 12, 2012 at 19:38, Donn Cave <span dir="ltr"><<a href="mailto:donn@avvanta.com">donn@avvanta.com</a>></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">
<div class="im">>> > Seems obvious to me: on the one hand, there should be a plain-ASCII<br>
>> > version of any Unicode symbol; on the other, the ASCII version has<br>
>> > shortcomings the Unicode one doesn't (namely the existing conflict between<br>
>> > use as composition and use as module and now record qualifier). So, the<br>
>> > Unicode one requires support but avoids weird parse issues.<br>
>><br>
>> OK. To me, the first hand is all you need - if there should be a<br>
>> plain-ASCII version of any Unicode symbol anyway, then you can avoid<br>
>> some trouble by just recognizing that you don't need Unicode symbols<br>
>> (let alone with different parsing rules.)<br>
>><br>
><br>
> What? The weird parsing rules are part of the ASCII one; it's what the<br>
> Unicode is trying to *avoid*. We're just about out of ASCII, weird parsing<br>
> is going to be required at some point.<br>
<br>
</div>What what? Are you not proposing to allow both ways to write<br>
composition, "." and "<unicode symbol>" at the same time, but<br>
with different syntactical requirements? Unicode characters as<br>
code would be bad enough, but mixing them with a hodge-podge of<br>
ASCII aliases with different parsing rules isn't going to win<br>
any prizes for elegance.</blockquote><div><br></div><div>Backward compatibility is rarely elegant, and this is in any case piggybacking on already existing (indeed, longstanding) parser horkage. The point of the Unicode is a first step at getting away from said horkage, which hopefully can be completed someday.</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>