World: r3wp

Didn't you do so already?

Indeed.

** Hint
Currently there is problem to complement charsets in R3.

To have 256 values in the complement (like in R2), I add the char 
#"^(FF) in the charset:
c: complement charset "0123456789^(FF)"


But it's not exactly the same thing (cause the value 255 is not allowed 
in the complement).

Have you any idea to have the "exact" complement (without using a 
nasty loop to construct the bitset!) ?

I mean, instead of adding 255 in the initial charset, i should add 
256, but i got a curious result doing that.
So i may doing it bad.

Complement charsets is almost completely broken in R3, mostly because 
a full complement of a charset would overwhelm your memory - about 
512 megs each. This has been a known problem since last fall, and 
was the initiial reason for the Parse Proposals.

well, you didn't read what i've said, because i show a temporary 
solution

to fit the R2 behavior

Use INSERT on the result:
>> insert insert complement charset "^(00)0123456789^(FF)" 0 255

== make bitset! #{FFFFFFFFFFFF003FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF}

You forgot the ^(00) at the front.

Fine, exactly what i wanted to get, thanks

we can't add 256 directly in the intial charset, i guess, anyway 
it's a clever solution.

The complement charset problem is also the inspiration for the FIND/not 
proposal.

Hmmm, no need to add the char #"(00)", it seems...

btw. is there a reason why we can use 'unique on a bitset?

yep, they don't want bitsets acting like true series

Completeness, and to reduce special-casing code.

hmm ok :-)

Wait a minute... UNIQUE on a bitset! means nothing, they already 
contain unique values

Yup, it's a noop. It was deemed more important to eliminate all potential 
test-to-see-if-something-is-a-bitset-and-not-call-unique code.

We're trying to make the functions more polymorphic in R3, to reduce 
special-case code.

Where it makes sense, of course (meaning: we can come up with a rationale).

For example, SELECT and APPEND also work on objects and maps, and 
the set functions also work on typesets.

Steeve, this works too: insert complement charset "^(00)0123456789^(FF)" 
[0 255]

no need for ^(00)

same result with:
insert complement charset "0123456789^(FF)" 255

Interesting. I wondered how the sparse charsets were handled - Carl 
had implied that they were offset (I probably misunderstood).

For 2.7.6.3.1:
Total: 3028 Succeeded: 2959 Failed: 69

For 2.100.55.3.1:
Total: 3155 Succeeded: 3110 Failed: 45

Taking into account that R3 implements more features (more datatypes 
e.g.), I would say, that it already succeeded to "surpass" R2 in 
its core functionality.

(the above are test results)

Is this with Carl's test suite or your own?

it is a test suite I wrote for Carl

(some time ago)

Ladislav, does it look like we can get going with Carl's test suite 
again? Have you studied it?

Carl gave me some requirements how a test suite should work and I 
wrote my implementation of his spec. Carl looked at it and he probably 
felt it was more complicated than what he liked. OTOH, the main difference 
was, that my test suite tries to give useful informations always 
when it is possible and continue with testing.

I think his desire was that most people could write their own tests.

So, it generally doesn't "choke", when encountering "runaway return", 
"runaway throw", "runaway break", etc.

most people could write their own tests
 - yes, that is fulfilled, the test are according to Carl's spec

Did you write the suite before he added the *-of functions? I remember 
he did a lot of work on those right when he wrote his own test suite.

(a block of code, that should evaluate true)

yes, I wrote it before he wrote the reflector functions, so it does 
not contain sufficiently many tests of these

maybe that's the complexity issue, he's talking about, or was the 
discussion recent?

another spec: the tests can be preceded by #issue modifiers, like 
#r3only, meaning, the test is meant just for the r3 interpreter

or #r2only meaning the opposite

is it possible to compile comparison lists?

complexity issue: if you mean the possibility to write tests that 
would check every possible aspect of the functionality, than that 
is probably impossible

compile comparison lists - you mean to compare different interpreter 
versions?

comparison: yes. this would not only be useful during tests, but 
for documentation for users to study legitimate differences in behavior 
between R2 and R3.

when comparing two interpreters, I can generally run all the non-crashing 
tests by both interpreters (a crashing test is a problem, since it 
stops the testing process) and show the differences

of course, this may mean to run R2-specific test by the R3 interpreter 
or vice versa, which may well look crazy, but it is doable

(since the majority of tests is common for all interpreters)