World: r3wp

oops  

1.0 = 0.1

If you want to use other than the standard REBOL terms, then come 
up with some other terminology to make that specific distinction, 
since it is the only distinction that matters for this discussion, 
which is about the difference between MOLD and MOLD/all.

Max, to be true, you should add in binary floating point IEEE754, 
otherwise, there are non-binary (decimal IEEE 754 versions), where 
it is not true

And pardon the delay in replying, I am having AltME freezes again.

Brian: ``The definition of "constructed datatypes" in REBOL is those 
types that can be written literally in REBOL without using "serialized 
syntax"``

_can_ or _can not_?

Freezes: me too

can not. The not got dropped in a freeze.

(Ladislav, true, that is what I meant)

Standard REBOL terms - I like those, is there a definition, what 
is meant by "serialized syntax"?

(I suppose, that it is the syntax starting with #"#"?

I think the definition would be to observe mold/all behaviour.

Anything in #[].

That is the standard term's meaning.

Well, then, ok, some REBOL values can be represented by "serialized 
syntax" and not by "non-serialized" DED syntax, this is where we 
agree, I suppose?

At least the REBOL standard. We have a lot of inappropriate standard 
terms (I'm looking at you, "context"). :(

I have no idea what you mean by DED.

read http://en.wikipedia.org/wiki/REBOL#Syntax

So you basically mean REBOL without #[] ?

no, I just mean REBOL

i.e. everything LOAD accepts

Oh, then you are not making the distinction in question here in this 
discussion.

Ok, so decimal! is obviously something in a third category. It can 
not be written literally without using special syntax, but it is 
not using serialized syntax according to Brian's definition.

LOAD accepts a lot of stuff that doesn't match this or that dialect's 
semantic model.

The point is, that DED has no semantic model.

Yes, that is the point

It is purely of syntactical nature, a tree of blocks (and parens) 
and scalar values.

And, it is trivial to see, that #[true] belongs to it.

And based on that, the problem is: load + save does not preserve 
the original data correctly

Regardless of #[true], as demonstrated on decimals

Andreas, decimal is a special case in that the regular syntax which 
can specify every value representable in memory, also can specify 
values which aren't representable, which have to be approximated. 
And since those approximated values include much of what developers 
actually use, the aproximation is undone when the value is saved 
in the form which is supposed to result in ordinary source code.

which is why some values wrap to 0.1 even though that value isn't 
representable within memory... it should be 0.999999999999999... 
 IIRC

when I say "it should be" I mean the real value in memory

Yes, that looks as a reasonable explanation, but, as I said, it transforms 
the script:

rebol [] same? 0.10000000000000001 0.10000000000000002

yielding #[false] into:

rebol [] same? 0.1 0.1

yielding #[true]


If I had to use a script preprocessor doing this, I would rather 
jump under a moving magnetophone tape, as a friend of mine told once

the approximation is undone

 is an euphemism. more precisly a transformation is applied which 
 also transforms values that are perfectly reprensetable in memory

and therefore have not had to be "approximated" in the first place. 
0.10000000000000002 demonstrates this

euphemism
 is pregnant, yes

Ladislav, a clarification: The DED has a semantic model, but it doesn't 
exactly match the in-memory model. And there is currently no function 
that can generate a serialized form of the in-memory model, and no 
function that can recreate the in-memory model from a serialized 
form (in this case "serialized" being used in its accepted meaning 
rather than the REBOL "serialized syntax" term). MOLD and MOLD/all 
are just approximate, as is LOAD. DO is a bit more accurate, but 
there is no function that can generate DO code from *all* in-memory 
structures, just some of them; the rest currently have to be written 
manually. So what we need is a function that does a better job of 
serializing the in-memory data model, and probably a new syntax to 
represent it.

I think we could just extend the serialized form to represent just 
about everything in-memory.

the best argument I heard in this discussion _against_ the sequence 
of load + save behaving as transparently as possible is that this 
is not at all intended in the first place! except, the argument gues, 
the intended design is for save to be symmetric to mold.

Brian: would you mind describing a single _semantic_ aspect of the 
the DED's model?

1 represents an "integer".

What is semantic about that?

So what we need is a function that does a better job of serializing 
the in-memory data model, and probably a new syntax to represent 
it.

 - actually not, as I have no problem to demonstrate, since the goal 
 of script preprocessing (which is the subject of this discussion) 
 can be reasonably achieved using the LOAD and SAVE/ALL pair.

1 is syntax for the "integer!" type, no semantics involved. The whole 
point of _data_ is that it has no semantics but a syntactic structure. 
That may not be REBOL's standard terms, but computer science instead.

Ladislav, script preprocessing doesn't require the whole range of 
in-memory data structures, just a subset. What I am talking about 
is outside of that subset.

Andreas, the integer! type is a semantic concept. As is nested blocks.

a syntactic category is per definition no semantic concept. but that's 
really getting off-topic here.

semantic battle

We are only concernce with this subset of data structures and we 
see that LOAD + SAVE in sequence does not adequately preserve even 
those.

Steeve, that is exactly a false impression, the original topic is 
about REBOL syntax preservation, all semantic detours are off-topic