World: r3wp

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

And the argument is that a pair of functions with the names of LOAD 
and SAVE which pretty much cry *duality* is to be considered harmful 
if they willingly violate their implied duality.

but you both use a different semantic to argue around your subject

Taking the decimal! type as an example, the DED syntax (what LOAD 
can handle) can accept a wider range of decimals than can be represented 
in-memory. Those that can't be represented directly in memory are 
approximated. Since those approxiimations tend to happen in the 16th 
to 17th digits, they can be "undone" by ignoring those digits in 
the "friendly" output.

If you want to consider LOAD and SAVE not being a duality to be harmful, 
go ahead, considerations like that are a matter of opinion.

This "unapproximation" is simply broken then.

Yes, Andreas, that is what I have been saying.

But they are still useful, even if they are limited.

They are not limited, they are broken.

Right, since it "unapproximates" all values, i.e. values, that aren't 
"approximated". Therefore, it either can be called a "broken unapproximation", 
or, more precisely, no unapproximation at all,since it actually is 
not "unapproximation"

Reapproximation for MOLD, no approximation for MOLD/all, approximation 
depends on the digits for LOAD, at least for decimals.

Well, is that worh any discussion? The transformation clearly transforms 
values so, that after being transformed, additional error is introduced.

Maxim, we can't extend the existing serialized form to represent 
everything in memory, because binding, cycles and DAGs aren't representable 
without some kind of reference index. So even rebin wouldn't do, 
we'd need something like RIF.

Ladislav, it was just an example to illustrate that the abstract 
REBOL that is accepted by LOAD doesn't exactly represent the real 
REBOL in memory. But it does represent enough to do source processing 
by a preprocessor.

If you want to consider LOAD and SAVE not being a duality to be harmful, 
go ahead, considerations like that are a matter of opinion.

Ha, at least we got to the point. This opinion was all this discussion 
was originally about.

As a matter of fact, LOAD and SAVE/all form a far better duality 
as far as REBOL source is concerned. So Ladislav and I argued that 
making /all the default for SAVE would be a sensible thing to do.

The problem with that is that opinions vary. This has been happening 
a lot lately. Just the other day, Sunanda claimed in CureCode that 
assignments were unsafe. I couldn't even answer a statement like 
that without it turning into a flame war.

Sure, that's why we are discussing it at all. Besides getting mightily 
side-tracked in semantic debates that do mostly not pertain to this 
issue, to only argument against this suggestion I heard was that 
SAVE should behave symmetrically to MOLD, not dually to LOAD.

A nice result of this side-tracking is that I now consider mold completely 
broken for decimals, as it applies a hack that maybe once was appropriate 
for single precision floats, but certainly no longer is for double 
precision floats.

SAVE and MOLD are explicitly designed to be newbie-friendly - that 
includes being able to have MOLD generate the value 0.1, which is 
not representable by the (misnamed) decimal! type in memory. And 
#[] syntax has been judged to not be newbie-friendly, or at least 
an ugly thing that only power users do. If you want to reverse that 
decision, fine, but it's unlikely.

Once again, 0.1 is not the point here. That's the result of a flawed 
pretty-printer.

>> mold/all 0.1
== "0.10000000000000001"

Many values that developers usually write out in decimal aren't representable 
in memory. Welcome to the wonders of IEEE754.

Funny, what platform?

>> mold/all 0.1
== "0.1"

Andreas, you are not getting that the whole point of MOLD and SAVE 
is to be a pretty-printer.

Windows

What is FORM supposed to be then?

A pretty-printer for users rather than developers.

;-) Someone should start to write our chronicles. When I will be 
an old hag, I would be fun to read our old debates.

Andreas, please use R3 when talking about MOLD/all for decimals - 
it's broken on R2.

Fair enough. So your take is that LOAD/SAVE forms no duality because 
of MOLD is supposed to do "developer pretty printing" but for absolute 
newbie developers, not for developers familiar with e.g. #[] syntax.