Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
Not used *yet* - what about:
use German; print uc("i"); use Turkish; print uc("i");
That is implementable (and already implemented by ICU) but by something
higher level than a "string".
So the first question is: Where is this higher level? Isn't Parrot responsible for providing that? The old string type did have the relevant information at least.
See my separate post--what's needed is a locale parameter to uc(), giving uc("i", locale). For Parrot, we at least need ops/API which take an explicit locale parameter. The interoperability issue comes into play in whether we decide to let a default locale be specified at the parrot level, and have op variants which use this. I think that we actually don't need that, and that we can let it mostly happen at the HLL level--that is, of Perl6 (etc.) want API such as uc() without an explicit parameter, it just needs to compile 'print uc("i")' down to:
set S0, "i" find_global P1, "default_locale" # some agreed-upon global uc S1, S0, P1 print S1
So parrot can support a default locale cross-language, without needing separate ops or anything. And if, for instance, Python didn't have a default locale, and always make you pass a locale into operations which need one, then everything would still be fine--just Python wouldn't be looking up this particular global.
I think we can't say it's a Perl6 lib problem. HLL interoperability
comes in here too. *If* there are some more advanced string levels above
Parrot strings, they have to play together too.
So let's first concentrate on this issue. The rest is more or less an implementation detail.
JEff
