[EMAIL PROTECTED] wrote:
>
> In one of my previous posts, I showed that bind doesn't change
> words, but creates new ones. I'm starting to think that words are
> immutable...
>
I need to look that msg up and think about it.
>
> BTW, do you think that immutable series would be better? Would
> their behaviour be more intuitive?
>
I think there are two issues:
1) "truth in labeling", and
2) holy wars.
(How's that for ducking the question? ;-)
1) I really believe that it would be good for the official REBOL
docs to state explicitly which values are (im)mutable and why.
Having the intended REBOL behavior documented -- especially if we
can get rationale to go with that -- will simply help us (well, at
least me!) understand better what the language is INTENDED to do.
At this stage, I want to make sure I understand the conceptual
vision for REBOL before I get too far into #2.
2) Without placing any value judgements on them, there are some
significant tradeoffs on series values being immutable. Having
immutable series values would push REBOL programming to a more
functional style, would reduce (if not eliminate) the possibility
of unexpected/unintended side-effects (especially in the case of
series values being passed through multiple layers of function
calls), and would likely introduce more overhead (especially for
folks who are used to an imperative style of programming).
Instead of saying,
insert series-ref blah-blah-blah
and having all other references to the same series "get modified",
one would need to (and be able to) think about whether one wanted
to modify a copy of the series for local use
new-series-ref: immutableinsert series-ref blah-blah-blah
or explicitly modify a shared reference (global variable, etc.)
series-ref: immutableinsert series-ref blah-blah-blah
; or
global-stuff/3: immutableinsert global-stuff/3 yadda-yadda
; and so on
A big problem with deciding what is more intuitive is that intuition
is the product of training and experience. My suspicion is that a
programmer who comes to REBOL already knowing one or more mainstream
languages would find MUTABLE blocks USED AS DATA more intuitive, but
IMMUTABLE blocks USED AS CODE more intuitive. Since REBOL refuses
to make the DATA/CODE distinction, his/her intuition is likely to be
frustrated at some point, as long as all series values have the same
(im)mutability.
Even if the language were still in design and this were a discussion
about requirements for a future language, I believe there would be
some violent^H^H^H^H^Hgorous ;-) discussion/debate about what REBOL
"should" do on this issue.
So, how could this be addressed? There are several options:
a) Have mutable series values, and leave it to documentation,
training, and experience to change the programmer's intuition.
This requires no change to existing code, nor to the language, but
does imply more attention to this issue in the docs (which are still
under development anyway, I presume/hope).
b) Change REBOL to have immutable series values, and put all of the
current REBOL users through the agony of fixing all the REBOL
code that breaks as a result; some of it would likely be so broken as
to be more easily redesigned ab initio (or discarded) than fixed.
c) Extend REBOL with additional series types which are immutable,
requiring that all series operators/functions "do the right
thing" based on the (im)mutability of their arguments. E.g.,
'insert on a value of type 'immutable-string! would copy the string
value, modify the copy, and return the modified copy. This would
require changes to REBOL (and the docs), but wouldn't break any
code and would give a REBOL programmer control over (im)mutability
at a fine-grained level.
This one is still leaves non-trivial learning, due to REBOL's ability
to create nested series values. In the case of an immutable series
containing a mutable series containing ... (you see where this is
going), the programmer could still construct surprises. There's also
the issue of notation -- is
[fee fie foe fum]
a mutable or immutable series, do we get new notation (such as
[:fee fie foe fum:]
for mutable series values), or do we have assymetry of notation where
make immutable-block! [fee fie foe fum]
is the only way to get immutability, etc...
d) Extend REBOL with pure functional series operators/functions and
let the programmer exert control at the expression level rather
than the value level:
blockref2: immutable-insert blockref1 miscellaneous-cruft
blockref2: immutable-append blockref1 miscellaneous-cruft
; etc.
This implies REBOL (and doc) changes and still requires the newbie
to understand mutable series values, but gives the programmer access
to a more functional style and insurance against side-effects. It
also could be tested (although with some extra overhead) by some of
us (users) writing the immutable versions as mezzanine functions and
playing about with some specimen problems to further explore the
stylistic and performance issues, prior to any action on the part of
the REBOL, Inc. folks.
CONCLUSION:
Since doing anything about this would imply LOTS of work for
somebody (depending on which option was chosen), I'd VERY MUCH like
to see #1 above happen ASAP, with an open discussion about why the
choices were made as they were (I'm assuming that the mutability
choices that Ladislav has been summarizing WERE deliberate choices,
just not well documented).
That would leave us, at least in the short run, with options a) or
d). I certainly wouldn't ask anybody at REBOL, Inc. even to THINK
about b) or c) unless/until some compelling arguments could be made
that the resulting advantages were so great as to offset the effort
and schedule hit.
Anybody game for d)?
>
> I'm asking because I'm not an expert in this field. :-)
>
I'm not an expert; I just play one on the 'Net! ;-}
> Regards,
> Gabriele.
> --
> o--------------------) .-^-. (----------------------------------o
> | Gabriele Santilli / /_/_\_\ \ Amiga Group Italia --- L'Aquila |
> | GIESSE on IRC \ \-\_/-/ / http://www.amyresource.it/AGI/ |
> o--------------------) `-v-' (----------------------------------o
