World: r3wp

Mezzanine example:


>> my-next: func [series] [either word? series [set series next get 
series] [next series]]
>> my-next [a b c]
== [b c]
>> block: [a b c]
== [a b c]
>> my-next 'block
== [b c]
>> block
== [b c]

Anyway, it does not look like a best idea to me. Besides, in the 
case of ++ a new (special) function with a different argument passing 
convention was defined

We talked about to change the value of non-series values by this 
way:
>> a: 5
>> multiply 'a 5
>> ? a
== 25


But ofcourse we are not sure about performance overhead or possible 
other problems.

I've been thinking about this before, and there was a discussion 
on Carl's blog long time ago. It came to me again, when I looked 
at LOWERCASE and UPPERCASE. They work on strings, and does change 
the sting. But many functions work on string without changing them. 
That's a bit odd, or maybe difficult for new users to understand.

I think, the ideas can be seen as: like other languages have call-by-value 
and call-by-reference (maybe using pointers as in C), REBOL could 
have call-by-value and call-by-word, both working with the same functions, 
as it's all by value, but we just give the word (REBOL's kind of 
reference) as an argument.

Leading to shorter notation and most likely also faster evaluation. 
I can't see any problem yet, but maybe there is!?

we are not sure about performance overhead
 - there are greater concerns than just performance here

Then we would have one more class of arguments that we need to treat 
carefully, rather than trusting the type checking to do it for us. 
This is similar to the none propagation problem.

Well, REBOL already has double type checking:

>> 4 > 2
== true
>> [4] > [2]
== true
>> [4] > 2
** Script Error: Expected one of: block! - not: integer!

For all those series functions that are non-modifying, except for 
ports, all we have to do to use them safely is to avoid putting ports 
in our data. This isn't usually a problem because it's rare to put 
ports in data; but words, on the other hand, are really common in 
data. This would make a misplaced word in your data not only not 
caught, but also *modified*. That is really bad.

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