World: r3wp

Thanks

>> stack: []
== []
>> insert stack func [arg][]
== []
>> stack/1
** Script Error: 1 is missing its arg argument
** Near: stack/1
>> first stack
>> pick stack 1
>>

So you get that weird looking error message when using path notation.

How to remove once used word from system/words list? For example 
if I do>> load [my-word1 my-word2] << The words, are now in the system/words 
(find first system/words 'my-word1) Is it possible to remove them 
at this moment somehow (I know that it will be changed in R3)?

No.

volker is right, there's no way to remove words from system/words.

if you have a situation where f1:  does [  f2 f3 f4 ] .. where all 
f1 - f4 are functions, is there a way that f2 can cause a return 
to the calling function of f1.  Do I have to throw an error to do 
this?

Graham: I guess you mean something like: f1: func [[throw]] [f2].

(my TFUNC does this "more comfortably" and for REBOL3 a change in 
that direction is planned)

Ok.

How RETURN works in R2

let's define the following function:

g: func [f [any-function!]] [f [return 1] 2]

now we may test what happens for different argument functions we 
may supply:

>> g :do ; == 1
== 1
>> g func [blk] [do blk]
== 2
>> g func [[throw] blk] [do blk]
== 1

poll: do you find it acceptable that for some numbers load mold number 
is an error?

example ?

the maximal or minimal possible decimal! values cannot be load molded

(while they can be computed, if you know how)

(do you really want me to present a formula here?)

IMO it should be moldable

they are moldable, but you cannot load the result back

Are they valid values or not ?

they are valid

Then they should be loadable, shouldn't they ? There will inevitably 
be a case where they are needed in a program.

Are they molded differently somehow ?

OK, so they should be loadable too :)

every Decimal! is "molded differently" somehow, no decimal is "exactly 
molded", example: 0.1 is a decimal! , but because the decimal! values 
are IEEE754 binary floating point, 0.1 is represented as the nearest 
IEEE754 number, which is not 0.1, because IEEE754 cannot represent 
0.1 as you probably know

Oh, I see. So to make them loadable you would have to mold them with 
an identifier on the front, (eg.  0d0.1)

OK so minimal/maximal decimal! values can be molded as nearset loadable 
decimal! or not?

nearset=nearset

grr nearest :)

The problem is, that there is some "inaccuracy" involved and the 
inaccuracy is so high, that the molded maximum is higher than the 
IEEE754 maximum, i.e. it causes overflow

this means, that 0d0.1 does not help

That means the decimal! maximum needs to be pulled back to the highest 
value which does not cause a problem.

But I am still confused - how can it be: "decimal! values are IEEE754 
*binary* floating point"  ?  I thought decimal! where using decimal 
math ?

the solution is not that easy. The problem is, that if somebody gives 
a number that is higher than all representable numbers, the overflow 
*should* occur. so we may need higher accuracy instead

 I thought decimal! where using decimal math ?
 - my favourite example: 0.3 - 0.1 - 0.1 - 0.1

in decimal math the result is exactly zero as everybody knows

Of course, sorry - confused with deci!  ..... (Probably the first 
of many confusions...)

Let me read all that again...

Yes, makes sense now.

Ok, I suppose you asked this poll question because you are looking 
for a way for the highest decimal! to be load moldable and it looks 
difficult / problematic.

the problem lies in the accuracy - we would need at least 17 digits 
from mold to be able to load back

How many digits are molded now ?

15

Maybe MOLD can be more accurate, and FORM can be less accurate ?

The trouble is, that the 16-th and 17-th digits are a bit "nonsensical", 
but they are needed for this purpose

(and this exceptional behaviour can be only for this exceptional 
datatype ?)

yes

I'd rather have non-sensical digits than not quite orthogonal loading/molding.