Dan Sugalski wrote:
>
> At 12:07 AM -0400 8/19/03, Benjamin Goldberg wrote:
> >There are a number of shortcomings in the API, which I'd like to address
> >here, and propose improvments for.
>
> You're conflating language level strings with low-level strings. Don't.
>
> STRINGs, the parrot structure and what S registers point to, are
> single-encoding, single-character set entities. They're designed for
> as fast access as feasable while maintaining the bare minimum of
> language/set/encoding abstraction. Parts of the core *will* assume
> they are concrete and, once transformed into a fixed-width format,
> can be accessed directly while avoiding all the overhead of the
> encoding (and even character set) functions.
>
> PMCs are full-blown language level variables that can do whatever the
> heck they want when accessed. Everything you do can be mediated by C,
> Parrot, or perl/python/ruby/scheme/forth/BASIC/whatever code. Lazy
> strings, multi-encoding strings, tree structures with strin reps,
> whiatever.
>
> Most, nearly all, high-level language level functionality should use
> PMCs. If a STRING is insufficiently flexible for what you want,
> that's a sign you shouldn't use it.
Ok, I'm convinced.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
