World: r3wp

>> 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.

As to why decimals are affected, they simply are, and your example 
does not prove the contrary.

Regarding the usefulness:


- one problem is that it is useful only in special cases as Sunanda 
mentioned

- another problem is that this approach is circumventing the proper 
approach, hiding the fact, that it is not recommended
- last but not least, this approach is inefficient

One more note: there is a FLATTEN function definition somewhere, 
which was defined some time ago to be used to flatten hierarchical 
blocks. It should be possible to find it here, but, since it was 
long time ago, I will try to find my version and put it to rebol.org 
or somewhere to make it more available.

Decimals are discussed in the DocBase (Geomol beinng a coeditor of 
the article), and, for the interested, it should not be a problem 
to find relevant informations in there.

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


Yeah, that's a pity, I think. I would prefer LOAD to always return 
a block, so the result from LOAD could always be sent to e.g. PARSE. 
I guess, it's made this way to kinda let LOAD and SAVE reflect each 
other. But that doesn't quite make sense, as we can't save to a string. 
And LOAD can load an empty file giving an empty block, while we can't 
save an empty file with SAVE, afaik.

Example of what I find a bit strange:

>> load ""
== []
>> load "1"
== 1
>> load "1 2"
== [1 2]

Regarding decimals in blocks, are you saying, that if I have a block 
with a decimal, then the decimal can be different after going through 
a LOAD FORM combo?

yes