World: r3wp

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.

I have sympathy for the opinion against coercion, if it is a real 
problem in real applications, but I also think, coercion can be good 
in many cases.


We have == (strict-equal?), and I think, it works as == (or =) found 
in many languages, and that is without coercion. And then we have 
=, that can be seen as a loose equal with coercion. I would like 
this coercion to be extended (if it makes sense), so these will give 
true:
1
 = 1
#"1" = 49
49
 = 49
a
 = "A"
a
 = 'a

1
 should not be equal to #"1", because this is true:
(first "1") = #"1"

(Just suggestions.)

The value tested against a string should simple have a to-string 
coercion, like an integer get a to-char if tested against a char.

("a" = "A" and #"1" = 49 in my example above is already true today.)

Documentation is the most important aspect for me, so people know 
what to expect. 


I don't want = to be as loose as you do, John, but maybe a loose/load-equal? 
op could be added. It's not something I've ever felt I needed. What 
scenario(s) do you want it for?

User type something in, and you wanna check, what number was input. 
Like:

if input = 42 [print "The answer!"]

I bet, we have a lot of TO-STRING or FORM around, that could be avoided, 
if = allowed coercion with strings, like it does with chars.

Maybe we could ask, where do you use = today, where you couldn't 
go with ==
And why?

What I'm after are very good arguments to have both equal? and strick-equal?. 
The less differences between them, the better argument to not have 
both. I think, both should be there, and equal? should have even 
more coercion than today. Maybe it even makes sense to take it further 
to include blocks? Should two series with the numbers 1, 2 and 3 
in them be equal?

123
 = [1 2 3]


Why not? Today we have to put to-string in front of the block to 
make them equal.

REBOL is about being human readable. Would a non-programmer find 
those two to be equal?

Ask a user, what she typed in, and she might answer the number 42. 
She wouldn't say, she types in the string "42".

*typed*

(Sorry I'm talking so much.) .-)

Input checking is about the last place I want coercion applied. Yes, 
you can eliminate some calls, but at the risk of letting bad data 
in, and still failing on valid data. e.g.,  which of these are OK? 

1 = "1"
1 = "1 "
1000000 = "1,000,000"


What we need, IMO, is an I/O dialect that makes it easy to specify 
mapping and formatting. The problem with coercion is that it's *hidden*, 
so you have to know all the rules.

I'm totally for human readable, as you probably know, but "123" is 
defnitely not the same as [1 2 3]. It might be considered the same 
as "1 2 3" by some people, but not "123". 


What the user types in, and what the programmer has to know it's 
translated to, are two different things.

The real problems get you when you start operating on the data. Lanugages 
that use + for string concatenation (which was a big issue in VB, 
even after the & op was added), can produce completely wrong results. 
e.g., what should these produce?

1 + "1"
1
 + 1
1
 + "1"


I think Carl has removed that from R3 at this point, but I know it 
was there in a couple test releases.

All this said, I agree that it's something that should be made as 
simple as possible, but it also needs to be robust.

You touches some problem, I have, with remembering the difference 
between FORM and TO-STRING. I can't remember what these produce:
form [1 2 3]
to-string [1 2 3]

I have to try it. You have good points. What do you see as the arguments 
to both have = and == in REBOL?

at the low level does the REBOL length? function sequentially calculate 
string data when it is called to determine length or does it instead 
access a memory location ot retrieve the current length of a string?

Based on its speed characteristics, I would say that the length is 
tracked in the string and just accessed by LENGTH?.

length is read not calculated

Ok, that is what I thought Brian.

The actual implementation is not know. But given REBOL strings are 
not null terminated, it seems most likely a length is help.
A glance behind the curtain here:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlTGVC

I didn't see anything addressing it at that link but I assume you 
mean somewhere in that thread.

uh ? IIRC strings are null terminated in R2