[REBOL] Re: On mutability and sameness
From: joel:neely:fedex at: 21-Jun-2001 4:00
> The point is that Ladislave, yourself & others debated
How about "discussed with great energy"? ;-)
> at length, trying to use only REBOL and a natural language
> ( English ) to demonstrate the differences in property &
> behaviour of SAME? & EQUAL? functions.
Did my little story about "same" and "equal" bank accounts
capture that distinction for you? If not, I'd really like
to think about how to improve it. If so, then it shows
that we can discuss conceptual distinctions without resorting
to low-level programming languages.
> Using REBOL was insufficient in producing a function for
> testing whether an any-string! or any-block! value shared
> the same memory location,
I'm really distressed with myself for being unable to state
this point clearly enough. WRT series value:
I do not CARE whether two series values share "the same memory
location" (and I especially do not care how many bits are in
that "location" nor how it may be laid out). What I care about
most is this:
Given two expressions (including simple words) that
each evaluate to a series, under what conditions can
I perform an evaluation involving one of them that
has the effect of changing the evaluation of the other?
I also care (somewhat less) about this:
Given two expressions (as above...) can one of them
consistently be evaluated using less time and/or
memory than the other?
It is not hard to demonstrate that two expressions may evaluate
to the "same" series, and to start drawing inferences as to
when that occurs.
>> a: [1 2 3] == [1 2 3]
>> b: a == [1 2 3]
>> c: [1 2 3] == [1 2 3]
>> d: copy a == [1 2 3]
>> reverse a == 
>> a == [3 2 1]
>> b == [3 2 1]
>> c == [1 2 3]
>> d == [1 2 3]
Some conclusion about copying and literal series expressions
are fairly obvious, and I won't take the time for them here.
Factors that make this game more subtle include:
1) the rich variety of REBOL data types,
2) REBOL's ability to create self-referential structures, and
3) the desire to discover "non-destructive" tests that
preserve the values we're examining.
(Old joke: How can you tell if a chair is an antique? It
burns with a bright blue flame!)
> and natural language was to ambiguous and lead to discussions
> about concise definitions & meanings for words.
... to which the solution involves precise definitions,
mathematics, and logic, not another programming language.
I must also point out another of my hidden biases. I regard
the goal of "a programming language for non-programmers" in
the same light that I regard the strong-AI goal of programming
human-like intelligence. I believe that both are ultimately
impossible. HOWEVER, I believe that efforts toward both goals
have led to wonderful advances in the state of programming that
likely never would have happened otherwise.
If you'll pardon the sports analogy (I'll probably regret this
as well ;-) it's perfectly OK for a runner to set the goal of
running a 2-minute mile, and to develop nutrition and training
regimens shaped by that goal. On the other hand, if a runner
claims to me that (s)he actually *has* run a 2-minute mile,
I'm going to get very, very picky about examining his/her
stopwatch and yardstick, and I'm going to insist on an actual,
testable demonstration before I accept the claim. (And even
then I'll be suspicious... ;-)
The AI community lost their credibility (despite some really
wonderful achievements) due to overselling and overly-
optimistic/enthusiastic claims. AI fell from being a leading
frontier in computing to being a marginalized niche, and its
proponents are now often viewed as snake-oil salesmen. I don't
want to witness that kind of tragedy again. Especially not
I have great respect for Carl and the whole RT team, and for
the fruits of their labors.
That's why I often (usually?) take on a gadfly-like role and
challenge the notions that (what I regard as) hand-waving
explanations (or *no* explanations, in some cases ;-) and
claims of simplicity are good enough to certify REBOL as a
final achievement of the "impossible dream" of easy programming
Better stories, more precise language, more complete documents
(written *both* by RT and the user community) and, yes, the
elimination of some unnecessary inconsistencies in REBOL itself
will all move us toward better programming for both programmers
Requiring that we describe REBOL in terms of a low-level
programming language is IMHO contrary to that goal.
> Your use of C, whilst admittedly not making it clear to
> everyone, showed demonstrably the why & how of the different
> behaviour. Anyone who knows C could study your example and
> see the logic that produced the REBOL like behaviour...
This is the heart of the problem (and the reason for my sincere
regret over that example!).
One or two of the questions in the thread seemed (to me) to
imply that REBOL was drawing a peculiar distinction that was
outside normal programming concepts. Quod non.
I wanted to show that the distinction does exist in other
languages, but that REBOL expressed it differently. I wasn't
trying to argue "how" REBOL must have been implemented. For
the rest, please reconsider my posted remarks on the danger of
drawing triangles in geometry. Arguing by example runs the severe
risk of having irrelevant details of the examples
the discussion and focus attention on the wrong
Depending on The Language That Must Not Be Named as our means
of explaining REBOL:
1) brings in entirely too much irrelevant baggage,
2) can be misleading, and
3) excludes anybody who doesn't already know that Language.
I consider all of these to be undesirable.
> All I will say is how advanced would our understanding of
> modern science be if the discoveries of Newton, Einstein,
> Planck, Maxwell etc. were proprietary & secret?
How advanced would our scientific understanding be if:
1) NEPMetc. were *required* to do all of their thinking
in public, subject to constant committee-style debate
over every detail while the work was still in progress?
2) Einstein, Bohr, and Planck were *required* to explain
all of their ideas strictly in terms of Newtonian
mechanics, and told that anything that didn't fit the
Newtonian model was unreasonable and unacceptable?
Now (to follow my own advice) I'm back to model hacking!
Programming languages: compact, powerful, simple ...
Pick any two!