World: r3wp

IMO non-loadable things should not be moldable. So in this case make 
limits on mold, so that the mold fails with such values. Reason: 
IMO under no circumstances should a save destroy values (at least 
not from the inbuild side). Better throw the last changes away with 
a "cant save, internal error" than overwrite valid data with broken 
one. Specially if rebol is a "public" format like xml, where everyone 
can send data and trigger a broken save.

Volker:the console has got a problem with non-moldable value (it 
tries to mold every result)

On further thought, I think the decision to use binary floating point 
numbers in one's program is a decision which includes the understanding 
that there will be some molding inaccuracies. Whether you try to 
print all the digits including the nonsensical final digits (which 
is inconvenient for most usage), or try to hide them (moving the 
problem to load/mold non-orthgonality), either way you must accept 
a problem.

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