World: r3wp

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.

I guess, that you meant the DISMANTLE-BLOCK and REBUILD-BLOCK functions. 
Nevertheless, the source code does not contain the definition of 
the CUSTOM-TYPE? function.

No, dismantle and rebuild are not defined there specifically, they 
are defined as actions for custom types (eg. pblock! etc.). But they 
are based on those two IIRC. http://www.colellachiara.com/soft/YourValues/

I am doing some tel. report automatic checking, and I need an advice 
- how do I get easily substracted two time values going thru the 
midnight?

>> (fourth 29-7-2011/00:02:00) - (fourth 28-7-2011/23:52:00)
== -23:50


If I substract whole date value, it returns 1, it simply counts just 
dates, not time ...

>> difference 29-7-2011/00:02:00 28-7-2011/23:52:00
== 0:10

this works to a point whereupon you start getting overflow

Overflow happens on dates around 68 years apart -- so probably safe 
for Petr's intended usage.

68.04 years to be precise  ;-)  the seconds resolution in 31 bits

(power 2 31) / 60 / 60 / 24 / 365.25

Max - thanks :-) I wonder why there is a difference between the 'difference 
and substraction ....

You were subtracting 23 hours and 52 minutes from zero hours and 
2 minutes. That's -23:50.

With difference, the whole date plus time was given, then the difference 
is positive in this example.

Subtract on dates give you number of days. Subtract on times give 
you number of hours, minutes and seconds. Difference on dates (incl 
times) give you number of hours, minutes and seconds.

Maybe subtract on dates should only give days, if time is not given, 
else work as difference?

I have a COPY/DEEP question:


When doing a COPY/DEEP, the first level requires that the argument 
must be a series!, port! or bitset! But when doing a /DEEP, I imagine 
that COPY traverses a series for elements and uses a different process 
than for the first level to determine whether the element can be 
copied. If it can't, it silently passes the value through.

Why can't we do that on the first level as well?

Just so you can puT COPY everywhere, without caring about the type?

I'm not really sure I want to, but I think it's interesting that 
there is a difference between the first level and other levels.

It makes sense to me. Copy what can be copied. I like having the 
type check at the top level.

I do dislike having to do:

either series? var [copy/deep var][var]


thing. Generally the programming needed for absolutely deep copy 
a value is too elaborate.

I don't do that very often. If I did, I would just wrap it.

I try to think of situations, where I would need to do that. I also 
don't think, I do it often. But it's an interesting idea. I try to 
come up with some situations, where I need to copy a value, that 
can sometimes be a series, sometimes not. Hmm...

Let's see: I need to copy a value, and it can be any value, so copy 
should work on any value. I don't see a flaw in that. I wonder, if 
it has come up before?