World: r3wp

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

Good conversation though.

Steeve, you can put ^(00) in strings in R2 and R3. They get converted 
to null-terminated for calling C routines, but they aren't internally.

But sticking to R2 and putting aside conversion to c routines, are 
you saying that R2 doesn't terminate strings with null?

hum... internally, strings are null terminated, i don't know the 
use, but it's a fact

Yes.

Steeve, have you disassembled REBOL?

not fully

some parts

Well the use for terminating the strings would be for determining 
length.  Otherwise you would have to determine length by updating 
the length value on each change of the string.

Which is what I hope is that case actually.

Paul, there are the two of them: length is stored, but strings are 
null terminated

iirc

Steeve, you can put nulls in the middle of strings and their length 
doesn't change. Thus, not null terminated.

i know it's not used, but really i saw nulls at the end of strings

They may have nulls tacked on the end after the tail of the string 
for C compatibility, but REBOL doesn't use them.

i agree

Is there another form of termination that might not be nulls that 
REBOL uses?

Otherwise length? would be O(n), and my testing has found it to be 
O(1) for avery series type except list!

REBOL uses something like Pascal strings with nulls tacked on the 
end for C compatibility. The length is tracked on write.

Well, if REBOL allocates storage for a string then there might be 
a maxlength value stored along with a length value.

Such that length? is returning current length.

A string use several slots of 16 bytes length.
by default, an empty string uses one slot (16 bytes).

If you define a string of 16 bytes length. then, the string uses 
2 slots because the null char at the end of the string can fit in 
the first slot.

*(can't fit)

They are continous slots of course

Are you referring to R2 or R3? R3's strings are different.

R2