On Sun, Apr 11, 2010 at 03:47:18PM -0700, Darren Duncan wrote: : Damian Conway wrote: : >The relevant suggestion regarding hyphens vs underscores is: : > : > "...to allow both characters, but have them mean the same thing." : > : >That is, any isolated internal underscore can be replaced with an : >isolated internal hyphen (and vice versa), without changing the meaning : >of the identifier. : : I am formally opposed to this idea. I see that making underscores : and hyphens to be equivalent is akin to having case-insensitive : identifiers, where "Perl","PERL","perl" mean the same thing. Rather : what I want is to be everything-sensitive, as AFAIK Perl 6 currently : is; if something looks different, it is different. -- Darren Duncan
Well, Perl 6 won't be everything-sensitive, since by default it does string comparisons under some kind of Unicodian Normalization. But I'm inclined to keep - and _ as unique characters, and just let the culture evolve over time; I think the end result will be to require (by convention) official APIs to use hyphens for all normal interfaces; underscores anywhere in a name will come to mean "this is private, use at your own risk" regardless of where underscores are used, much like current meaning of leading underscores. But I don't think it should be anything tighter than a convention, or we make language interoperability more difficult (particularly with Perl 5). As for the horror of people having to memorize lists again or Risk Using The Wrong Character...I'm afraid I just don't buy it. The standard parser will likely be pointing out spelling errors and conjecturing emendations for near misses. Whole-program analysis can even do this for any method names that look wrongish. The difference between Acme-X and Acme_X is no worse than the difference between Damian and Damien, at least in Levenshtein distance. Larry
