World: r3wp

I wasn't joking about the "a valuable debugging aid" comment. That's 
a deal-killer for me.

What exactly does this mean:

>> a: make bitset! [#"-" - #"+"]
** Script Error: Out of range or past end
** Near: a: make bitset! [#"-" - #"+"]

>> make bitset! [ #"+" - #"-" ]
== make bitset! #{
0000000000380000000000000000000000000000000000000000000000000000
}

bitset likes its args in ascending order (but Graham beat me to it)

that seems a bit impractical, but I guess it could complicate the 
function to have both ways.

Is there a simple way to transform a block of blocks into a single 
block and maintain their types? As follows:
a: [  [1] [2] [3] ]
Changing that to
b: [  1 2 3 ]

You know, outside of looping thru each value and building a new block 
(which I don't mind doing but if there was some simple way)

Only one level, or all the way?

Also, in-place or as a copy?

>> a: [[1][2][3][[4]]]
== [[1] [2] [3] [[4]]]

One level:

>> b: copy a while [not tail? b] [either block? first b [b: change 
b first b] [++ b]] b: head b
== [1 2 3 [4]]

All levels (not cyclic reference safe):

>> b: copy a while [not tail? b] [either block? first b [change b 
first b] [++ b]] b: head b
== [1 2 3 4]

ChristianE's ODBC extension for R3 includes a native FLATTEN command, 
but I haven't tested whether or not it manages memory properly, and 
it doesn't help R2, or R3 not on Windows.

Using R3 PARSE:
>> b: copy a parse b [any [change [set x block!] x | skip]] b
== [1 2 3 [4]]

>> b: copy a parse b [while [and change [set x block!] x | skip]] 
b
== [1 2 3 4]

Or simpler:
>> parse copy a [return while [change [set x block!] x | skip]]
== [1 2 3 [4]]

>> parse copy a [return while [and change [set x block!] x | skip]]
== [1 2 3 4]

For some types of data (not embedded objects)
    to-block form [ .... ]

in-place:
forall a [change a first a]

copying:
collect [foreach x a [keep x]]

Andreas, FORALL won't work here:
>> a: [[1] [2] [3 [4]] [[5]]] forall a [change a first a] a
== [1 2 3 4]


If it's shallow, it should be [1 2 3 [4] [5]], if deep it should 
be [1 2 3 4 5].

Sure, neither will it work in n other arbitrarily constructed border 
cases :)

The PARSE and WHILE versions above will work in all cases where you 
don't run out of memory, and for the deep versions when there are 
no cyclic references.

>> parse [[1] [2] [3 [4]] [[5]]] [return while [change [set x block!] 
x | skip]]
== [1 2 3 [4] [5]]

>> parse [[1] [2] [3 [4]] [[5]]] [return while [and change [set x 
block!] x | skip]]
== [1 2 3 4 5]

For the common flatten use-case of regular one-level nested blocks, 
it's fine. If that's not what you need, no warranties :)

The FORALL version won't work if the embedded blocks have more than 
one element in them.

That is the common case :)

True.

It's a little better if you do this, but still not quite right:

>> a: [[1] 2 [[3] [4]] [[5]]] forall a [change/part a first a 1] 
a
== [1 2 [3] 4 [5]]  ; should be [1 2 [3] [4] [5]]

The WHILE trick above needs the same CHANGE/part (whoops):

>> b: [[1] 2 [[3] [4]] [[5]]] while [not tail? b] [either block? 
first b [b: change/part b first b 1] [++ b]] b: head b
== [1 2 [3] [4] [5]]

>> b: [[1] 2 [[3] [4]] [[5]]] while [not tail? b] [either block? 
first b [change/part b first b 1] [++ b]] b: head b
== [1 2 3 4 5]

Overall, I have to say I prefer the R3 PARSE version.

Gentlemen, thank you. I will study your methods. It is just one level 
and it was to handle indexes I was receiving from a mysql db that 
were returned as [ [1] [2][ 3]]. Again thank you. You guys sure know 
your stuff!

If you are copying from fixed records (as from DB results), Andreas's 
COLLECT version will use the least memory because you can preallocate:

>> a: [[1 2] [3 4] [5 6]] head collect/into [foreach x a [keep x]] 
make block! 2 * length? a
== [1 2 3 4 5 6]

Brian, that reminds me. The ++ is something I have never seen before 
and it doesn't show up in the "dictionary" which is what I normally 
depend on for info. Is there some doc or source of info you recommend?
Thanks.

HELP ++, or SOURCE ++ on R2.

I mean even knowing that it exists.

collect ....Another one that is not in the dictionary

Interesting.

Right, I forgot about that. There's a -- too, and other new functions 
like FIRST+ and TAKE. I tend to just do WORDS-OF lib in R3 and go 
from there. Most of the new functions in R2 in the last several years 
are backports from R3.

Ah, that makes sense. I was just looking at R3 Collect.

Very cool thanks.

R2's COLLECT is pretty similar. The backports try to be as compatible 
with R3 as is practical in R2, though is a couple cases they are 
a bit ahead of their R3 versions, where there are some tickets that 
haven't gone through yet. In particular ENLINE/with, DELINE block!, 
and MAP-EACH/into come to mind.

is -> in

Yet an alternative:

>> load form [[1][2][3]]
== [1 2 3]

Please, do not publish such solutions, they are not recommended in 
the documentation

? Are you joking?

No, that is serious

Will you please point to that documentation?

Do not forget, that you destroy such properties as binding, etc.

My solution works perfectly in this example, and don't tell me what 
to do or not to do.

OK, do whatever you want. I am changin my recommendation to: readers 
of the above, please do not use such code. Other affected datatypes 
are:

- decimals, functions, objects, ....

(and my list isn't complete)

As for the documentation, i.e. where exactly it is mentioned that 
this approach is not recommeded. Unfortunately, I forgot, where exactly 
it was. Nevertheless, the reasons are clear, I hope.

In general, Carl wrote REBOL to be its own metalanguage, especially 
to be able to manipulate blocks and their contents accurately. Solutions 
like the above are necessary only in languages, that do not have 
such abilities.

Why shouldn't decimals work?

>> b: load form [[1.5] [2.5]]
== [1.5 2.5]
>> type? b/1
== decimal!

another example, which does not work:

type? load form [1] ; == integer! (i.e. not block!)

I suggested the same approach, geomol. I added a caveat that it works 
for some datatypes, not others. It is particularly bad for objects:
    load form reduce [make object! [a: 1]]
So, a useful approach if we are mindful of its limitations.