World: r3wp

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

(I mean the mold/all [undo [true]] example)

So, to constrain this, constructs are useful for values, you don't 
wanna do (because of security reason, if e.g. the data came over 
the network). Therefore there is no need to make constructs for natives, 
operators and functions?

there are constructs for functions. natives and ops can obviously 
not be serialized and don't need to.

What if you want to send this information:
	[next "abc"]
, where next is the native NEXT ?

If you can't serialize NEXT, it can mean anything, right?

then you send it, and when loaded, 'next is executed, no?

Eh, no.

Geomol, you can't present NEXT that way. In that block, it will be 
a word:

>> reduce [:next]
== [action]

Ok, confusing with the block. Forget that.


What if you wan't to send the information: evaluate the native NEXT 
working on the string "abc" ?

simply send the block [next "abc"] and DO it in the other end (if 
you dare)

Geomol - if I send you my script, which contains [next "abc"], and 
you just DO it, then it will work, or not? :-)

But you can't be sure, it's the right NEXT. Same resonnement with 
NONE, TRUE, FALSE etc. Or? :)

Geomol, context, as usual, is irrelevant during serialization.

Sure, it always depends upon the context. In some context, 'next 
might not refer to the native function.

Pekr, yes exactly, it would work, because NEXT here means something. 
My point is, the same can be said with values like NONE, TRUE, FALSE 
etc. So why have constructs?

Serializing NEXT has no meaning, because it's a native, that already 
exists in REBOL. There is no state we can save with it and there 
is no need to transfer that information.

Can't the same be said with the value, NONE holds?

The value that NONE holds is irrelevant.

http://en.wikipedia.org/wiki/Serialization

Is the following statement valid?


Because in REBOL, code is data, serialization doesn't make sense, 
when native functions and operators can't be serialized?

I'm not sure that is valid, because, if you move to other languages, 
where code is not data, you don't serialize "natives" there either.

Ladislav, a better mold/all example is:

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

What I usually use to differentiate these is that there are literal 
values which do not have to be interpreted (only parsed), and logical 
values which have no real meaning without this interpretation.

Serialization

 in the REBOL sense, hence the quotes,  is used to give the second 
 form of data a way to be described in the first, *where its possible* 
  which it isn't at all in the case of some types (native,etc) and 
 only partially in others (objects!, functions!, etc.)   


even with these distinctions there is still a sizeable amount of 
REBOL *data* (interpreter values, not human visible source code) 
which cannot be serialized (in the real sense) in any way because 
either:  

-the notation has simply not been defined for it (cyclic series/objects, 
which is serializable in other languages)

-it implicitely depends on its interpretation (a VID dialect block 
(you cannot save the vid from the faces)), custom types (in the future))

so the way I see it is that: 
-MOLD is the counterpart to DO
-MOLD/ALL is the counterpart to LOAD.

which leads to saying that:

only MOLD/DO can effectively represent all data,  (with the caveat 
that it is extremely insecure)

only MOLD/ALL can effectively represent literal data without interpretation 
(with the caveat that it is not complete)

BOTH , are highly complex to use effectively in non-trivial cases. 
  


IMHO, if it's notation where completed, the second form could actually 
be built to represent all data, since it could be built to include 
binding hints, series reference graphing and more.  It doesn't have 
to be pretty, it just has to be symmetric.