On Thu, Oct 20, 2005 at 04:23:44PM -0600, Luke Palmer wrote: > On 10/20/05, Steve Peters <[EMAIL PROTECTED]> wrote: > > Like the old joke goes "Doctor, Doctor, it hurts when I try to type a > > Latin-1 > > character." "So don't try to type Latin-1 characters!" Instead, many > > programmers will to use the ASCII equivolents that will require additional > > keystrokes. > > You mean additional keystroke. We haven't yet developed any ASCII > equivalent that takes more than two characters. For most cases, the > ASCII equivalents are easier to type than the Latin-1 versions. > However, being a Perl 6 programmer myself, I still use the Latin-1 > versions because I like how they look and feel better. But nobody is > forcing you to do the same.
But I may have to support your code. That's the issue. > > The one thing you have to worry about is if you use an editor that > doesn't support Latin-1 to read somebody else's code. However, many > many popular editors are capable of doing this, and any editor that > doesn't probably will soon. We've been over this and over this. I'd say a lot more editors support ASCII than Latin-1. Also, you are also assuming that programmers have control over what tools they have available, and have the ability to upgrade whenever they wish. I've found this to be very far from reality. I understand that the ability to process the code as Unicode is an important feature of Perl 6. There is a big difference between allowing it and requiring it. Writing off a large number of editors, and even operating systems, seems like a big shot in the foot. My biggest concern, however, relates to advocacy. There will need to be books, magazine articles, tutorials, etc. written to announce the arrival of Perl 6. If the code uses Latin-1 characters, and people are unable to look at the example code in their favorite editor or type in some of the example code, we'll lose that person to Perl 6. The other alternative is to preface every article with the explanation of the separate ASCII/Latin-1 sigils. That doesn't sound practical, and cannot be policed or enforced. > > Also, don't think of the class sigil as a sigil. You won't be writing > it very often. Just think of it as an operator. > > My final point: we don't introduce unicode characters lightly. We do > so when we think it is the best symbol for the job, optimizing, for > once, for readability rather than writability. As you mentioned above, readibility is a big issue. If I can't tell one sigil from another, or cannot even see it, how can I support the code? > If you don't think the > class sigil should be a unicode character, come up with a better one. > We're not going to say "You're right, Steve. No more unicode sigils!" > until wee see a good alternative to the unicode sigil that we have. ~ seems to be available for a sigil, if my reading of S02 is correct, and the cent sign is replacing :: in all cases. If not (that is $::foo is still the global variable named foo) then * may also be available. Steve Peters [EMAIL PROTECTED]
