World: r3wp

I am just a bit concerned that some functions should be too pure 
to return alternate values when input is not "perfect".

this is like to-integer and as-integer.  the later could ALWAYS return 
an error, even when the input is obviously wrong and return 0.  but 
to-integer should either return an integer, raise an error, or maybe 
none instead... which is gradually being accepted as a softer error 
value... llike the switch to first/second... etc.

I understand your arguments. But let's take a look at the following 
example:

    abs -2147483648


The -2147483648 is a result in the C language (using wrapping). Python 
uses a "larger" datatype and raising an error is yet another option. 
All three variants are "reasonable" in a sense, but we may pick only 
one of them.

I must say that I "don't like" -2147483648, because it violates the 
fundamental mathematical principle, that ABS cannot yield a negative 
value.

If we accept 1 / 3 = 0.333333333333333 (which is mathematically sound, 
because all integers *are* real numbers too), then we should apply 
that to the ABS case as well and say, that abs -2147483648 = 2147483648.0

Python uses this "philosophy", except for the fact, that it uses 
bignums instead of decimals

indeed within mathematical operations, there is acceptible leniency 
in a "pragmatic" language like REBOL, and I agree completely.

but as you say about abs, there, the return value is the result of 
a mathematical expression.  so it is consistent throughout REBOL 
maths, that some equations return decimals, when values go out of 
range of integers.... just like power 2 32

actually, power 2 0 yields a decimal!, even though it might return 
integer! (but this is more efficient when comparing code size)

people who code in C are programmers.  there is no doubt about it. 
 and indeed, if they choose C, there are reasons, and they expect 
a harsh and unforgiving environment.

hehe

yes, Max, REBOL is and should remain more friendly, than C

we must just not forget the intent of the functions first and foremost. 
 if harsh and possibly faster algorythms are needed, I am all for 
it, but these should get specific names... pick and poke, ocome to 
mind as alternatives fewer of use use.

so for maths, I'd rather have a function which does not go haywire 
like the wrapping which can occur, which you describe, even if its 
slower... simply because its completely out of the reach of the reason 
of why I use REBOL to have to understand this.

hehe, I might seem to contradict myself wrt the whole to-integer 
thing, but the fundamental function of to-integer and make integere 
are getting an integer out of some other possibly compatible values.

I do agree with you completely.

its a bit like the law, there is the letter of the law, and the meaning 
of the law.

procecution and defence will try to bend the judge or jury towards 
one or the other... using the same text.

:-)

we are at a crossroad (R3) where we can pick the best direction, 
that is why it is time to ask these questions

so we must not get lost in proceeedings when the intent is so clear, 
even if precedents would tend to make us think we should continue.

yes.

do you agree about a panel at devcon 2007 for some of the more pointy 
issues?

i guess, that it may be too late for these issues

I would hope R3 beta/alpha would last a while for such issues to 
be compared empirically.

well, but some code needs to be written and we cannot prepare all 
variants

the equality for example...  testing it out in code would surely 
help, but deciding for sure, could be left at the devcon...

this might also raise REBOL's case about it not being a totally closed 
source effort.

My big issue with stuff like this is how people will use these kinds 
of examples to show how "stupid" REBOL is, and make them reasons 
not to use it, and to drive others from using it. e.g. "if it can't 
even return a positive value from ABS...". Doc'ing the behavior, 
even pointing out that it's more akin to how C might work, will go 
a long way toward that, but maybe not all the way.

I don't understand - there is no ideal way. The best possible way 
is to use one general principle. Such principle may be to let the 
arithmetic work like the C language arithmetic does (use wrapping 
for integer arithmetic). Another principle is to use the "Python 
principle" - use a "more general datatype", if the original datatype 
is unable to represent the result. And the third alternative is to 
cause an error if the original datatype cannot represent the result. 
I think, that the slowest is the "error causing principle". The most 
unsafe is the "wrapping principle". The "more general datatype" looks 
like the most comfortable.

I agree, we must not think in terms of how C does it, this would 
be a step backwards.  REBOL is more natural than that...

BUT as I said earlier, this must not contradict the first principle 
of an expression's meaning.  if abs means "return a positive VALUE" 
then that's what it should first and foremost.

note I use the word VALUE, not int, not decimal... this lets the 
whole be consistent and precise.

I looked up the ABS description. It is quite funny: "Returns the 
absolute value."

I might have used number instead, in REBOL's pov this is even more 
precise as you can then expect to use number? on it.

hehe

on a completely other note, I'd really like for rebol to adopt IM 
protocols.  did you know that a recent survey here showed that only 
30% of teens use e-mail?

and they only do so to interact with 'old people.

like teachers, parents and employers.

if we could actually code IM apps as easily as we can send mail, 
then REBOL would Definitely attract attention to a younger crowd.

(this is a suggestion for R3)

hehe,

to-logic "false"
== true

try to convince non REBOL users why this is logical... and well, 
I think you are on the bad side of the discussion  ;-)

I think this whole mess needs to be explicitely dealt with and exhaustively 
documented, in R3 in the least.  right now, I'm realizing that  these 
issues permeate REBOL and they are probably the only real inconsistency 
in the language.  Each type seems to have its own understanding of 
how to treat an input value... its probably quite frustrating for 
novices, IMHO.

Maxim - about protocols - that's why I wanted something higher-level, 
like Uniserve being inbuild. We should not develop protocols from 
scratch, but plug them into some existing architecture, which does 
multiplexing without the need for the dev to think how to achieve 
it ...

I've forgotten .. how to restore a url encoded string ?

like this one ..  "alcohol %26 tobacco"

is it decode-url  ?

nope

errr.. perhaps there isn't a native function to do this ?