On Tue, 2005-04-12 at 07:42, David Cantrell wrote: > > You might argue that Language::Dutch should never ship with the core... > > that's a valid opinion, but SOMEONE is going to write it. It'd be a kind > > of strange form of censorship for CPAN not to accept it. After all, > > there's more than one way to say it... isn't there? > > While it may be possible to do it, and while it may be an interesting > exercise to implement it, that doesn't mean that anyone *using* it for > anything other than a joke isn't a blithering idiot.
We're all programmers (I assume), and we've all come across environments where programming tools that seemed useless or silly in one environment were critical in another. The education example I gave is an ideal one, but there are dozens of others from any number of fields. Perl 6 offers us the opportunity to create true dialects, and dialects are valuable things. I don't recommend that everyone rush in and use such a module, but it has its value. > > > I'm not even sure I like the *possibility* of using non-ascii letters in > > > identifiers, even. > > I think we already have Latin-1 in identifiers... > > more's the pity. This is just ASCII prejudice (which seems strange, as your domain implies you're not here in the US where such prejudice is usually assumed). There's nothing fundamentally wrong with having $Ãther as a variable name, other than the fact that most Americans are confused by it because they think "Ã" and "ae" are identical. They're wrong. We've already deeply embraced the Latin-1 character set for many purposes in Perl 6. I *would* however, have a "use warning <unicode>" type of thing which would warn on the use of any Unicode character in an identifier whose standard display form is difficult to distinguish from some more commonly used character's display form. For example, "Æ" is just a bit too close to "b", so you might want to warn the user unless their default locale was one where it's commonly used, or at least provide a facility for requesting such warnings. > > Let's see about UTF-8.... > > pugs> my $??? = 1; > > undef > > pugs> $???; > > 1 > > I see a sequence of three question marks, there's no funny foreign > characters there. I have to confess to being surprised that $??? is > legal. That's either a bug in your mailer (or possibly something that tried to re-encode your mail for you) or the fact that you're using some ancient output device that doesn't grok Unicode character sequences. It's refusing to display perfectly valid "Content-Type: text/plain; charset=UTF-8" mail in "Content-Transfer-Encoding: quoted-printable" correctly. It should render "pugs> my $=E0=BA=81 =3D 1;" as the appropriate Unicode sequence. Certainly we've already stated that the default encoding of Perl 6 programs will be UTF-8, and that means that such sequences are valid, and all editors I know of handle these sequences correctly (Emacs, vim, eclipse, etc.) I don't see why stopping someone in Russia from writing code in their native syllabary is wrong... after all, they're probably not going to use ASCII to represent words that I can read anyway... they're going to use ASCII to write a romanized form of their own language. Restrictions on style should be performed at a higher level. For example the new CPAN for Perl 6 might have some qualifiers that you can attach to your programs that describe character set used and other stylistic conventions. That way, I might choose to look for only modules that are written in a language that I feel comfortable maintaining. Then again, I might not care, and just install whatever works. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
