World: r3wp

So, I have to use their formatting function, which produces this 
result

Please put that in a comment of bug#1633 - it might help justify 
not using MS's compiler.

Ladislav, I would like to see how you write that formatter under 
GCC, Is that too much code that you can't show it us ?

If so, forget it

Hmm, I should not do it, I suppose.

But, the principle is quite simple: multiply the number by a "suitable" 
power of 10 and convert the result to integer. The trouble is, that 
you need to use a high precision multiplication and power.

(which is unsupported in MS compiler)

You mean, you don't do it using an incremental way, each digit separatly 
?

No

What version of the MS compiler is being used? Can it be upgraded, 
and would that help? Can the Intel compiler be used, or the DMC++?

Only "ancient" versions of MS compiler support the extended precision

GCC should suffice. And as Carl is already using it for the Host 
Kit, it may also be possible.

Max: this is very funny. normal MOLD, afaik, is only there for backward 
compatibilty. i personally almost always use /all, when i don't use 
it it's because i'm molding something i just loaded or something 
like that, eg. i know that i don't need the /all, bet even if i used 
it it would make no difference at all.

it's very very hard imho to come up with reason NOT to use /all...

if you try to DO a script saved with SAVE/all or MOLD/all, it will 
fail if it contains functions or objects.
 - show me an example.

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

 - weird, i always use save and load to save and load data. but, even 
 if that was the case, save/all would work just as well, so this is 
 a silly argument.

Hmm... I recall saving rebol objects with save/all and not being 
able to load them again properly

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

 - in that case, SAVE/ALL is *BETTER* than SAVE. there is no argument 
 about that.

some problem with functions inside objects or something

If you write them out directly in that syntax, you are mixing paradigms.

 - that makes NO sense. I write them directly MANY times because it 
 saves useless evaluation of DATA

Brian: your #[function! ] example is something I have ALWAYS pointed 
out as a bug and you ALWAYS countered by saying it is a "security 
feature" which i still thing is a very stupid thing to do (doing 
that as a "security feature")

SAVE and MOLD are explicitly designed to be newbie-friendly

 - I though Carl had realized, that "newbie-friendly" is the worst 
 thing you can do to a language. I hope others realize this as well, 
 as soon as possible...

Graham: show me ONE example of something you can LOAD but then breaks 
when you SAVE/ALL it back.

SAVE is *not* able to serialize arbitrary REBOL data. that is a known 
problem that Carl did not consider important enough to address, since 
he prefers using dialects to interchange data instead of just moving 
around the internal representation a program may be using.

User friendliness
 is in the eye of the beholder. I consider this:

>> block: [none #[none] true #[true] 0.1 0.10000000000000002]
>> print mold/all block

[none #[none] true #[true] 0.10000000000000001 0.10000000000000002]
>> print mold block
[none none true true 0.1 0.1]


as a problem for me, trying to give me wrong informations, as well 
a a problem for a beginner, who may not even be able to find out 
the informations he obtained were wrong

CureCode #1634, add a "me too", if you like

Gabriele, I also always use /ALL, when molding.    as I stated, I 
was playing devil's advocate, in which case I helped improve the 
case for SAVE/ALL being better.


 but I'm not sure its a good thing to break the symmetry between mold/all 
 and save/all.  


IMHO if we change one, we should change both.  IMO this is a better 
solution.


but this doens't change the fact that MOLDing is severely limited 
in many ways.

Gabriele, that "security feature" argument was always more of a "look 
on the bright side" thing, not really countering the argument that 
it may be a bug. However, more functions are usable in R3 after being 
built with #function! ...] than were with R2 - apparently references 
to the "global" environment are bound, and then the function-local 
environment. I have yet to figure out how, but I'm working on it; 
a clue is that there is no real "global" environment. That means 
you lose the security benefits of the non-feature in R3, so enjoy 
the get-path and SELECT security enhancements that more than compensate 
for such things.

Ladislav, you, Gabriele and I are not the kind of users that MOLD 
is trying to be friendly to. Try newbies.

Apparently the particular "global" context bound to serialized functions 
in R3 is the system context, not the user context. Or maybe it's 
the exports context - hard to distinguish them right now, since system 
and exports is currently the same object (it's a work in process). 
So that makes serialized functions minimally useful in R3, instead 
of not useful at all as in R2. Interesting.

Try newbies

: unless I find out you are right, I do not have any reason to believe 
you (I remember, that I was a newbie once too)

The trouble is, that the situation is worse, as far as I am concerned. 
To me, MOLD is quite "hostile" actually

You are the type of programmer who will look up the IEEE754 standard 
to determine math behavior, or will write in C if necessary. You 
are not MOLD's target market :)

Wrong, I *am* MOLD's target market currently, without having any 
other choice: console forces me to read that nonsense

That is why I wrote #1634

You are misunderstanding the difference between a "market" and a 
"target market". That ticket was a good idea though.

Brian: I insist that the "newbie" argument is silly at best, dangerous 
for the language at worst.

i also think that mold/all would be better for newbies than simple 
mold, but i guess that's a matter of opinion, since nodoby did any 
experiments with a group of newbies.

I think as a newbie I try mold .. when it doesn't work, i ask here 
and the gurus say, use mold/all :)

rather than newbie, I use "the principle of least surprise"

Yep, I also think the "newbie" argument is bogus.

Oh my, more stuff to read!

Carl is trying to "undefine" ODD? EVEN? and COMPLEMENT for floating-point 
pairs. I guess, that nobody would really miss these functions for 
FP pairs. I even think, that ODD? and EVEN? are not used (of little 
use) for decimals as well. Any different opinions?

I think that I had some code somewhere that once used odd or even... 
but it's not important, because it is so rare, a person can convert 
to integer first if they want.

So, no problems. Added ROUND, which is more interesting.

Regarding all the above discussion regarding MOLD... there is an 
assumption, once that I do not believe.


The assumption is this: that any function of REBOL could ever produce 
the perfect output storage format for all data.


Or, stated another way: part of the design of building all applications 
that store persistent data is to build the storage formatters (savers) 
and storage loaders.


I don't think there's any way around this, because storage formats 
have specific requirements, such as speed of loading, indexing keys, 
resolution of references (words or other), construction of contexts, 
etc.

once = one, TTF (typing too fast)

Yes, I do agree with you, that is why I restricted my notes (or at 
least tried to) to just script preprocessing.

...and in that case we have the LOAD function, and its counterpart 
should be the SAVE/ALL function, not the SAVE function (that is essentially 
what I wanted to underline/document somewhere)

Yes, a good point.  But, and furthermore, even using LOAD instead 
of LOAD/all can be a problem for users due to its method of removing 
the outer block. An odd problem.