Ok, I'm still lost on the language thing. I'm not arguing, I just don't get it, and I feel that if I'm going to do some of the things that I want to for Perl 6, I'm going to have to get it.
On Mon, 2004-04-12 at 11:43, Dan Sugalski wrote:
Language ======== *) Provides language-sensitive manipulation of characters (case mangling) *) Provides language-sensitive comparisons
Those two things do not seem to me to need language-specific strings at all. They certainly need to understand the language in which they are operating (avoiding the use of the word locale here, as per Larry's concerns), but why does the language of origin of the string matter?
Because the way a string is upcased/downcased/titlecased depends on the language the string came from. The treatment of accents and a number of specific character sequences depends on the language the string came from. Ignore it and, well, you're going to find that you're messing up the display of someone's name. That strikes me as rather rude.
You also don't always have the means of determining what's right. It's particularly true of library code.
For example, in Perl5/Ponie:
@names=<NAMES>; print "Phone Book: ", sort(@names), "\n";
In this example, I don't see why I would care that NAMES might be a pseudo-handle that iterates over several databases, and returns strings in the 7 different languages that those databases happen to contain.
Then *you* don't. That's fine. Why, though, do you assume that *nobody* will? That's the point.
You may decide that all strings shall be treated as if they were in character set X, and language Y, whatever that is. Fine. You may decide that the language you're designing will treat all strings as if they're in character set X and language Y. That's fine too. Parrot must support the capability of forcing the decision, and we will.
What I don't want to do is *force* uniformity. Some of us do care. If we do it the way I want, then we can ultimately both do what we want. If we do it the way you want, though, we can't--I'm screwed since the data is just not there and can't *be* there.
We've tried the whole monoculture thing before. That didn't work with ASCII, EBCDIC, any of the Latin-x, ISO-whatever, and it's not working for a lot of folks with Unicode. (Granted, only a couple of billion, so it's not *that* big a deal...) We've also tried the whole global setting thing, and if you think that worked I dare you to walk up to Jarkko and whisper "Locale" in his ear.
If you want to force a simplified view of things as either an app programmer or language designer, well, great. I am OK with that. More than OK, really, and I do understand the desire. What I'm not OK with is mandating that simplified view on everyone.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
