On Fri, 2004-04-30 at 13:53, Dan Sugalski wrote: > 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.
Ahhh, now things are beginning to make a little more sense. Bear with me for a question or two more. > > 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. <mode="dave barry"> Since "text" "strings" are a proper "subset" of a "binary" "buffer", which is really what the "string" "registers" really "are", what we've "logically" got is this: </mode> LAYER 1 2 3 +-- Text Ops --- (Hosted Language) SREG --+ +-- Bin Ops --- (Hosted Language) or maybe this: SREG --- Bin Ops ----------- (Hosted Language) +-- Text Ops --- (Hosted Language) where semantics are found in Layers 2 and 3. (Layer 3 could also be merged.) Now I think that's more less what Parrot has, right? Except that the Layer 2 semantics are tracked (and locked in?) at Layer 1? (To prevent the aforementioned bit-shifting of WTF strings.) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)