A string is what Dan described in his various postings on strings. Nuff said.
Gerald Butler responds:
Yes, I know a "String" is what Dan described. He described a thingy made up of 32-bit Values where each value represented a "Code-Point". Now, we have people talking about doing "LSL/LSR" on "Strings". That is 100% inconsistent with that definition of a "String". In the hierarchy I proposed "TextString" is exactly what Dan said. Underlying "TextString" is "String" from which also derives "BinaryString" which has the behaviors and abilities such as "LSL/LSR".
Assuming I've an idea what's going on here (it's a bit difficult to tease this apart with the quoting--I do so hate outlook) you're both right, so if there's any shouting it ought be at me.
Parrot, at the very low levels, makes no distinction between strings and buffers--as far as it's concerned they're the same thing, and either can hang off an S register. (Ultimately, when *I* talk of strings I mean "A thing I can hang off an S register", though I'm in danger of turning into Humpty Dumpty here) That's part of the problem. There are already bitwise operations on S-register things in the core, which is OK.
The bitshift operations on S-register contents are valid, so long as the thing hanging off the register support it. Binary data ought allow this. Most 8-bit string encodings will have to support it whether it's a good idea or not, since you can do it now. If Jarkko tells me you can do bitwise operations with unicode text now in Perl 5, well... we'll support it there, too, though we shan't like it at all.
I *think* most of the variable-width encodings, and the character sets that sit on top of them, can reasonably forbid this.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
