World: r3wp

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.

I think, that the point here is the Geomol's question:


I still ask myself, if all those constructs are really necessary 
taking the amount of work and time used into account.


The answer is quite simple, it is as with any data the Load dialect 
can represent:


- many data representable by the Load dialect aren't "really necessary"

-- other languages can usually represent less data types than the 
Load dialect can

-- the Load dialect did not have the escaped format from the start, 
and could do without it


- without the escaped format, the Load dialect cannot express values 
of the logic! type


- it is useful to be able to express values of the logic! type in 
the Load dialect
-- some languages have the advantage of being able to do that

-- it is confusing to use a word like true in the Load dialect, when 
meaning the logic value, since in the Load dialect true is a word, 
not a logic value (notice the example, where Geomol confused words 
and their values)

-- the expressibility of the logic! datatype in the Load dialect 
enhances the expressivity of the dialect, which is why it is useful 
to have it, similarly as for any other datatype expressible

-- the expressibility of the logic! datatype enhances the reflexivity 
of REBOL, since 

--- this way, the Load dialect can express values that would be otherwise 
inexpressible in it, while being used in the Do dialect

--- that means, that the Load dialect would not be usable to "speak 
about" logic values in a direct way

That was my answer as far as the usefulness of the #[true] and #[false] 
values is taken into account. Similarly, the usefulness of #[unset!] 
and #[none] is quite unquestionable. As far as the usefulness of 
the other representaions goes, it may be more questionable to have:

- escaped format for objects, because

-- some objects are not describable precisely enough using the current 
escaped format

-- nevertheless, the ability to describe a result of a REBOL expression 
this way is useful at least sometimes, since for me, the #[object! 
...] clearly communicates e.g. the fact, that it is one value, while

--- make object! [...] are, in fact, three values in the Load dialect, 
as Geomol noticed


- similar notes can be written about the escaped format for the function! 
datatype


- the escaped format for natives, (which exists only in R3) is even 
less useful, since it is not loadable, so, in a strict sense of the 
word, it is not even in the Load dialect

-- but (arguably) it can still be used to describe a result of an 
expression when such a demand occurs

The only problem right now, is that the serialized form of the language 
is just not complete. all the edge cases I can think of have a way 
of being resolved, especially in R3.

having cyclic references be checked and used on object/block types 
would already go a very long way.


#[block  1  [ val1 val2 ...]] ; serialized block with uid as first 
parm (only needed when it is shared in the string being loaded).
#[block  2  [ val3  #[block 1]  val4]  ; shared block
#[block  3  [ #block 3 ]]   ; self-reference


effectively shows a simple way to solve the cyclic series/object 
problem.

The only problem right now, is that the serialized form of the language 
is just not complete.

 - I would say, that "the Load dialect is not complete relative to 
 the Do dialect", being unable to express some values of the Do dialect.


Nevertheless, the question arises, whether the relative completeness 
is necessary. For example, you demonstrated how cyclic blocks could 
eventually be handled, but, I am not sure you do suggest your solution 
to be used, or just demonstrate the possibility.

Moreover, when I look at it, I have to say, that it actually would 
not be acceptable, since when you do want to mold e.g. your block 
3, you should obtain a representation of one block

Aha, wrong example, I should have used your block 2 as an example

You forgot to mention: Natives, actions and ops aren't properly serialized 
for a couple reasons:

- The native references wouldn't necessarily be valid between versions.

- It breaks the security constraints, giving access to natives without 
requiring access to their contexts.

Today's Moment of REBOL Zen:

>> s: "abc"
== "abc"
>> t: copy next s
== "bc"
>> index? t
== 1
>> b: []
== []
>> insert b next s
== []
>> index? b/1
== 2
>> p: copy/deep b
== ["bc"]
>> index? p/1
== 2


So copy/deep a block does not use copy on each member of the block 
in the normal sense of copy.

I'm not sure to see your point.

But If you want to see if the series are the same or not you have 
to use same?
Actually, Your trial does not  prove your claim

Maybe the following makes it more clear?

>> b: []
== []
>> s: "abc"
== "abc"
>> insert b copy next s
== []
>> index? b/1
== 1

When copying a string, you get what you see.

When copying deep a block containing strings, you get more than what 
you see.

Yes, the string is copied in both cases. The difference is that  
copy/deep copies the whole string not only the part that is maked 
by index.

Neither, sorry :-)
index? never gives the absolute position.
just try index? head b/1

try mold/all after and you will see the (hidden) parts

Yup! :)

an index is stored alltogether with any serie

I'm not sure which behaviour is better though. Ie copying whole string 
vs. just the 'ranges' defined by the series values in the block.

Don't know, but it would be a problem now, because I use this behavior 
to hide data in blocks (like absolute identifiers)

My guess is the current copy/deep behaviour can consume too much 
memory if the strings(or whatever data) are too big.

You have a point here

Here is another way how to ilustrate it clearly:
 
>> s: "abc"
== "abc"
>> mold/all copy/deep reduce [next s]
== {[#[string! "abc" 2]]}
>> mold/all copy next s
== {"bc"}

is that true only for strings ?

I think it works same on all series.

>> s: [1 2 3]
== [1 2 3]
>> mold/all x: copy reduce [next s]
== "[#[block![1 2 3]2]]"
>> mold/all y: copy/deep reduce [next s]
== "[#[block![1 2 3]2]]"
>> mold/all z: copy next s
== "[2 3]"
>> same? x/1 next s
== true
>> same? y/1 next s
== false
>> same? z/1 next s
== false
>>

Ok, I agree, it's a problem for 
>> same? y/1 next s
== false

the hidden part should not have beeb copied

Good point Geomol, you found a new ticket

yes, the whole serie is copied from HEAD in the copy/deep case...not 
sure if Carl does that intentionally but could be a bug that can 
lead to unwanted bigger memory footprint in some scripts imo.

Ladislav, typical serialization only takes into account the data 
traversed (in the order it meets it).  in the above example, if the 
block 2 was encountered first, then it would look like this:


#[block  2  [ val3  #[block  1 [ val1 val2 ]]  val4]  ; shared block 
containing another shared block
#[block  1 ]


(I kept the ids, just to make the comparisons easier, but it would 
have effectively swapped 1 and 2)


I built such a system for a project a long time ago (I lost the code, 
unfortunately).   It stored graphics in block formats, and used shared 
sub-blocks in many objects .  So  I built a reference-safe load and 
save which completely made the above invisible... I used tags to 
refer to blocks, and  a tag-based block serialization which was very 
similar to the above.  it was quite specific to my application, but 
it could have been generalized.   I did have to make it a two-step 
process.  if it where internal, it could be done in a single pass.


 a serialization can be made more persistent (accross several serializations 
 and even sessions), but that is not what REBOL is built for, nor 
 would it be very useful within REBOL's semantics IMHO.

So, shall I understand it, that you actually propose to use this 
kind format for cyclic blocks?

unless someone finds a better alternative, I don't see anything wrong 
with this syntax... maybe it needs a bit more components (like keeping 
tabs on the index of the block).  
in fact  maybe this is even better:

 #[block  #1 2 [ val1 val2 ]] 


here an issue type is used for the uid and the integer is used as 
the block index.

since this is just managed within LOADing, it shouldn't force the 
word count to increase, its just a notation.

I solved the problem of serializing circular blocks etc. a long time 
ago, by adding DISMANTLE and REBUILD. Eg. see http://www.colellachiara.com/soft/YourValues/libs/persist.r

So, it can even be done as a mezz layer above MOLD and LOAD.