World: r3wp

what do you think about these:

>> p: make port! http://
>> equal? reduce [p] reduce [p]
== true
>> equal? p p
** Access Error: Port none not open
** Near: equal? p p

or

>> a: tail [1]
== []
>> remove head a
== []
>> equal? reduce [a] reduce [a]
== true
>> equal? a a
** Script Error: Out of range or past end
** Near: equal? a a

it looks inconsistent to me and incompatible with FIND and SORT as 
well

It does look like a problem. Things like this are funny, because 
it seems like an obvious issue we would have hit long ago. :-\

ladislav, you aren't causing Carl any sleepless nights now, are you? 
:-)

no, he silently ignores my huge list

Except that I don't get the error you get on the second example.

you don't?

No. Let me try a fresh console.

Hmm. I got it this time.

it surprises me you didn't the first time

Me too. Let me check something.

ladislav, well it could be that he's incorporating fixes into R3.

Oh well, it happens every time now. Must have been something odd. 
Can't dupe it right now.

Can't dupe it working that is. :-)

that does not surprise me like the opposite did

That one comes back to the old issue of out of range indexes, which 
has been around for a long time, correct?

yes, it is an old issue, actually

but my point is, that you cannot state comparing A with A may be 
an error without asking for trouble

Agreed.

it is clearly more useful to allow comparisons as FIND or SORT demonstrate 
than to forbid them

I would say that you can't do *anything* safely on a series reference.

linked lists being an exception.

It obviously doesn't affect much code, though, or we would all be 
screaming about it.

they are easy to break and fuck up.

lists will be redesigned for R3 (with my contribution, I hope)

Re the new SWITCH proposal. ( Mezz/switch1.r). It fails in the following 
cases (due to FIND datatype searching properties):

switch-test: func [x] [
	switch :x [
		#[datatype! integer!] ["The first variant"]

  #[datatype! decimal!] #[datatype! block!] ["The second variant"]
	]
]

switch-test block!
switch-test decimal!

(the old SWITCH implementation fails for similar cases too)

I guess it would be useful to have a FIND/LITERAL refinement to behave 
differently when searching for datatypes

this is my gripe with lists:

>> a: make list! [1 2 3] clear a tail? a
** Script Error: Out of range or past end
** Near: tail? a

yes, that is an issue my proposal for lists solves

I often end up using REDUCE when dealing with datatypes that way.

yes, but here the issue is, that FIND does not allow us to implement 
SWITCH reliably

Ladislav, yes, these inconsistencies hold back rebol's reflection 
somewhat.

Maybe it's excusable for ports, though, because they are kind of 
"custom series datatypes"... have to think carefully about that.

excusable - the trouble is, that EQUAL? is incompatible even with 
itself this way, not speaking about FIND or SORT. It is too hard 
to implement custom FIND or SORT using "unreliable comparisons".

Yes, I agree. I suppose EQUAL? is COPYing the port, what do you think 
? Maybe it's just a minor implementation flaw. Can you see what it 
might be ?

By the way, I found handling all the different datatypes consistently 
very difficult each time that I've launched into doing that. It would 
help development of all sorts of reflective tools if rebol is completely 
consistent and reliable there. Search tools / debugging tools / test 
kits (all that stuff you're probably doing right now.) This is one 
of those core issues which affects so many other higher level tasks, 
it should be ranked High or Critical.

my guess is, that it may be "by design", but I don't like it this 
way

I think it may only be a side-effect of an incomplete implementation.

user poll: what do you think about RAMBO #3518?

I do admit that he has a point wrt how the help states things. if 
 there is a stated difference between  '=  and '==   then maybe the 
'= should be expanded (and explicitely documented)  for obviously 
equal values...

like char and one letter string,
$ and equivalent decimal,
 etc.

char and one-letter string is not "obvious" for me, but a more "obvious" 
thing may be a comparison of [a] versus (a) or "a" versus %a etc.

isn't a character and "one letter" the same thing semantically?

but in general I am in favor of expanding the equality, as long as 
it does not have side effects like breaking:  if, any, all

I know many people would like to expand these to include empty strings 
and 0, just like python does... but in such a case, many usefull 
uses of any/all will loose their value.

I have considerably reduced useage of if and either since I have 
truely grasped Carl's elaborate and repeated use of any/all

You have to draw the line somewhere. I think we'd have to discuss 
it on a case-by-case basis, because you can't always substitute one 
value for another, e.g. strings, files, and urls. So, even though 
it seems like two any-string! values could be compared safely, that 
might not work in our favor in real life. We could create a matrix 
and examples for duscussion; I'd be hesitant to change it without 
deeper thought.

yes obviously, and we could also add a new "loose" equality ~= or 
whatever... but in any case... all matching type-pairs should be 
explicitely explained and documented.

Agreed.

and we should decide first and foremost if its the intented value 
of the datatype which is consistent or the actual lexical form which 
is the consistent measure.

in some types this will have a lot of meaning/differentiation  ... 
take the date for example... do we equate the number of seconds, 
or the lexical textual form... or both, depending on other type pair...