AltME groups: search

sort function can sort  pairs but < and > leads error? don't you 
think it would be better if < gives same result with sort?
sort [10x4 23x2]
>> [23x2 10x4] ;sorted y-first
10x4 > 23x2
>> ** Script Error: Expected one of: pair! - not: pair!
and it is a little bit strange error, expects pair, not pair?

Sortability and sort order are (in REBOL) distinct from comparability.
See this curecode report and the response for example:
   http://curecode.org/rebol3/ticket.rsp?id=1150

in the #1150 the response is missing the point, as I see it, mistaking 
#[datatype! unset!] and #[unset!]

Ah, but that is assuming that the code is run at the top level. Judging 
by that particular code snippet, it looks like something from inside 
a function, and one that is likely in a context has 'email? already 
defined. Still, the fact that INTERN is already run on normal scripts 
(and the module equivalent run on modules) means that he likely wouldn't 
need to do this with the main contexts, just inner contexts.

This will get you a "near f" message and an arg1 code of 404, but 
 not an error of type 'user --- is that more useful?
    f: func[][ print "kuk" make error! 404]
    if error? bad: try [f] [probe disarm bad]

is there a way to get access to the main script's header within code 
you execute using 'DO

when I 
do %source.r

and source.r defined as:

 print system/script/header/title

I get the title of the source.r file... not the main script.

Well, I know, but I just mean that if functions can detect what types 
they get then making [add (something) (percent)] do the same thing 
as [add (something) to-decimal percent] seems a little less exciting 
than if it "knew what you meant".  There's sort of a dimensional 
analysis thing... adding integers and percents doesn't make a lot 
of semantic sense unless you're speaking about adding a number to 
a percentage of itself.

There was very long debate on this, when percents were implemented 
and this is the result and you should have to live with it.

Yes, Fork told REBOL to add 50% to 10. And result is 10.5 ...

Hey, it's early enough, make a proposal and submit it to CureCode. 
Be sure to check first to see if it's already there though.

And remrmber that the mathematical intuituin you mention isn't the 
same if you swap the arguments. Note that Wolfram swaps the arguments 
back if you put the percent first. That is because the intuition 
for 50% + 10 is that it result in 60%.

Intuition is a bit of misnomer here. What you are really saying is 
"expected behavior". And that is always in the eye of the peoson 
doing the expecting.

Great, now I have AltME freezes and a cat that is jealous of my computer 
- double whammy to my typing.

They get lots of people in and give them a box of fruit containing 
apples, oranges, pears

And ask like hundreds of people "go to the box and bring me back 
something that's not an apple or a pear"

And no one (who isn't a snarky programmer) brings back a pear.

How much of this is cultural and how much is some deep embedded pattern 
instinct a la X bar theory is tough to say http://en.wikipedia.org/wiki/X-bar_theory

But if things like X bar theory and these studies have merit, one 
actually can say that "right answers" aren't necessarily as fluid 
as being in the eye of a particular beholder as we might guess.

go to the box and bring me back something that's not an apple Nor 
a pear

The english language is a bit loose ... and since the incorrect way 
of saying things is so common, one assumes that what's the speaker 
meant

what's the quickest way to determine whether a series is past end 
in R2 and then handle it?

Quickest for what you test for might be:

and series? s tail? s

As a side note, I noticed, TAIL? and EMPTY? is the same. So you can 
also write the above as:

and series? s empty? s


Is it wise, that TAIL? and EMPTY? does the same? Maybe EMPTY? should 
return false, if the series holds elements, even if you're at the 
tail.

AND is an op, thus infix, and doesn't have shortcut evaluation. This 
means that you should use AND~ instead of AND if you want prefix, 
but it will still fail if s is a datatype that is not compatible 
with EMPTY? because EMPTY? s will still be called even if SERIES? 
s is false.

Henrik, can you post some code that will make a series reference 
that is past the end of a series? I'm having trouble making one that 
works consistently, and neither your INDEX? method or EMPTY? will 
work. REBGL keeps adjusting the index returned by INDEX?.

>> b: next a: "a"
== ""
>> index? b
== 2
>> remove a
== ""
>> index? b
== 1  ; adjusted
>> insert a "1"
== ""
>> index? b
== 2 ; and back again

In R3 they stay consistent, and there is an action PAST? to tell 
whether an index is past the end.
>> b: next a: "a"
== ""
>> remove a
== ""
>> index? b
== 2  ; not adjusted
>> past? b
== true


In R2 I don't even see how to write this in mezzanine without temporarily 
appending something on the end of the series (a single element will 
do) and seeing if the index adjusts, then removing what you appended. 
Like this:
>> b: next next next a: "abc"
== ""
>> clear a
== ""
>> also (index? b) < (append b "1" index? b) clear back tail b
== true  ; past end
>> b: ""
== ""
>> also (index? b) < (append b "1" index? b) clear back tail b

== false  ; not past end, but Henrik's method, and EMPTY? will both 
return true.

Here's the source to the backport:
past?: func [
	"Returns TRUE if a series index is past its tail."
	series [series!] ; gob! port!
][
	also (index? :series) < (insert tail :series "1" index? :series)
		clear back tail :series  ; Undo the modification
]

; Note: Native in R3, and non-modifying. No ports because you can't 
undo the

; insert. INDEX? doesn't stay consistent with past-tail references 
in R2.

Note: I am not sure, whether this would work with ports and gobs, 
though, since I do not know, whether SAME? behaves similarly for 
them

(which means, it would work in R2, old R2, and R3)

The not same? :series skip :series 0 line works well enough, afaict. 
Do you have a case for which it doesn't work and the larger test 
is required?

That is actually an auto-adjustment test, and I thought, that no 
auto-adjustment was taking place in R3

Well, in R3 PAST? is built-in. And auto-adjustment was taken away 
in R3 on purpose, at the same time that PAST? was added.

, and it relates to the problem better, since in the case below:

>> b
== ** Script Error: Out of range or past end


what is past tail is just the series not any "series index", which 
should be an integer value, and as such it cannot be "past tail"

I adjusted the http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Series
article to mention the past-tail series and to explain differences 
between series with fast indexed access and series with fast insert/remove 
operations.

construct exiplictely looks for the words none, true, false, yes, 
no   and replaces them with their value equivalents.

So, why is yes not evaluated but true and and on are?

Just downloaded 2.7.7 to be sure that the bug is still there and 
it is

The yes and no keywords of R3's CONSTRUCT were added at my request. 
We'll have to see whether the enhanced function can be backported 
to R2 safely. There are other changes as well, mostly safety changes, 
and a CONSTRUCT/only option that turns all of the tricks off.

Bug#651 details the changes - yes and no keywords, and unset-to-none 
translation - and bug#687 explains CONSTRUCT/only.

We'll have to see if there is any R2 code that will be broken by 
the change; if so, it won't happen. As a rule, backwards-incompatible 
changes are only made to R2 when they can be proven to not harm legacy 
code. There have been a few exceptions, and at least one mistake 
that predated (and inspired) the rule, but the exceptions have all 
been added functionality that doesn't change old functionality that 
is relied on in code. If nothing relies on yes and no not being keywords, 
or unset! values not being translated to none, then we're cool. As 
a counter-example, CONSTRUCT/only could be backported without question 
because it's a new option.

What is the easiest way to prevent sub-object sharing? I have very 
simple but nested XML structure, and I want to put records into objects. 
But I have one subobject. I want to have prototype object (class) 
and create instances filled with data, but I want to avoid subobject 
sharing ....

simply put: proto: context [name: none address: context [street: 
none]], and now I want to make instances, but those should not share 
address subobject ...

I put an init function in the class, and do any stuff there, then 
its much easier to manage.

a: make class [init]

yes, my above one-line constructor func scales very well, since you 
can call new on sub-objects too, and it will take care of any things 
like creating empty new blocks and formatted strings on the fly, 
within the init func.

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.

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.

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.

Are you kidding? Try to load any script and save it

...and, being at it, what does that "ugly" mean?

#[true]

 is a normal REBOL syntax, since REBOL is a language, and LOAD as 
 well as Lad recognize it.

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

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.

They do? Then, would you be so kind, and explain to me what is the 
purpose of SAVE? (I never found any)

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.

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.

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.

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

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

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

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.

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

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?)

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.

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.

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

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?

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

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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

the whole point of MOLD and SAVE is to be a pretty-printer

 - looks true for MOLD, but SAVE does not print, so this does not 
 apply in any reasonable sense

As I said, I can actually live with it, but, what I am unable to 
live with is, that this gotcha is nowhere documented, and it is a 
gotcha par excellence, as demonstrated

Andreas, which platform are you using? That is a serious platform-specific 
bug you are demonstrating there, and should be reported.

No need to put it to CC, the code that generates the string was written 
by me (both for Linux and for Windows), and I did my best

The behavior as designed in R3 is this:
>> mold 0.1
== "0.1"
>> mold/all 0.1
== "0.10000000000000001"

This is because 0.1 is not directly representable in a IEEE754 value. 
If it does not work this way on a platform, then the platform code 
is broken. And you, Ladislav, were the one who made the rule in the 
first place.

Andreas, it is the latter. The decimal! type is designed to use single-precision 
floating point. And that behavior is in the standard (according to 
Ladislav, the last time this discussion came up a year ago or so). 
I told you the decimal! type was misnamed.

0.1 and 0.10000000000000001 are represented differently in single-precision 
IEEE754.