r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Henrik
10-Jul-2010
[17294]
remember to MOLD/ALL if you don't want to lose information.
Demitri
10-Jul-2010
[17295]
I have r2 question.  I wont to convert integer value to binary but 
it comes out wrong.  Some tell me how?  The integer is above 255.
Graham
10-Jul-2010
[17296]
Tell us what you are doing
Demitri
10-Jul-2010
[17297]
I trying to convert integer value to binary.
Izkata
10-Jul-2010
[17298]
>> debase/base to-hex 512 16
== #{00000200}
Demitri
10-Jul-2010
[17299]
thx you Izkata.
Anton
10-Jul-2010
[17300]
Dope doesn't work that well.
Ladislav
14-Jul-2010
[17301]
I think, that everybody processing REBOL strings using REBOL shall 
be aware of CureCode #1632. I should probably write an article about 
the subject somewhere to make life of at least some people easier.
Anton
14-Jul-2010
[17302]
Yes, it's a pity MOLD isn't the one which is the least "lossy" (vs 
MOLD/ALL) when it comes to serialising.
What can be done about it at this stage, though?
Maxim
14-Jul-2010
[17303x2]
thing is load isn't the counterpart to mold.  'DO is.   and even 
then, even MOLD/ALL isn't a real serialization because shared objects, 
or series aren't shared anymore.


although they go a long way, and I have been using them extensively 
in many tools, MOLD & MOLD/ALL are just helpers, destined for advanced 
users who have very special requirements.
we need to build a REAL serialization dialect, one which rebuilds 
the data sharing, even in nested and co-occuring references to series 
and objects.
Steeve
14-Jul-2010
[17305]
it's rebin
Maxim
14-Jul-2010
[17306x2]
but we should not be forced to use a binary dataset for such things. 
 it can be expressed in source format.
just added an (very succinct) extended serialization example which 
would allow us to basically fix all the MOLD issues on LOAD directly. 
 it could be the basis for rebin, which could just be a compressed 
version of the source version to keep it (very) small.
Steeve
14-Jul-2010
[17308]
just added ?
Maxim
14-Jul-2010
[17309x5]
to curecode.
as usually, all datatypes would need to support this extended format, 
but since it would be managed directly within the native datatype 
handling it would be MUCH faster than if we tried to build some dialect 
for it in REBOL.  especially since the native has much more direct 
access to things like same?, and internal states like series index.
I have done some work on this to support reloading of shared & nested 
objects specifically and its easy enough to do (for me ;-), but it 
requires some deeper understanding of REBOL.


I agree with Ladislav, though, that serialization should be addressed 
more "completely" at some point, directly within the language. 


IMHO, The current implementation isn't a "bug" but rather an annoying 
limitation which has been known and put off as a "to do" for years, 
by everyone which is capable of solving it.
(cause its a very tedious and "not fun" thing to do)
also, there are nasty binding issues on serialization...  things 
like:

---------------------------------
a: "data"
f: does [print a]
o: context [
	a: "other data"
	f: does [print a]
]
set in o 'f :f
---------------------------------


how is this treated in MOLDing ?  these are hard cases to choose 
from a variety of paths, if we serialize only the o  object, then 
its f method is pretty much broken in current REBOLs.   

how would we handle this?  there are a lot of ways to play with the 
above, but no single method will ever cover all possibilites.  


so in the end, the serialization will never be "perfect", unless 
all data items are signed with a unique key which is retrievable 
at run-time and reusable at each interpretation (pretty much impossible).


IMHO all we can do is properly document  what can and cannot be serialized 
without risk of data corruption.  Currently, official & explicit 
documentation on this is vague at best.
Ladislav
14-Jul-2010
[17314x2]
Max, I had a specific issue in mind: (pre)processing of REBOL scripts. 
In that case, you we not need to worry about such issues as binding, 
shared objects, etc. I am quite comfotable with MOLD, since it does 
not look like a gotcha to me (not that I want to repeat that "MOLD 
is not a counterpart to LOAD" mantra), but SAVE clearly *is* a gotcha, 
since nobody sane would expect it to "distort" REBOL script when 
saving REBOL code obtained as a result of LOAD.
you we not
: "we do not"
Maxim
14-Jul-2010
[17316]
in R3, there is save/all which stores in serialized format, which 
might solve that particular case (saving a whole script)
Ladislav
14-Jul-2010
[17317]
{I agree with Ladislav, though, that serialization should be addressed 
more "completely" at some point, directly within the language.} - 
I do not need that, especially not in this case; but I do want to 
help people to not get caught by the bad design decision making SAVE 
inadequate for the task it is supposed to perform.
Maxim
14-Jul-2010
[17318]
actually it seems even R2 has /ALL refinement.
Ladislav
14-Jul-2010
[17319x2]
Yes, that is not a problem, problem is, that almost everyone would 
expect SAVE to be adequate.
Ceterum censeo Carthaginem esse delendam

 - the SAVE function (especially in R3) should work as SAVE/ALL does, 
 while the "gotcha functionality" should be discarded.
Maxim
14-Jul-2010
[17321]
but SAVE/ALL will distort the output such that many values such as 
true and none  will be written in their serialized (and ugly) format 
of #[true] and #[none]  so that is not optimal either.
Ladislav
14-Jul-2010
[17322x2]
Are you kidding? Try to load any script and save it
if you use SAVE/ALL you obtain the code, that is as close to original 
as possible
Andreas
14-Jul-2010
[17324]
Maxim:
>> mold/all load "foo: none"
== "[foo: none^/]"
no distortion here
Ladislav
14-Jul-2010
[17325]
...and, being at it, what does that "ugly" mean?
Maxim
14-Jul-2010
[17326]
aahhh yes... loading doesn't convert the word tokens to their values, 
so they do not get converted to #[none]... they are still words... 


though all the comments disapear... which is understandable in this 
case.
Ladislav
14-Jul-2010
[17327x3]
serialized

 is an inadequate notion as well, would you call "0.10000000000000001" 
 "serialized"?
#[true]

 is a normal REBOL syntax, since REBOL is a language, and LOAD as 
 well as Lad recognize it.
:-p
Maxim
14-Jul-2010
[17330x2]
yes, but its the "mechanical" syntax which is meant for the interpreter, 
not humans... Part of the reason I use REBOL is that I don't have 
to use machine syntax.
if you had a pre-processor which converted all none to #[none]... 
first thing I'd do is stop using your tool   ;-p
Ladislav
14-Jul-2010
[17332]
mechanical

? - it is the only syntax allowing me to write a logic! type value 
in using the Data exchange dialect. There is no other way how to 
do it.
Andreas
14-Jul-2010
[17333]
#[none] is the only literal representation of the corresponding abstract 
object
Ladislav
14-Jul-2010
[17334x4]
Why the "converted none to #[none]" - that is exactly what *I* am 
against
In the DED (Data exchange dialect) none is a word, nobody wants to 
transform it to a value of a different type, and it actually never 
happens
...as Andreas demonstrated above, so why to pull out that strawman?
Generallly, "preprocessing REBOL scripts" means to work with the 
DED, not with the DD (Do dialect)
Maxim
14-Jul-2010
[17338x2]
but one must understand that when you LOAD data, no evaluation occurs, 
which is why serialization into litterals does not occur. 

this is a big detail, which most REBOLers do not grasp.


the litteral notation allows you to load items AS data, not as DO 
dialect source code.


I guess what could be done is to remove the /ALL refinement and add 
a new refinement which forces the non /serialized format.  but that 
makes SAVE work opposite of other serialization handling ... which 
is why I'm not sure that is such a good thing.
for data exchange, I really think that a deeper serialization is 
required.   even MOLD/ALL is inadequate for any serious project. 
 I've been bitten many times.  things like recursive object molding 
or breaking can occur.  ex:

>> a: context [b: none]
>> b: context [a: none]
>> b/a: a
>> a/b: b
>> mold/all a
{#[object! [
    b: #[object! [
        a: #[object! [...]
    ]]
]]}
Ladislav
14-Jul-2010
[17340]
but one must understand that when you LOAD data, no evaluation occurs, 
which is why serialization into litterals does not occur.
 - this looks like a confused statement to me. Example:

mold/all load "true" ; == "true"
mold/all load "#[true]"; == "#[true]"

There is no rocket science involved.
Maxim
14-Jul-2010
[17341x2]
in your first line... the loaded value is a word, not a #[true] value... 
but people don't get this.
it becomes obvious to advanced users, cause we've had to go deep 
into the bindology, but casual/intermediate REBOLers se all the datatype/binding/loading 
stuff as magic.
Ladislav
14-Jul-2010
[17343]
They should read http://en.wikipedia.org/wiki/REBOL#Syntax