Rebol Values vs. Human Values #2:

let's have a look at the following example:

a: []
probe a
insert a 1
probe a

Rebol console:
>> a: []
== []
>> probe a
[]
== []
>> insert a 1
== []
>> probe a
[1]
== [1]

What are we looking at? Probably everybody feels, that we are probing one
Rebol Value twice and are seeing two different Human Values. (I
intentionally didn't define Human Values, but don't be afraid, the end of
the tunnel is approaching.)

Now a definition: the Rebol Value is mutable, if it can acquire at least two
different Human Values. The Rebol Value is immutable, if it isn't mutable.

Now the bad news: a mutable Rebol Value is not a Human Value.

And the good news:  an immutable Rebol Value is a Human Value. (you can see
it immediately from the definition)

now other interesting statements:
(i) any number is immutable Rebol Value
(ii) any date is immutable Rebol Value (proven by Joel)
(iii) any time is immutable Rebol Value (proven by Joel)
(iv) for the immutable Rebol Values there is no need to have the Same?
function, because the immutable Rebol Values are the same as long as they
are equal in a common sense
(v) for an immutable Rebol Value it doesn't matter, where in the memory it
is stored, which means, that Ted doesn't have to worry about the contents of
integer value and simply say integer value instead

Mutable Rebol Values and the Human Values.

The Human Value of a mutable Rebol Value is actually its current state.
(surprised?) Let's try to describe the current state of the block seen at
the first line of the example code above:

"it is a rebol block having position 1 containing no elements; the
representation of its head is stored at position xxxx in the computer
memory"

To be continued...

Ladislav

Reply via email to