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 "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}