World: r3wp

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).

Oldes, regarding your example. It looks, that you messed up something.

I do not need any parens to write:

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

BTW, at the Davis RebCon, Gregg asked which REBOL dialect is the 
one used most frequently, and he suggested the function specification 
dialect, IIRC. But, as you may have noticed, my favourite is the 
"Data exchange dialect"/the "Load dialect" (still did not pick the 
name you prefer?)

I think that Ladislav's point of view can be simply exemplified:

>> type? first [none]

== word!

>> type? first [#[none]
]
== none!

and perhaps made clearer with an example using #[unset!]:

>> type? unset!       
== datatype!
>> type? first [unset!
]
== word!
>> type? first [#[unset!]]      
== unset!

Any, if we define a DISPLAY-RESULT function as follows (in R3):


    display-result: func [value [any-type!]] [print ["==" mold/all :value 
    newline]]

, we obtain:

>> display-result unset!
== #[datatype! unset!]

>> display-result quote unset!
== unset!

>> display-result quote #[unset!]
== #[unset!]

, which is (IMO) less confusing than

>> unset!
== unset!

>> quote unset!
== unset!

>> quote #[unset!]
>>

The data exchange dialect is a good point to have constructs. Then 
my logic goes:


REBOL values can be divided in two groups, 1. the ones with a non-ambigious 
lexical representation and 2. the ones without such lexical representation. 
Datatypes of values in the second group include:


unset! none! logic! bitset! image! map! datatype! typeset! native! 
action! routine! op! function! object! library! error! port! event!

and maybe a few more depending on what version of REBOL. The rest 
is in the first group.


It would make sense to have constructs for the values in the 2nd 
group. Then I look at some examples of constructs:

#[string! "abc"] #[email! "[abc-:-d]"]


Those are not necessary. If it's because all values can be represented 
as constructs, then why doesn't this work?

>> #[integer! 1]
** Syntax Error: Invalid construct -- #[


And how would values of type native!, action!, op!, etc. be represented 
as constructs?

I'm not convinced.

Example of necessity for string! and other series! types:
>> X: #[string! {abc} 2]
== "bc"
>> head X
== "abc"

Ah, now I got it. Thanks!


Is it complete, so natives, operators and functions can be made as 
constructs too?

REBOL values can be divided in two groups, 1. the ones with a non-ambigious 
lexical representation and 2. the ones without such lexical representation.

 - Well, this is rather confusing for me, since e.g. #[none] is (for 
 me) a "non-ambiguous lexical representation" of the value. But, your 
 classification would be OK with me, if we just added a note like 
 ("when the specially escaped representations are disregarded").

The Data exchange dialect (or the Load dialect) is incoplete in the 
following sense:


- natives etc. do have specially escaped representations (MOLD/ALL 
creates them), but such representations are not loadable

- MOLD/ALL creates loadable representations of REBOL objects and 
functions, but they are not guaranteed to preserve the properties 
of the orignal values

The "incomplete" above means "incomplete when compared with the DO 
dialect".

natives etc. do have specially escaped representations (MOLD/ALL 
creates them)

>> native? :until
== true
>> mold/all [until [true]]
== "[until [true]]"

How do I see the escaped representation?

>> mold/all :until             
== "native"

Hm, how is this useful?

Why not do this instead of having constructs?

>> make logic! 0      
== false
>> make logic! 1
== true
>> make none! 0 
== none

... etc.

Sorry I answer myself, but it's probably because it gives a different 
kind of value when loaded:

>> load {make logic! 0}
== [make logic! 0
]
>> load {#[false]}     
== false

How do I see the escaped representation?
 - interesting, you seem quite seriously confused

the [until [true]] block contains only words

>> mold/all :until
== {#[native! [[
    "Evaluates a block until it is TRUE. "
    block [block!]
]]]}

It is from R3, but, as said above, it is not loadable

Why not do this instead of having constructs?

>> make logic! 0      
== false

, because it is confusing. I prefer this:

>> display-result make logic! 0
== #[false]

(see the DISPLAY-RESULT function above)

I guess, much of my confusion here comes from the fact, that I never 
had the need for constructs.


If we follow the thought, that the none value should be shown as 
#[none] in the console, when it's a result, then the following should 
be shown as well:

>> next "abc"
== #[string! "abc" 2]


I think, most people wouldn't want that. It's not very readable. 
I still ask myself, if all those constructs are really necessary 
taking the amount of work and time used into account.