At 11:26 PM 3/23/2001 +0000, Dave Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> doodled:
> > At 11:09 PM 3/23/2001 +0000, Simon Cozens wrote:
> > >For instance, chr() will produce Unicode codepoints. But you can
> pretend that
> > >they're ASCII codepoints, it's only the EBCDIC folk that'll get hurt.
> I hope
> > >and suspect there'll be an equivalent of "use bytes" which makes chr(256)
> > >either blow up or wrap around.
> >
> > Actually no it won't. If the string you're doing a chr on is tagged as
> > EBCDIC, you'll get the EBCDIC value. Yes, it does mean that this:
> >
> > chr($foo) == chr($bar);
> >
> > could evaluate to false if one of the strings is EBCDIC and the other
> > isn't.
>
>Err, perhaps I'm being dumb here - but surely $foo and $bar arent
>typed strings, they're just numbers (or strings which match /^\d+$/) ???
D'oh! Too much blood in my caffeine stream. Yeah, I was thinking of ord.
chr will emit a character of the type appropriate to the current default
string context. The default context will probably be settable at compile
time, or be the platform native type, alterable somehow. Probably "use
blah;" but that's a language design issue. :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
