[REBOL] Evaluation Re:(10)
[EMAIL PROTECTED] wrote: > > l>> word ; mutable (protect/unprotect/set ...) > > Actually, I prefer to think that those function modify the > context, not the word. Well, at least for 'set. > Hmmm. Interesting, but I can see your point. How about 'bind? Do you consider that as modifying the word itself (not its value)? -jn-
[REBOL] Evaluation Re:(10)
Hi, thanks, I forgot about it. But, see: Money: >> a: $100 == $100.00 >> poke a 2 3 == $3.00 >> a == $100.00 It seems immutable to me Date: >> a: 7/1/2000 == 7-Jan-2000 >> poke a 1 8 == 7-Jan-0008 >> a == 7-Jan-2000 Time: >> a: 21:21 == 21:21 >> type? a == time! >> poke a 1 22 == 22:21 >> a == 21:21 Tuple: >> a: 1.2.3 == 1.2.3 >> type? a == tuple! >> poke a 1 22 == 22.2.3 >> a == 1.2.3 So, I think, that although pokable, the values are immutable, which is not bad. Ladislav > >Hope this is helpful: > > >> HELP POKE > > Returns value after changing its data at the given index. (See manual) > Arguments: > value -- (series money date time object port tuple) > index -- (number logic) > data -- new value > > The list below lists a few of the above pokables as immutable. > > (Maybe the list could be broken into two?) -jeff > > > > any-type ; undecidable > any-function ; mutable > action ; mutable (change third ...) > function ; mutable (change first ...) > native ; mutable (change third ...) > op ; mutable (change third ...) > any-word ; undecidable > get-word ; immutable - (an immutable ref. to a mutable word?) > lit-word ; immutable - (an immutable ref. to a mutable word?) > refinement ; immutable - (an immutable ref. to a mutable word?) > set-word ; immutable > word ; mutable (protect/unprotect/set ...) > bitset ; immutable > char ; immutable - scalar > date ; immutable - scalar > error ; immutable > logic ; immutable - scalar > money ; immutable - scalar > none ; immutable - scalar > number ; immutable > integer ; immutable - scalar > decimal ; immutable - scalar > object ; mutable (through set-path ...) > port ; mutable (close ...) > series ; mutable (change ...) > any-block ; mutable (change ...) > block ; mutable - series (change ...) > list ; mutable - series (change ...) > lit-path ; mutable (change ...) > hash ; mutable - series (change ...) > paren ; mutable - series (change ...) > path ; mutable - series (change ...) > set-path ; mutable (change ...) > any-string ; mutable (change ...) > binary ; mutable - series (change ...) > email ; mutable - series (change ...) > file ; mutable - series (change ...) > issue ; mutable - series (change ...) > string ; mutable - series (change ...) > tag ; mutable - series (change ...) > url ; mutable - series (change ...) > symbol ; immutable > time ; immutable - scalar > tuple ; immutable - scalar > unset ; immutable > > > > > > >
[REBOL] Evaluation Re:(10)
Hi, Ted,
SHORT VERSION:
1) I'm not sure what "scalar" really means in REBOL (and a simple
listing of the datatypes that are called scalar isn't an
explanation). Maybe that's my fault?
2) Without a clearly-stated model/specification from the final
authority (REBOL, Inc.), we may see behavior we didn't
expect and be unable to determine for ourselves whether:
a) It's supposed to be that way. Carl just has different
(perhaps better ;-) ideas that we do about what "should"
be happening.
b) It's supposed to be different. There's just a bug in
the current version.
c) There IS no "supposed to". The behavior is simply an
emergent, unplanned property of the implementation.
RAMBLING DETAILS:
Based on the terminology in
http://www.rebol.com/manual/valabout.html
on the subject of "scalar"
This chapter focuses on the common definitions for data values
(sometimes called constants or literals) that can be directly
expressed in the REBOL language.
Most values are written in a common, natural form, like integers.
Some values have alternate forms allowing for minor variations
found in some countries, like dates. REBOL will accept any of
the forms.
Scalar and Constructed Datatypes
Within the language, the types of fundamental values mentioned
above are called scalar datatypes. Programs are created by
combining these datatypes in endless variety to form more
complex data.
the only "types of fundamental values mentioned above" in that
document are "data values that can be directly expressed in the
REBOL language."
This makes it sound as if "scalar" simply means data values that
have an explicit representation in REBOL, including the possibility
of some variations in that explicit representation.
[EMAIL PROTECTED] wrote:
>
> Hi, Ladislav,
>
> 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.)
>
(Not flaming, just thinking out loud...) The simplest data values
-- integers for instance -- are viewed as having no parts; they
simply "are" themselves. Since there are no parts, there's no way
to manipulate the parts of a value. Therefore, every occurrence of
17 is totally interchangeable with every other occurrence of 17.
No information is available regarding its ancestry, personal habits,
place of residence, etc. (Remember that the literal meaning of
"atomic" -- uncut -- means that there are no parts.)
So, it's probably just metaphysics to distinguish between saying
that there's only one 17 (to which occurrences are just references)
or to say that all 17s are totally equivalent.
BUT, once we start introducing values which have parts (other terms
might be "attributes" or "components"), those values start to seem
more like containers than atomic units. If you hand me a container,
I can fiddle with the contents without changing the identity of the
container.
If we have two references to (or "mentions of") the same container,
then the contents are guaranteed to be identical. OTOH, having two
references which refer to distinct containers leaves the possibility
that their contents can be identical (e.g. immediately after making
a copy) or not. We need to be able to express "single container"
('same?) distinctly from "different containers but identical
contents" ('equal?) distinctly from "different containers with
different contents" ('not-equal?).
Now, if we are prohibited explicitly from changing the contents of
certain datatypes, then there's nothing we can do to make visible
the distinction between 'same? and 'equal? -- they become synonymous
in the practical sense. We may have situation in REBOL (e.g., with
time! and date! values).
>
> This would be because all scalar values can be predefined, since
> that is what scalar means.
I'm not sure I understand how you mean "predefined". I'd be
interested in hearing more on what you had in mind.
>
> And this is why all scalars with the same apparent state are
> considered both the same and equal... 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.
>
That seems to be true experimentally (sort of~!). I can show it
with money! values, as follows:
>> reward: $100.00
== $100.00
>> first reward
== ""
>> append first reward "DM"
== "DM"
>> reward
== $100.00
However, tuple! is described in the same document referenced above
as being a series datatype. It behaves as if immutable:
>> fakeIP: 12.34.56.78
== 12.34.56.78
>> second fakeIP
== 34
>> fakeIP/2: 43
== 12.43.56.78
>> fakeIP
== 12.34.56.78
and also denies being in the series pseudotype
>> fak
[REBOL] Evaluation Re:(10)
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
[REBOL] Evaluation Re:(10)
{{
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.)
}}
Or, REBOL only creates one object for a given scalar value, and all
words defined with that value refer to the same object.
In the case of a series, REBOL creates an object for the data value,
and by default, shares the data value when a word is set to the series.
Many series operations don't need to reset the word, since the
operation affects the data value directly. The word is still defined
the same way, but evaluates differenty because the value of the
underlying reference has changed. (It looks-up the data value and
finds a different string, but it is still looking at the same memory
location.)
In the case of a scalar, you must reset the word for it to evaluate to
another value. Scalars are immutable -- the underlying object cannot be
changed, we must reset the word to refer to another object.
Are we getting any closer?
-Ted.
*** REPLY SEPARATOR ***
On 1/4/2000 at 7:16 AM [EMAIL PROTECTED] wrote:
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.
