On May 7, 2004, at 11:48 AM, chromatic wrote:
On Fri, 2004-05-07 at 11:13, Leopold Toetsch wrote:
Larry Wall <[EMAIL PROTECTED]> wrote:
[I'm assuming that these internal signatures contain actual type
No. They are really internal, denoting C data types: 'i' => int, 'd' =>
double and so on. These signature just happen to live in STRINGs so that
we can pass them around e.g. to VTABLEs.
I don't see a problem here, but just to be sure -- if Perl 6 makes NCI visible so that Perl 6 programs can specify these signatures, will assuming that they're always ASCII strings be a problem?
I wouldn't think it would be a problem--this is just an arbitrary notation for the C data types, and doesn't involve the function names themselves (or user-defined types). I wouldn't think we'd expose this directly at the Perl6 level--or if we did, it might go through a translation layer, or a more explicit API. But having non-ASCII identifiers in Perl shouldn't matter--the function names aren't involved, but if they were, they'd be the _C_ function names, which would be restricted to ASCII[*] anyway. So I think we're okay.
[*] At the moment at least, string_from_cstring() uses ISO-8859-1, since it's cheaper than specifying ASCII (which technically should check that there are no code points > 127 involved). But we could at some point get rid of string_from_cstring--it's just a one-statement convenience method--in order to be more explicit. But (currently), in the case where you know your string is going to be all ASCII (eg, in the literal-in-Parrot-source case), it's a performance benefit to specify ISO-8859-1 rather than UTF-8, since in the latter case we need to run through and check that it's valid UTF-8.
JEff
