World: r3wp

The unfortunate thing is, that there is the MOLD vs. MOLD/ALL ambiguity, 
which confuses every beginner exactly because when they encounter

    none


they usually think it is a REBOL value of the type NONE!, which may 
mislead them in many cases

do we have both MOLD and MOLD/ALL for performance reasons?

I do not think there are performance reasons for that.

why do we then have MOLD and FORM?

rather: why do we have MOLD at all? I'm not sure we can say that 
it preserves REBOL code, because, surely, MOLD/ALL preserves more 
of it.

For example, if MOLD/ALL were used to display the result of an expression 
we would obtain:

    none
    == #[none]

, which would be less confusing than

    none
    == none

but we use FORM for that, don't we?

the only place that I find use for MOLD is when wanting to preseve 
brackets when displaying a block. otherwise I use FORM or MOLD/ALL

no, MOLD is used to display the result of REBOL expressions as far 
as I know

That's not how I originally understood it, when I first read about 
them. Displaying values was the intent with FORM as it does not necessarily 
produce REBOL readable output, but human readable output. MOLD was 
meant to be used for serialization, so that the data could be re-read 
by REBOL.

Indeed, the help strings:

FORM: Converts a value to a string.
MOLD: Converts a value to a REBOL-readable string.

>> print ["==" mold "a^^b"]
== "a^^b"
>> print ["==" form "a^^b"]
== a^b

So, it is clear, that MOLD is used, not FORM

you mean, when returning a value to the console?

you mean, when returning a value to the console?

 - it is not "returning a value to the console", it is "to display 
 the result of a REBOL expression in the console"

that's different than "human readable output":

>> "a^^a"
== "a^^a"

>> print "a^^a"
a^a
== "a^^a"

'that's different than "human readable output":' - I do not understand 
what you are after saying that

the output is clearly different from PRINT than from MOLD.

The current state: 


- MOLD is used to display the result of REBOL expression to the console.
- I prefer MOLD/ALL to be used, since it would be less confusing
- do you mean, that you would prefer FORM?

I'll rephrase:


What I have a problem with, is that there are apparently degrees 
of serialization:


One that we call MOLD, but doesn't really work on all REBOL data. 
I very rarely use this alone.

One that we call MOLD/ALL, and works on nearly all REBOL data. I 
use this very often.


Then we have FORM, which should work on human readable output. The 
problem with FORM is that it isn't flexible enough. For example it 
should have been capable of reformatting numbers, such as 2E-3 to 
".002". It doesn't do that.

R3 does

Yes, R3 does (I wrote the code, as far as I remember), but it is 
arguable, whether it is true, that ".002" is human readable, while 
"2e-3" isn't.

I know that everything is human readable to Ladislav, that's for 
sure. :-)

Not everything, *that* is for sure.

Nevertheless, for me, "1e9" is more human readable than "1000000000"

yes, I know it is for you. :-)

I guess, that it is for everyone having trouble to count the zeros.

I must agree Ladislav event if it hurts ;-)

LOL

Nevertheless, there is reason to have good native support for any 
numeric format, correct? You and I know that our NLPP app suffers 
performance wise over this, having to use FORM-DECIMAL. Don't you 
think that FORM is a good candidate for assigning it to be only for 
human readable output?

NLPP ?

RM Asset product.

I am afraid, that there is no universal format usable for every application 
one may write.

It's likely country varying

Then, does it not make sense to have configuration for this, which 
FORM would use?

I thought several times to implement FORM-DECIMAL in C and support 
the different country styles. Should be queried from the OS. And 
yes, all Rebol functions should be aware of this.

you can redefine the word FORM as you wish, no ?

Performances of rebol in general cases are the real subject here, 
I guess

Steeve, btw, R3:

>> form .00000000000000000000000000000000000000000000002
== "2.0e-47"

That's good

The point is the lack of user types in rebol and also the lack of 
performances (GIT compilation needed)

I maybe understand the reason to have things like #[none], #[true] 
and #[false] to specify those values, if someone choose to redefine 
none, true and false. I say "maybe", because I would be ok to let 
people to on their own, if they did such thing. But why have all 
the other #[] constructs? Is this making things simple or unnecessarily 
complex?

*to let people on their own*

Or did I mean "to let people be on their own"? :) Probably.

When I see tickets like #941, I think "gees, so much energy wasted 
on such rubbish".

Maybe I don't see the light, and then I'm sorry.

*geeze*
(It's late here.) ;)

true: not (false: true)

btw... why we need the parens to get the expected result?

>> mold/all true: not (false: true)
== "#[true]"

>> mold/all (true: not (false: true))
== "#[false]"

the above is in R3... in R2 it seems to be as I would expect:

>> mold/all true: not (false: true)
== "#[false]"

I maybe understand the reason to have things like #[none], #[true] 
and #[false] to specify those values, if someone choose to redefine 
none, true and false.

 - as far as I am concerned, you are missing the point, Geomol. My 
 thoughts:


1) there is a Data exchange dialect in REBOL, which is the main REBOL 
dialect (considering the fact, other REBOL dialects are derived from 
it).


A sidenote: the "Data exchange dialect" name may not be ideal. (this 
name is used in the http://en.wikipedia.org/wiki/REBOLarticle). 
Maybe, following the same "naming procedure" as for other dialects 
we could name it the "Load dialect"?


2) In the Data exchange dialect (or Load dialect, whichever you prefer), 
the

    none


expression is a word, and you do not have any means how to express 
the #[none] value, except for this specially escaped format, the 
same holds for #[true], #[false], #[unset!], etc.

Considering the fact, that any REBOL code is loaded first (in the 
computer, but your brain should follow a similar procedure when reading 
it), i.e. handled as the "Data exchange dialect"/"Load dialect" (pick 
the one you prefer) before being (eventually, but not necessarily) 
submitted to any other interpreting function (like DO, etc.), the 
specially escaped format is useful, since it increases the expressivity 
of the "Data exchange dialect"/"Load dialect" (pick your preferred 
one).