World: r3wp

Unfortunately, we currently don't have a non-binary alternative floating 
point type.

But that seems to me what we really want; to supplant decimal! with 
deci!  (Anyone disagree ?)

What I'm trying to say is: I would be happy for the current molding 
of decimal! to remain as it is, if I had a deci! type that I could 
use instead.

You have always inaccuracies in theory. In practice all have IEEE, 
but in theory its what the c-compiler uses. If some software-emulation 
thinks something else works faster, sending data there is anaccurate.

LAdislav: Fix the console. Or at least a check 'reloadable? , which 
as meazzine molds, loads and checks for equality, and without to 
much overhead.

Fix the console
 - how would you like it to be fixed?

Good question. First thought was: report error. Second thought an 
option to mold, mold/always, and console uses that.

default should be "better error than sorry" for 'save-related things 
IMHO, a dont-bother option would be ok.

I am very sensitive with save since people learn "save often" to 
keep their data, well, safe. Calling something "save" which breaks 
happily data was totally unexpected to me when i started (in the 
times when even a "}" in a string meant trouble, much bette rnow)

It's probably just me but what is the deal with command line arguments 
via system/script/args, I can't seem to get anything returned except 
none.

I wrote this a long time ago, but it should still be useful:

prin "args: "
probe any [
    system/options/args  ; this is available in user.r

    to-block system/script/args ; system/script/args is only available 
    after user.r, when script is done
]

Anton, thanks. I get it. You have to "turn on" the feature then use 
system/script/args with a "do/args script.r"   Thanks.

Very good.

If rebol used unicode for source code the problem with deci! could 
be address in the same way that plt-scheme does. That is they just 
have exact and inexact numbers. Exact numbers print all digits up 
to the precision in a normal way. Inexact values print the number 
and the last digit has a dash on top. Operations of exact with inexact 
yield inexact. If the programer wants to warrant exactness he converst 
from inexact to exact, which just means removing a flag and assumming 
the number is exact to the number of digits given.

I know that due to efficient represeantion of values with 16bytes 
gives a constraint. But it would be really cool if rebol adopted 
the tower of numbers from Scheme.

Rebol offers a way for handling molding of new data types that could 
be exploited. We could mold an inexact deci! using something like 
#[deci! [precision: 4  value: 1.33333333]]

...the problem with deci! could be address in the same way that plt-scheme 
does...

  - there is no problem with deci!, it is decimal! that has got a problem

Ah. Well then apply my comments to decimal!

do you like this: any [1 true] ; == 1 ?

sorry, bad cut and paste, forget about it

what would you prefer this expression to return, 1 or 2?:

		loop 1 [
			f: func [x] [
				either x = 1 [
					loop 1 [f 2]
					2
				] [break/return 1]
			]
			f 1
		]

I take "either is fine" as a possible answer too

I prefer "2".

sorry, I should have posted my question to Rebol3 group, probably, 
because it is about the new behaviour mainly

2 too. the result of "f 2" is thrown away, the last value 2. should 
be returned. i would  not expect some side-effect here.

The break/return should only change that with a 
  f: func[[throw] x] 
IMO.

Maybe without even give an error.

(continue in Rebol3 group)

I think this is a bug ...

to-local-file what-dir

it removes the trailing "/"

Yep, the DOS/Windows way of representing directories is buggy. Rebol 
is not at fault here.

what's the easiest equivalent to:

>> set to-path [a b c] 7 ; doesn't work

where the block may be a set of arbitrary words in an arbitrary object.

Certainly not the most elegant sollution:
set-path: func [pth val /local rslt][
	rslt: copy []
	head insert/dup head rslt [in get] -1 + length? pth

 repeat i length? pth [append rslt to block! form to path! reduce 
 ['pth i]]
	set do bind rslt 'pth val 
]

>> a: context [b: context [c: 0]]
>> a/b/c
== 0
>> set-path [a b c] 7
== 7
>> a/b/c
== 7

wow, that's a lot of stuff alright...

well, it seems to work, thanks :-)

do reduce [to set-path! [a b c] 7]

hehe I knew there's some simple way :)

ladislav, I did that one, but somehow I have trouble binding the 
result to the original object

yes, the word 'a must have proper context for this to work

do reduce bind [to set-path! [a b c] 7] 'a does not seem to work

rebolek: it doesn't handle paths with indexes in them. I don't always 
store objects inside objects, but also blocks of objects. are there 
ways around that?

do reduce bind [to set-path! [a b c] 7] 'a does not seem to work

 - right, that is not supposed to do anything meaningful, it simply 
 keeps the context the word 'a had

>> a: context [b: context [c: 0]]
>> do reduce [to set-path! [a b c] 7]
== 7
>> a/b/c
== 7

If 'a does not have meaningful context, then bind [...] 'a cannot 
repair the situation

but 'a does have a meaningful context. I'll have to try a different 
approach.

load mold reduce [to set-path! ... ] seemed to work