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)
