At 11:42 AM 3/26/2001 -0600, Garrett Goebel wrote:
>From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> > At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> > > So the results of ord are dependent on a global setting for
> > > "current character set" or some such, not on the encoding
> > > of the string that is passed to it?
> >
> > Nope, ord is dependent on the string it gets, as those
> > strings know what their encoding is. chr is the one dependent
> > on the current default encoding.
>
>Are built-ins like chr going to be nailed to one encoding at compile time,
>or will we be able to toggle the default encoding setting at runtime?
I don't see any reason not to have the encoding lexically scoped and
settable via use. Probably either "use encoding qw(EBCDIC);" or "use
ebcdic;". The former would be easier to extend, but it's Larry's call.
>Besides having the ord opcode dispatched by the string tag, will it be
>possible to have the chr opcode dispatched by the type of return value
>wanted?
>
>$foo:ASCII = chr(65);
>@foo:ASCII = map chr($_), 80, 69, 82, 76;
>
>I assume internals-wise that this is similar to whether a function was
>called in a scalar, array, or void context... But further raises the spectar
>of multiple dispatch to include typing.
That's an interesting question, and it depends on how the chr operator's
defined. If it's done via the variable vtables it's sort of easy (sort of)
in some ways, and if not it's sort of easy in others.
There's no reason it can't be done, the question is whether it's useful
enough to justify the speed penalty.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
