>- Open Your Mind -<
Just wanted to warn...
Character-based arithmetics can be deceiving. Consider the following
>> for c #"^(00)" #"^(ff)" 1 [prin [c]]
which goes on forever (on REBOL/Core 2.3.0.1.1). Investigating for's source, I found
out the advancing instruction
start: start + bump
where 'start represents a char!, while 'bump represents the integer! 1; and the
while-test
while [op end start]
where 'op represents :greater-or-equal?, 'end represents #"^(ff)" and start steps up
one by one starting from #"^(00)". Now, when 'start gets to the 255th character, we
have a wraparound:
>> #"^(ff)" + 1
== #"^@"
and when the while-test comes, it is equivalent to
>> greater-or-equal? #"^(ff)" #"^(00)"
== true
and here we go again! :-)
Be my guest (-:, have a few other examples:
>> #"^(ff)" + 67
== #"B"
>> #"h" - 255
== #"i"
>> #"h" - 256
== #"h"
>> #"h" - 257
== #"g"
So, stay alert whenever you do maths on char! data, *especially* when nearing
boundaries.
Moreover, since the for function explicitly accepts char! values, and since it
internally treats series in a special way separated from all other datatypes, I'd like
to see it modified so that it treats the char! case in its own special way as well.
I've thought of at least three different methods to take care of this, involving
bitsets, strings or integers, but, though I definitely prefer the integer! way for
elegance, I can't say which one is faster: if there's one thing I've learned about
speed tests on the Amiga version of REBOL is that they don't correspond on the other
versions... :-)
Of course, I'm sending this message to feedback, too... but I'm almost sure it's going
to bounce back. :-(
Alessandro Pini ([EMAIL PROTECTED])
"I'm going in!" BOING! "Then again, maybe not!" (Paris)
