World: r3wp

Pekr, Bacon has been doing good work, and the wiki is getting prettier 
:)  But there have been a few factual errors on those pages...

NFOREACH would take 3 arguments, not 2, just like FOREACH.

I'm not sure about the name though.

BrianH: I don't agree. While he is doing really a good work, he also 
completly ruined some stuff. He restructured Carl's docs so that 
they don't make much sense and he intermixed it with Gab's former 
VID docs, not understanding VID3 and VID 3.4 are different things. 
That fact alone is totally confusing ...

I can help him to point out few things, but dunno how to contact 
him ....

I'm not assuming it's a him until I see a full name. The factual 
errors can be cleaned up as the GUI design progresses, no worries. 
In the meanwhile we have a new doc structure and examples of formatting 
to copy, so I'm grateful. This does illustrate my point about the 
difference between a wiki and a manual though.

Factual fixes I can handle (with available time). Formatting fixes 
are much more difficult - don't know Wikimedia. Not the docs guy 
though.

Brian: i was not comparing wiki to docs. I was comparing wiki to 
chat. If i need to restate do in chat, why is the wiki there?

Brian: I don't like it that way as then you have to keep in your 
mind the relationship between words and blocks; furthermore, please 
name me one case where you wouldn't need reduce. A function that 
*always* needs reduce is badly designed. :P

Gab, sorry, I thought you were talking about DocBase (as others were) 
rather than the parse proposals. The reason I mentioned the chat 
is because you keep bringing up the DO operation as if you are trying 
to convince us of its importance, but we all agree with you so it 
doesn't help. I was trying to point you to a forum where trying to 
convince someone about a parse proposal would have some effect.

As for the Parse Proposals wiki, I'm afraid it will need some cleaning 
down. I kept trying to tell Peta the rules Carl set up, but Peta 
kept ignoring them and going into great detail about parse theory 
and such. Half of the contents of that page are going to have to 
be moved to other pages, and I'm probably going to have to summarize 
the best of the proposals to Carl if we want to convince him to implement 
them.

You have a good point about the nforeach reduce thing, but I am not 
convinced that giving up the ability to generate the data in other 
functions is worth it. I usually don't like to see DO/next in mezzanine 
code anyway: DO/next is usually a sign of a function that doesn't 
work in a REBOL-like way and has too much overhead to use. However, 
I still want Carl to fix DO/next in R3 - it doesn't work at all at 
the moment, and there are some proposed functions that can't be implemented 
without it.

to me do/next is just a sign of a dialect :-)

maybe too many dialects is bad, but i personally think it's worth 
trying.

I have a 'case like function that uses 'do/next

Like case, but inverted (performs the block if the result is false). 
 It'd be easier to implement using [block block] or [paren block] 
pairs, but would not be as readable - imagine the same with 'case 
?

Chris, that sounds like a good job for DO/next. It also sounds like 
a function that would be replaced by CASE [NOT ... when the code 
is being optimized. REBOL programmers can be pretty ruthless when 
it comes to hand-optimization, so one of the goals of R3 is to make 
the mezzanine functions powerful and efficient enough that they will 
actually get used rather than optimized away, and to make native 
the functions that need to be. The hope is that the users of REBOL 
can just use functions and trust that they will be efficient, rather 
than having to manually inline code all of the time.

Yey to that!

Is there a script around that decodes entities such as & etc 
?

rebol.org   web-to-plain.r  handles a lot of them.

http://box.lebeda.ws/~hmm/rebol/htmlentities_latest.r

(converts to utf8)

thanks.

Is this logical behaviour? (Has it been discussed before?)

>> #"a" = 97
== true
>> switch #"a" [97 [print "found!"]]
== none

Inconsistent, perhaps.  Perhaps the first case shouldn't be, but 
can be extra useful (as can #'a" + 5)

I'm not sure about you're example but this would definitely seem 
to be a bug:

>> #"a" == 97
== true

The R3 behaviour is: 

>> #"a" == 97
== false


>> #"a" = 97

== true

I get:

>>  #"a" == 97
== false

in R2...

The implicit type convesion in evaluating #"a" = 97 is consistent 
with the help text :

>> ?
 =
USAGE
:
    value1 = value2
 

DESCRIPTION:

     Returns TRUE if the values are equal
. 
    = is an op value
.

ARGUMENTS:

     value1 -- (Type: any)

     value2 -- (Type: any)

I forgot that I was running 2.5.6 :-)

However I would ask why there is not an imiplicit type conversion 
in 

>> #"a" = "a" 
   
== false

Likely as char! is not a series type?

Seems a stretch as to-char "a" works, and to-char "ab" returns an 
error...

The implicit type conversion needed would be to change the char! 
to string! so as not just to compare the first element in the string!.


It would be a nice feature, but not essential. What would be helpful 
would be haivng the implicit type conversions doucmented.

It seems that there mat be a bug in R3:chat 

>> to char! "ab"

== #"a"

Would it make sense to let this return true?
1
 = 1

There is a trap here, because we easily run in circles with char, 
string and integer. There are some special rules about char!, and 
it's probably hard to deside the best design.

In other words, would it make sense to compare apples and pears? 
We kinda do that with char and integer now.

I'm not sure that comparing char! and integer! is comparing apples 
and pears. Given that Rebol is written in C, it is most likley that 
internally it is stored as a char which is simply a single byte integer.

As for  "1" = 1 returning true, there is a case for implicit type 
conversions. Perhaps not a strong one, but the help text for = does 
imply that test is for equality regardless if type.

The implicit type conversion would need to be:

>> "1" = to String! 1

== true

The case for such implicit type conversion is somewhat strengthened 
by the existance of the == function.

But you see the problem, if
#"a" = "a"
and
#"a" = 97
then
a
 = 97

which doesn't make much sense. But it could be a nice thing to have 
some of those implicit type conversions.

I agree, that the explanation for = isn't clear. Also because of 
special cases like:
>> "abc" = "ABC"
== true

Same can be said about ==:
>> "abc" == "ABC"
== false

It's the definition of the word "equal", that is a bit confusing.

Would it make sense to compare objects? Why not when blocks can be 
compared?

>> b: [1]
== [1]
>> b = [1]
== true
>> b == [1]
== true
>> b =? [1]
== false
>> o1: context [a: 1]
>> o2: context [a: 1]
>> o1 = o2
== false
>> o1 == o2
== false
>> o1 =? o2
== false

http://www.rebol.net/wiki/Datatype_math_compatibility_tables


Those tables were generated programmatically, so I don't recommend 
editing the wiki manually. The idea is that running the generator 
will produce results based on acutal behavior. 


If we care about which version, that will need to be added, and we'll 
need a way to deal with the information. e.g., run under multiple 
versions and aggregate the results.

As much as it seems like adding coercions support would help, IME 
it only helps in *very* simple scenarios, and can lead to problems. 


As a historical note, when Visual Basic added the Variant data type, 
it started down this road and went so far that it eventually spawned 
a petition of "VBers against Evil Type Coercion".

Interesting, Gregg. "In Python 3.0, coercion will not be supported." 
See:
http://docs.python.org/reference/datamodel.html#id5

Gregg: The table is great thanks. 


One small question, that started this thread, is char! compatible 
with integer! when:

>> same? #"1" 1

== false

>> same?
 #"1" 49

== true


The behaviour make sense based on an understading of character encoding 
but may appear incorrect at a higher level.

The entry in the Rebol dictionary for the = finciton  explains that 
it is case insensitive. == should be used for case sensitive equality 
checks.

The table suggests that, apart from a few exceptions, Rebol coerces 
numeric types and not non-numeric types. If this is the case, it 
would be good for this to be documented.