World: r3wp

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 ?

DEHEX

>> dehex  "alcohol %26 tobacco"
== "alcohol & tobacco"

OH ?? I tried that too ... hmm.

oh well....brain not working properly !

Interesting,

>> to lit-word! first [ < ]
== '<
>> to lit-word! first [<]
** Syntax Error: Invalid tag -- <
** Near: (line 1) to lit-word! first [<]

It looks Rebol's lexical parser detects #"<" without space at the 
end as a tag!

I cannot INCLUDE script with that line (to lit word! first [ < ]). 
'include uses LOAD/ALL and LOAD/ALL changes the line to (to lit word! 
first [<]). While the first line works OK, the second one crashes.

>> load [< ]
== [<]
>> load [<]
** Syntax Error: Invalid tag -- <
** Near: (line 1) load [<]
>> load [<a ]
** Syntax Error: Invalid tag -- <a
** Near: (line 1) load [<a ]
>>

yes, LOAD is the cause.

it seems so ... but wouldn't we expect a block?

I don't expect anything, I just want to set some words for parser 
:)

so it looks like a bug to me. There should be added a condition where 
the '< is at the end of loaded block imo.

you cannot parse [to '<] but you can parse [to _lt] if _lt is '< 
....

Yes, a bug probably

The lexical parser shoul probably check for <...> in the TAG! detection 
but maybe Rebol is just checking for the first '< to be faster?

Ok, Rebolek and anyone else, Syntax errors should not be called "crashes". 
A crash is something more serious which takes down the interpreter.

lexical parser should give precedence to ] followed by a space, as 
it is a closure to initiated block, no? :-)

(me not being parse expert at all :-)

I agree with Anton - for me "crash" is when something takes down 
rebol ...

Anton sorry, I'm no native speaker, I'll take more care

No problem, just keeping terminology clear.

Rebolek: please put it in RAMBO if there isn't already present.

OK. What should be the priority to have it fixed in 1.3.3? ;)

red-icons = old time problem with timestamps we can't rely upon