World: r3wp

DELINE.

and to get it back we should use write enline output?

Yeah, except deline/lines and enline of block doesn't work yet (tickets 
#648 and #647, respectively).

Of course to get the text in the first place you need READ/text (ticket 
#622), or TO-STRING.

Paul, I am taking a look at a good suggestion for a function that 
is similar to one of your mezzanine proposals. Could you take a look?

http://curecode.org/rebol3/ticket.rsp?id=637

Sample usage:
>> any-of x [-1 4 10] [x > 0]
== 4
>> any-of [x y] [1 4 10 8 5 -3] [(x - 2) = y]
== [10 8]
>> all-of x [33 -1 24] [x > 0]
== none
>> all-of [x y] [1 2 3 4] [x < y]
== true

If we do these as mezzanine with the full R3 *EACH word and set-word 
syntax these become big functions, similar in scope to my R2-Forward 
MAP function. If we limit the words to the word! type it becomes 
much easier, but still with more overhead than ANY and ALL. I had 
put off working on these for months because I thought DO/next was 
needed to implement them, but I've just realized that it isn't.

I think they are great ideas.  A bit more extended then my any+ function.

Probably a bit more practical also.

Yeah, I really liked your ANY+, but it wasn't very REBOL-like. However, 
I couldn't come up with anything better. Then this guy did :)

For the second all-of example, 1 and 2 got checked, as did 3 and 
4, but did 2 and 3?  Same question to the second any-of example.

(Mostly curiosity, but with all-of, would be a simple way to see 
if data is already sorted)

If you provide multiple words, they get treated like a record, just 
like *EACH.

Ah, never noticed remove-each could do that, although I've used foreach 
that way

If you want to check for sorted, try this (if we support full *EACH 
syntax):
>> all-of [x y:] [1 2 3 4] [any [tail? y x < first y]]
== true

(Soon-to-be) MAP-EACH also supports the record and set-word tricks 
:)

Here's a better check for sorted:
>> all-of [x y:] [1 2 3 4] [x <= any [first y x]]
== true

I would change the any-of syntax up a bit myself.

any-of [x [1 2 3] y [4 5 6]][....]

That would require a REDUCE or DO/next to use referenced data, and 
this function is too inefficient to use with inline data, as compared 
to the ANY and ALL equivalent code. These functions would only be 
worth using for large datasets, or otherwise their overhead would 
be too much. That is the problem ANY+ had :(

The *EACH syntax is what makes these functions worth using, rather 
than refactoring away.

I'll grow my own as usual then.

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