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
>> fakeIP
== 12.34.56.78
>> append fakeIP 90
** Script Error: append expected series argument of type: series
port.
** Where: append fakeIP 90
>> series? fakeIP
== false
so my experiments seem to conflict with the current documentation.
>
> 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.
>
Some languages take the copy approach (Perl; BASIC, I think) while
some make strings immutable (JAVA and Python). It would be good to
get the (intended) REBOL behavior officially nailed down.
-jn-
