World: r3wp

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.

I see them as necessary, otherwise you would not be able to serialize 
(or specially escape) any rebol code or data properly using a fixed 
method. This is very important for dialects.

Henrik, can you give a simple example, where the serialized format 
is needed?

every time I save REBOL data to disk? I use this hundreds of times 
every day.

What's wrong with using a simple SAVE?

you will lose every datatype that will be seen as words.

Not, if you LOAD the data back into a context, where those words 
have meaning.

no, some types may be *confused* as words. that's different.

Basic example:

>> save %file.txt none
>> load %file.txt
== none ; is it none?
>> type? load %file.txt
== word! ; nope
>> save/all %file.txt none
>> type? load %file.txt   
== none! ; yes, only with proper serialization

It's kinda interesting, how complexity sneak into a language like 
REBOL. I have never used constructs. I save REBOL data and code to 
disk all the time. I even created a file system/database, that is 
all about saving and loading data and code. I get along using a combination 
of simple REBOL functions like SAVE, LOAD, REDUCE and DO.

I understand, it can be argued, it's more simple to just use
	save/all ....
	load ...

than something like
	save ...
	do load ... or maybe ... reduce load ...


but trying to make this simple result in a much more complex language. 
(as I see it)

I'm not sure that's a complexity. It's a basic need, when transfering 
REBOL data somewhere else, using strings or binaries. There is simply 
a loss of information, if the data is transferred in an unserialized 
fashion.

As code is also data in REBOL, and because natives can't be loaded 
and there are bugs like in making function constructs, then I see 
this as half-hearted. It kinda work, but not really.

You can't avoid serialization. What does this block contain?

>> my-block
== [none none]


You simply don't know by looking at it and you can't use this information 
other than in the current context. If you need to transfer the data 
elsewhere, you must serialize it.

Geomol - you should seriously serialise :-)

heh

Well, Henrik, I suppose the none word holds the none value, and if 
it does, it probably works as intended. If people want to redefine 
none, then it would mean something else. And then what? I don't see 
a big problem needing constructs in there.

If a writer write
	fromage

what does that mean? In Denmark, it's a dessert, in France, it's 
cheese.

So I need to seriealize that word to hold the meaning?
Nah, I don't think so.

The meaning comes from the context.

Interesting, that after writing

    mold/all [undo [true]]


and wondering why you did not obtain what you expected you still 
don't see that you confused words and the possible values that may 
have been assigned to them.

Geomol, the context is not relevant during serialization, so stating 
that "I suppose the none word holds the none value" is incorrect. 
It is the unreduced contents that are important. Also you don't have 
the index of the block.

Let me reveal what my-block actually contains:

my-block: next reduce [true none 'none]


That information is only available in the serialized format like 
this:

>> mold/all my-block
== "#[block![#[true] #[none] none]2]"

Yeah, I wasn't very sharp, when I wrote that mold/all example, Ladislav. 
:)

As I see it, the problem is not that you "wasn't very sharp", the 
problem is, that the practice of displaying words and their values 
the same way *is* confusing.

That information is only available in the serialized format like 
this:

Why isn't it available using the do dialect, like:
	do [next reduce [true none 'none]]


And then you say, because DO, NEXT and REDUCE may not hold the meaning, 
you expect. 2 points:


1. Right, but is it worth the effort, if those are being redefined?

2. Why SAVE series like that at all? Why not save HEAD series and 
then maybe an offset, if you need it?

Ladislav, isn't it only confusing, if those words are redefined?

And redefining those words in the first place is confusing, so this 
bites itself in the tail.

Geomol, you don't know how the data is generated, if you are getting 
the data from disk or network, where you are surely not haplessly 
DOing things for security reasons. You are capturing the state of 
the data. Without such a state capture, much of REBOL is rendered 
useless.

Ladislav, isn't it only confusing, if those words are redefined?
 - no, and the example you used demonstrates that