World: r3wp

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

if they load at all ...

Geomol, re "I would prefer LOAD to always return a block" check out 
LOAD/all.

If a decimal changes by a LOAD FORM combo, isn't that a bug?
(I haven't found an example yet, that does what you claim.)

Andreas, I think, LOAD should with like LOAD/ALL in cases, where 
there is just one element.

with = work

See

http://www.rebol.net/wiki/Decimals-64

for more

If a decimal changes by a LOAD FORM combo, isn't that a bug?
 - it was intended

Oh, those border areas. That really really special cases not seen 
in real applications.

But, yeah, you're right in those special cases.

Many languages return inf in cases with math overflow. I would prefer

load mold 1.7976931348623157e308

to return [inf] instead of the now:

** Math error: math or number overflow

And that inf in the block should of course be of type decimal!.

That is a low-level aproach in REBOL interpreter, hidden by the error 
triggering code

And, I am content with the high level code taking care of exceptions

My FLATTEN function implementation is available at:

http://www.rebol.org/view-script.r?script=flatten.r

Guys, thanks for all the input. I didn't mean to cause this much 
excitement. :-) I just wanted to get my crazy DB program to work. 
And by the way, it does, at least so far.

James, it's usually interesting to explore the many corners of the 
language. Good you program work! That's important.

Thanks Geomol.

I sometimes wonder about having a NEXT that does not move to the 
tail, but only to the last element in cases where you always do a 
FIRST on the block afterwards to get the first element.

Then you don't need the trivial

unless tail? next blah [blah: next blah]

idiom.

In my opinion, the

    unless tail? next blah [blah: next blah]

should not be used at all. (I suppose, that it is in a cycle?)

more like list navigation, where one may move back and forth one 
item at a time, but never past the last item.

you can define it as a function, if you need it, but it probably 
never becomes a native

I would not think it would.

What if the block is empty? It should be possible to avoid the UNLESS 
... idiom, maybe by some careful coding.

In R2:

>> type? :sine
== native!
>> type? :sine/radians
** Script Error: sine expected value argument of type: number

In R3:

>> type? :sine
== native!
>> type? :sine/radians
== native!
>> do :sine 30
== 0.5
>> do :sine/radians 30
== 0.5			; Wrong result!?

Shouldn't things like :sine/radians just be invalid get-paths?

Think about passing :sine/radians as an argument to a function. So 
when using that argument in the function, the user would expect sine/radians 
to be calculated, but it doesn't, and it will be very difficult to 
implement that feature, if at all possible.

In R2:

>> type? first [:sine/radians]
== path!

in R3:

>> type? first [:sine/radians]
== get-path!

(R2 does not have get-paths)

Think about passing :sine/radians as an argument to a function.
 - you mean like this?

  type? first [:sine/radians]


? As far as I am concerned, I did not expect any additional evaluation

Aha, you probably meant that you did not like

    same? :sine :sine/radians ; == true

You can put that into CureCode as a wish, stating, that you prefer 
an error to be triggered instead

Today's Moment of REBOL Zen:

>> f: func [a op b] [a op b b]
>> f 1 quote / 2              
== 1

>> f: func [a op b] [op a b]  
>> f 1 quote / 2            
== 0.5

Note: That is in R2, where QUOTE word! doesn't work (known limitation). 
On R3, the / is not dereferenced.

Also, in R2 operators are evaluated by DO itself, which has a set 
of keywords that it transforms from operator to prefix function syntax. 
R3 does this swap by value, not by name, so operator renaming is 
possible. However, this leads to behavior like this:
>> f: func [a op b] [a op b b]
>> f 1 get quote / 2
== 2

>> f: func [a op b] [op a b]
>> f 1 get quote / 2
** Script error: op operator is missing an argument
** Where: f
** Near: f 1 get quote / 2


This is why, when you are accepting and calling function values, 
it's best to either limit yourself to the types of functions you 
are expecting, or use APPLY.
>> f: func [a op b] [apply :op [a b]]
>> f 1 get quote / 2
== 0.5
>> f 1 :divide 2
== 0.5

R2 has an APPLY too, in mezzanine but it works the same way. It was 
added for security and function wrappers.