World: r3wp

A question from Carl: 

Should #877 just cause an error (infinite cycle):

a: copy []
insert/only a a
copy/deep a

as far as I am concerned, this looks acceptable

Domain of EQUAL? EQUIVALENT? STRICT-EQUAL? and SAME?: currently they 
are declared to accept all values except for #[unset!] Any proposals 
for change?

>> b: tail [1 2 3]
== []

>> clear head b
== []

>> same? b b
== true

>> equal? b b
** Script error: out of range or past end
** Where: equal?
** Near: equal? b b

** Note: use WHY? for more about this error

the above was yet another domain-related example. I can imagine the 
EQUAL? example to yield TRUE as an alternative. Which one do you 
prefer???????

I think this is just about performance. SAME? has a simple job to 
do to see if two values are the same. EQUAL? investigates in more 
depth, and then discovers the range problem. This seems like a good 
implementation and I like the current behaviour.

EQUAL? is used more often by newbies and people doing quick programming. 
Such people would be better served by the error.

I'm considering the concept of neutral values: Empty blocks, empty 
strings, zero, true and generally what is default made with MAKE 
<type> [].

It comes from typing this alot:

	all [
		val
		block? val
		empty? val
	]

which would be equivalent to:

	neutral? val

It may be a bad idea.

Why should  equal? b b yield a error?

Just because it gives back an error in R2, but there also b alone 
gives back an error.
The current behaviour in R3 is much better.

It yields an error in R3 too. You *want* that error because it tells 
you that you have bad series references. You want to know that.

No, it does not give an error in R3.

>>  b: tail [1 2 3]
== []

>> clear head b
== []

>> b
== []

EQUAL? b b gives an error in R3, as does = and ==.

No "but there also" related to EQUAL? in your statement, so that 
was the assumed subject of  "The current behaviour in R3".

EQUAL? b b causes an error. The value of such an error is doubtful, 
taking into account, that e.g. the MOLD function accepts the series 
happily, in an incompatible manner. So, what is "more useful"? To 
cause or not to cause? My personal opinion is, that the value of 
causing the error is totally negligible even for the beginners. (the 
EQUAL? function is not meant to be used as the function supposed 
to be used for such checking)

I'm not convinced that the lack of an error with the straight b reference 
is good either. It seems like a good error to throw.

If we examine the "nature" of the implementation of REBOL blocks, 
then we come to the conclusion (at least I do), that the "abstraction" 
is as follows: (at least when we examine the PICK function): a block 
is an "essentially unlimited" series of values, the majority of them 
are  #[none] s, except for a limited "segment", which may "contain" 
other values as well

There is a lot of correct code that would assume that
>>greater-or-equal? length? head b index? b

If this is ever not the case and I try to retrieve a value from that 
reference before that condition is true again, that is a serious 
error. If you fill in the missing data before you attempt to retrieve 
anything, not an error.

So, either b is an error in R3, or INDEX? is an error (which might 
be the case).

So we could either have INDEX? be an error, or unstable. Which do 
you prefer?

PICK happily allows you to examine any position, so a code that works 
in a manner incompatible with PICK is violating the block design 
principle IMO

I'm OK with declaring that bounds don't matter, and that INDEX? is 
not an error. The rationale for the new series bounds model was my 
idea, anyways. And having =, !=, == and !== (and their actions) not 
generate an error is consistent with that. Just taking the devil's 
advocate position :)

moreover, the INDEX? function does not show you an error.

as long as the index can be used as such.  using an object for the 
index should raise an error.

using an object for the index should raise an error
 - you mean e.g. poke 4 index, when the index is "out"?

sorry, I mean poke block 4 index

Ladislav, my point was that if bounds matter, INDEX? *not* generating 
an error (or changing its results) for an out-of-bounds index *is 
itself an error*. If bounds don't matter (except apparently for POKE), 
then INDEX? not changing its behavior is fine.

aha, so you examined the possibility to change the INDEX? behaviour 
as well

my experience tells: it is better to be able to find out what the 
value of INDEX actually is (even for debugging), than to obtain an 
error, which does not tell me where I actually am

Yeah. However, consistently not caring about out-of-bounds on read 
seems more useful. We only care on write.

(that was in answer to your last message)

(AltME is slow for me today)

henrik:  the neutral? is very usefull, python uses that as the false 
values.


when everything is coded using this it simplifies a lot of code, 
even more than using none.

I have often wondered what the name for the function would be.... 
'NEUTRAL?  is not bad!

(altme is fast here. (very))

I prefer REBOL's false/none treatment to Python's, but that NEUTRAL? 
sounds good, especially if it also checked for unset values, and 
SERIES? instead of BLOCK?.

its just different allows different optimisation of conditionals. 
 neutral? can be very usefull, especially for GUI handling code... 
where you usually don't care for the type, but only if a value is 
meaningfull.

my name for the function was:   meaningfull?

I have not thought it through that much, other than figuring there 
would have to be a way to shorten that code to one step. I have compiled 
a list of neutral values for all types, that are capable of producing 
neutral values. Some can't, and I wonder what the response to NEUTRAL? 
would be there.

the lack of datatype screening might be a problem.

It could take a datatype/typeset parameter (probably the first parameter 
of two).

Internally you could even convert the datatype! to a typeset! and 
use FIND; since typesets are immediate there would be no overhead.

why should be this 
>> equal? b []
== true
but 
>> equal?  [] b
** Script error: out of range or past end
** Where: equal?
** Near: equal? [] b


equal? should just compare the two params, but not test if they are 
in in their own limits.


As I understand this, blocks are containers and empty containers 
are equal from the outside.
Even errors should be equal.)

seems, that Carl agrees with you

btw - as for 'arrays - will there be any change in R3? I never use 
them, as I worry they are slow (mezzanine). Now with vectors, blocks 
and arrays - do we have fast multidimensional arrays and vectors?

It is possible that vectors will get multidimensional addressing 
- it is sort-of planned to do so, but nothing concrete yet.

I don't understand: "I never use them, as I worry they are slow (mezzanine)."

REBOL doesn't really have multidimensional arrays. There is an ARRAY 
function that creates nested blocks (which is as close as C gets 
to multidimentional arrays too), but once created they aren't mezzanine, 
they're a data structure.

Once the data structure is in memory, it doesn't matter whether it 
was created with a mezzanine or a native - all that matters is what 
kind of data structure it is. The nested block style is better for 
some things (data structure manipulation, flexibility) but worse 
at others (vector math). You make your tradeoffs. At least in R3 
you have a choice :)

If I understand it correctly, Carl is leaving for vacation in France 
at the end of the week. So - what last minute fixes do we request, 
before Carl vanishes for 2 or so weeks? :-)

Nothing. Better let him finish up what he was doing.

Do you think fixing another 20 tickets, or releasing plugins finally? 
:-)