chr and ord
Rod Adams
activities, but I'm not sure.
They likely need to be renamed, in any event, to better reflect the fact
that everything is Unicode these days.
-- Rod Adams
Larry Wall
: I'm thinking C<chr> and C<ord> should be strictly Code Point level
Alternately, since Num implies arbitrary precision, we *could* define
a value that can hold as many code points as you like, mod 2**32 or some
such. But I'm not sure either.
: They likely need to be renamed, in any event, to better reflect the fact
: that everything is Unicode these days.
And to reflect the fact that Unicode is many things these days.
Larry
Galion Public Library
> activities, but I'm not sure.
I'm thinking they might need to be able to operate at different levels.
It is, for
instance, not hard to think of situations where someone might want them
to
operate at the byte level.
> They likely need to be renamed, in any event, to better reflect the
fact
> that everything is Unicode these days.
It seems plausible that there might be different versions of ord,
depending on
whether you want the ordinal number of the first byte, the first
grapheme, or
whatever. The trick, to my way of thinking, is coming up with decent
names for
them. What we absolutely MUST NOT do is call them bord (for byte),
gord
(for grapheme), cord (for codepoint), and so forth. That would be evil
and
entirely too C-like. ordb, ordg, and so on would be almost as bad.
I wish I had a good set of names to propose. I don't, at this time.
$string.bytes[first].ord and $string.graphs[first].ord and so on has
clarity
going for it, but it feels way too verbose to me, and also it presumes
that
the elements of those tied arrays (or whatever they are) to know their
own
emantics for ord. The array itself obviously already has to know what
level
it's operating at, but now the elements have to know too. That
wouldn't
bother me if I liked the syntax, but as I said it's too verbose.
chr might be able to DWIM, unless I'm missing something.