World: r3wp

It is similar "inconsistency/limitation" as with refinements /can-not-use-this-word 
.... I would prefer change to use /refinement in function body instead 
of word ....

... but maybe too many scripts would break ...

too many=probably all ;-)

I'm not sure why but it feels "safe" to me to have two way to acces 
data : one that return none! and one that throw an error! (even disarmed).

I used to use one or the other way in my code depending the possibility 
of missing values can happen or must not be.

So having:
- pick => none!
- value/word => error!

is good to me. I use 'first, 'second... as shortcut for the second 
case.

But if Carl want to make them works as the first case, it's OK too.

I'm like Pekr, I just want to distinguish between awaiting missing 
value (none) or not (error).

perhaps we need a null datatype ?

I thought that none is our null ....

what would be the difference other than being able to tell them apart?

only that .. need a way to distinguish.

but block is kind of storage for us ... so the trouble is, that we 
may obtain those nulls from two different reasons - as a result of 
an operation, or simply because we wrongle adress block itself ... 
not sure what we can do about it :-)

why not take advantage of FALSE, then?

what do you mean?

isn't this the issue of using an ordinal on a block with NONE as 
an element?

perhaps it should return an error.

in all cases.

which is inconvenient ...

very

whatever result is returned by an operation on the block can also 
be an element in that block.

yeah, what if your block contains an error! object?

exactly.

but then the problem exists in FIND to for example

which returns none on not found, but there we have the FOUND? to 
help us. perhaps the ordinals should use FOUND? as an indicator?

found? second [true none]

found? is just not none

I thought it was smarter than that, but maybe it could be smarter 
in 3.0

>> source found?
found?: func [
    "Returns TRUE if value is not NONE."
    value
][
    not none? :value
]

oh :-)

:-)

I use it as a shortcut for not none?

well, it would also eliminate the performance advantage that ordinals 
apparently give

then we need some flag to be settable for none? strict? none? blk/3

Perhaps we need a way to configure the behaviour we want?

if your data doesn't have none, then you can accept none for a range 
error.

I thought about it too :-) e.g. copy-by-default: true, etc. :-)

I suspect it was a mistake to allow an out of range to return none.

Too late now though ..

Regarding pair and decimals; would it make sense to generalize pair 
further into a new vector datatype, that can be any dimension more 
than one? Examples: 2.4x8.0x5.5 would be a 3D vector with coords 
(2.4; 8.0; 5.5). Like the same idea with tuples, which can be 3 or 
more bytes separated by dots: 255.255.255, 255.255.255.255,... etc.

Or should that be handles with user-defined datatypes?

*handled*

And going further, if we take the vector road, what about matrices?

Support for multi-dimensional vectors and matrices in rebcode might 
lead to something really interesting. ;-)

I think it should be handled natively

but it could get ugly quickly.

The alternative, doing vector- and matrix-math just using decimals, 
can easily be ever uglier.

Imagine having a matrix! datatype:
m: make matrix! 4x4
Then you could find the determinant like for example:
m/determinant
That would be a miracle! :-)

Suddently complicated math can be made very simple.

it would also be a miracle to be able to have a complex! datatype. 
I think electronic engineers would appreciate that

How to submit a suggestion to Carl?

feedback or comment on blog?