Hi, Ted,
just a few remarks, if you don't mind (no flames intended).
I tried to prove, that as long as the value is immutable, there is
no need to worry about the storage.
The interpreter can store it as many times and at as many places
as is preferrable, without worrying about the consequences. That
means, that it can maintain an integer value 5 only once, if the
decision is to spare the memory, or it can store it 25 times, if
the speed is preferrable. It doesn't have any influence on the
results. (My personal guess is, that when comparing: same? (2 + 3)
(4 + 1) the results of addition are stored at two different places
in the computer memory, because it's much faster.)
How did I find out, that the integer value 5 is immutable? I
looked at all core functions and found out, that none of them can
modify an integer value (have a look for yourself, if you don't
find it too boring).
How did I find out, that Rebol blocks are mutable? I looked at
Change, Insert, Append, Empty, Remove functions, that modify
their block argument. That is why Rebol blocks are mutable, there
is no other reason.
Now about immutable blocks:
I wrote a Rebol implementation of immutable blocks and it is not
that hard. There is only one problem, if you write it in Rebol:
how to make some attributes private.
If you try to implement immutable blocks, you have to create this
set of functions:
empty-IB ; a function, that creates an empty IB - elementary
operation
prepend ; a function that prepends a Rebol value, i.e. creates a
new IB with one element added at the beginning, without modifying
its argument - interesting is, that it was elementary operation -
no copying of elements was needed, as with mutable blocks, where
inserting element may make necessary to move all elements
previously stored, which is time-consuming
next-IB ; a function, that creates a new IB, essentially its
argument without the first element - elementary operation, no
copying needed - a counterpart to prepend
IB-empty? ; a function, that tells you, whether the argument IB is
empty - elementary operation
IB-first ; a function, that returns the first element of its
argument, without modifying it - elementary operation
Other (non-elementary) functions can then be easily created with
the help of these "elementary 5". Notice, that the function
copy-IB is totally useless, because there is no need to copy
immutable blocks. Instead of the copy you can always use the
original. Similarly same-IB? is useless, because it gives the
results that can be obtained by equal-IB?, which is easy to
implement with the help of "elementary 5".
Of course, if you want to have an IB with a different element, you
will have to create a new IB, which may mean to copy some elements
even if their value will remain the same.
The algorithms using IB's can be found in some textbooks and, in
some cases, they are more effective than their mutable
counterparts.
Ladislav
> Hi, Ladislav,
>
> I think the key point is that REBOL is polymorphic and handles
scalar,
> series, and constructed values in different ways.
>
> We are told that REBOL unsets a word before setting it. So then
it must
> be true that I cannot change the value, I can only set the word
to
> another value.
>
> In the case of scalars, I guess you are saying that there is
only
> really one "instance" of each scalar value, and any word with
that
> state refers to that one "instance". (No flames on the term
instance,
> please.)
>
> This would be because all scalar values can be predefined, since
that
> is what scalar means. And this is why all scalars with the same
> apparent state are considered both the same and equal. In
REBOL-space,
> there is only one integer value 2.
>
> In the case of series (and I suppose constructed) values, the
data
> value is arbitrary and cannot be predefined. So, two strings
with the
> same apparent state are equal, but may not be the same. Since
the data
> value is something we created, we can change it (it is mutable).
But we
> don't really change scalar values, we simply reset the word to
another
> (predefined) scalar (it is unmutable).
>
> In the case of Joel's examples with TIME! - TIME! is a scalar.
You
> cannot change a scalar value the way you can change a series
value
> (immutable vs mutable). You must reset the word to another
scalar. So,
>
> >> a/minute: 55
> == 7:55:02
>
> Is not enough to change 'A -- we must say
>
> >> A: a/minute: 55
> == 7:55:02
>
> to set A to a new value. This is because A/MINUTE returns a
scalar
> value, the assignment conveniently adjusts that scalar value,
and
> returns that result. But since A is scalar, REBOL does not
> automatically redefine A.
>
> With a series, the same operation returns a reference to the
data, and
> so A (as a string) would be automatically changed (it is
mutable). If
> we want to avoid that change, we must copy the series first.
>
> By default, REBOL sets a word to share the data of a series
value. I
> don't know if this is a theoretical necessity, or just an
> implementation decision to save space. After all, if series
acted like
> scalars, then we would be forever making copies of what could be
very
> large structures.
>
> -Ted.
