World: r3wp

(ok, i'll abstain. ladislav is faster :)

please, don't, have to run, bye

I personnally NEVER use SAVE/ALL in any manner.   I always use WRITE 
so I can't even give you a valid case for SAVE/ALL  ;-)


but I've used SAVE a few times to log data.  Even when doing script 
pre-processing, SAVE/ALL broke too often for me to afford the hassle.


I'll usually use MOLD/ALL process the data as a string with real 
control then use WRITE

and even then, I don't LOAD scripts because we loose all the comments, 
so I pretty much always use LOAD/next, & string parsing to process 
REBOL source scripts.

mentioning the perceived symmetry to mold and mold/all is kind of 
evading the argument. ladislav is arguing that SAVE should be useful 
with respect to LOAD. nothing stops us from defining SAVE as WRITE 
... MOLD/ALL ..., and there is no necessity to hold up this perceived 
symmetry.

btw, I *am* playing devil's advocate here... ;-)


It might be that for the general purpose, SAVE/ALL might be the better 
default.  but IMHO SAVE itself is usually inadequate for storing 
DATA.  it might be ok for storing dialect blocks though.

Ladislav, if you try to DO a script saved with SAVE/all or MOLD/all, 
it will fail if it contains functions or objects. And it definitely 
*won't* be "as close to original as possible". So /all can't be the 
default for SAVE.

>> save/all %foo.r load/all "foo: func [x] [x * x] foo 42"
>> do %foo.r
Script: "Untitled" Version: none Date: none
== 1764

works pretty well!

The primary purpose of SAVE is to save scripts that are to later 
be processed by DO.

Andreas, that isn't a function, it is a description of a function.

It's a script, you said scripts

and that's the whole point. if you load a script and then save it, 
the original script should be affected as little as possible

I also said functions and objects. That means function!, closure! 
and object! values, not their source.

Yes, and that's the strawman. Those literal objects will only be 
written from a script if it contained them in the first place.

{And it definitely *won't* be "as close to original as possible".} 
- this is a Goebbels' truth, would there be any example?

I gave one above.  if you try and save/all cross-referencing object! 
values the mold fails.

Yet another example of a Goebbels' truth:

>> do mold quote (1 + 2)
== 3

in fact basic SAVE fails as well.

Max, you did not give any example, that would not deserve the "strawman 
prize", your DATA surely is not a DED

BTW, my above DO example demonstrates quite pregnantly, that DO isn't 
a "counterpart" of MOLD

I don't get what you mean by strawman prize?

maxim, you have a good point regardign serialising circular datastructures 
and similar stuff

the objects could be within a block of data that you are trying to 
serialize... it would still fail.

but it is a different issue than what we are discussing here

You built a strawman, since your example does not relate to the subject 
at all. The subject is: SAVE is not good to process DED.

but SAVE is not only for DED, THAT is my point.

and in any case, you could have objects within your DED and SAVE 
would fail.

(*could* fail)

There is nothing that can be used to process non-DED and I agree 
with that, but that is a completely different subject

no, you could not

where is the DED defined?

LOAD

Data Exchange Dialect, see http://en.wikipedia.org/wiki/REBOL#Syntax
, if you do not know what it is

{but SAVE is not only for DED, THAT is my point.} - that is not a 
point, that is a falsehood. SAVE is not even for DED (SAVE/ALL is), 
less so for non-DED data

When SAVE is being used to generate source that is meant to be run 
by DO, that source should be semantically equivalent to DO code (active 
values in an evaluation context won't be preserved without QUOTE, 
nor will constructed values in a non-evaluating context). When the 
generated source is intended to be LOADed, it should stick to the 
semantics that can be directly LOADed without DO (no multi-level 
"nested scopes" or other binding tricks, no inline modules, no natives). 
And when you are going to combine them, stick to string source.

The trick here is that #[none], #[true], #[false] and #[unset!] are 
constructed values. If you write them out directly in that syntax, 
you are mixing paradigms.

ok read the complete definition of DED and its missing A LOT of valid 
rebol datatypes.


well, the object! is part of "compound" values.  there is a litteral 
notation for objects, so yes, it is part of the DED.


also the text uses composite values, but its like refers to scalars, 
which is wrong.

(the text of that wiki article)

arrrgh...  I'm "typoing"  profusely

like = link

but  #[none], #[true], #[false] and #[unset!]   are part of the DED... 
no?  since they are the litteral notation of specific datatypes.

Maxim's point about serializing circular structures also applies 
to "nested scopes" with more than one level of nesting.
>> #[function! [[x][#[function! [[][x * x]]]]]] 42
** Script error: x has no value
** Where: applier applier
** Near: make function! [[][x * x]]

Maxim, I have yet to comment on the DED - I am still commenting on 
REBOL.

The trick here is that #[none], #[true], #[false] and #[unset!] are 
constructed values.

 - yet another Goebbels' truth. They are much less "constructed" than 
 e.g. 0.1, which actually does not even exist in REBOL (how many users 
 know that?)

I am not using Goebbel's truth, I am using REBOL.

Me too, but, I am not trying to present falsehoods as truths

Well, obviously decimal!s are constructed values too!

well,   once could argue that 0.1 exists in REBOL at the DED level 
but not at the,  but not after its constructed.  ;-)

As said, if #[true] is "constructed" in any sense of the word, what 
is 0.1? As I said, 0.1 does not even exist in REBOL, which is easy 
to prove

Maybe it is deconstructed?

litteral notation of specific datatypes

 - Those are "serialized syntax". The definition of "constructed datatypes" 
 in REBOL is those types that can be written literally in REBOL without 
 using "serialized syntax". I am going by the standard REBOL terms 
 obviously, since both syntaxes are serial and all values are constructed 
 from those syntaxes.