[REBOL] Re: On mutability and sameness
From: joel:neely:fedex at: 19-Jun-2001 3:43
[Robbo1Mark--aol--com] wrote:
> Joel Neely
>
> > I am not trying to reverse engineer REBOL......
>
> Ladislav Mecir
>
> > I am not trying to make discoveries or
> > statements about REBOL implementation
> > details.......
>
...
> Having followed this thread with interest, I
> believe, barring the disclaimer above, that
> both Joel & Ladislav are WRONG in the sense
> that some REBOL behaviour can only be explained
> and understood fully in terms of the way it
> has been implemented.
>
I don't want to create a model that explains all REBOL
behavior, just the "essential" behavior. The hard part
is at the edges. Absent a formal specification of what
REBOL "should" do, it is sometimes a bit of a puzzle as
to whether a given detail is essential or incidental.
However, most of the time the distinction is obvious.
(I should be clear that, since I view REBOL as a work in
progress, my remark that there's no formal specification
is a statement of fact, and not a complaint.)
> To me this "understanding" means how REBOL is
> implemented as well...
>
> Holger Kruse also stated that users shouldn't
> speculate about the precise implementation
> details as this can vary between CPU, platform
> etc. This is a valid point in as much as it is
> true however it does not aid us in our quest
> to understand REBOL...
>
Let me illustrate why I'm sympathetic to Holger's statement,
clarifying my essential-vs-incidental distinction.
ESSENTIAL:
We can observe REBOL behaving differently for BLOCK! and
TIME! values, as in:
>> a: [1 2 3] == [1 2 3]
>> b: a == [1 2 3]
>> a/1: 2 == [2 2 3]
>> b == [2 2 3]
(changing the value of A changes the value of B)
>> a: 01:02:03 == 1:02:03
>> b: a == 1:02:03
>> a/1: 2 == 2
>> b == 1:02:03
(changing the value of A does not change the value of B)
I view this behavioral distinction as essential; one cannot
use blocks and times correctly without respecting it (I
won't try to imagine using REBOL without using both BLOCK!
and TIME! values and all of their capabilites).
But we can describe this distinction via conceptual models
*without* reference to the specifics of the current REBOL
interpreter. Ladislav has offered one such model; I have
offered another. While our views differ over "meta-details"
of our models, I think we would both agree that both models
do predict the above behavior.
INCIDENTAL:
1) The SORT algorithm in REBOL used to be unstable; more
recent releases have used a stable algorithm. (For any
who aren't familiar with the jargon, "stable" has to do with
how different items with equal keys are handled, rather than
with sanity. ;-) Based on a post by Holger, I could guess
about the change, but there are several stable sort techniques.
Knowing that SORT is stable is relevant to my model (in some
cases, though not all) but knowing *which* stable sorting
technique was used is not. If I'm trying to explain REBOL to
someone who doesn't know what "stable" means, I can give an
example of how to achieve stability without worrying about
whether the example is based on the technique used in REBOL.
2) We know that REBOL values have types. There are many
different ways type could be represented. It is not
essential to my model whether types are coded as a single
byte in a descriptor or in a 64-bit bitmask prefixed to a
pointer, as long as I know that data type *is* an essential
aspect of a value and (for example) understand the meaning
of converting a value from one type to another.
> Forgive me if Iam wrong, but I think Joel is seeking
> a fully comprehensive understanding and Ladislav seeks
> clarity, simplicity, purity and consistency. These are
> NOT mutually exclusive.
>
Ladislav can (and will, I'm sure ;-) correct me if I don't
understand his view properly, but I'd describe our different
perspectives by saying it this way:
Joel is seeking a model of essential REBOL behavior
that uses conventional concepts and terminology when
appropriate and effective, with a goal of explaining
REBOL to programmers who already know other languages.
Ladislav is seeking a model of essential REBOL behavior
that can be communicated entirely within REBOL itself,
without reference to other languages or assumptions,
with a goal of having a seamlessly self-contained model.
These two goals sometimes lead to different explanations;
Joel is a little more willing to make a leap of faith
in the interest of simplifying his model, while Ladislav
is a little more strict about refusing to draw distinctions
that cannot be demonstrated by REBOL code.
> However I think they are wrong to believe they can fully
> and properly achieve this without geting down to the nitty
> gritty of implementation details where necessary.
>
And I suggest that we have different interpretation of "where
necessary".
> To fully understand the behviour of any-block! or any-string!
> series! values you have to have a model of how series! values
> are implemented at the C code level from which REBOL is built.
> ...
> Whilst any C code model we might build for REBOL values...
> will most probably NOT exactly match the RT official
> implementation, I think it is important conceptually that we
> do TRY to conceptually build an implementation model.
>
I'll admit that sometimes (especially given enough special
cases and exceptions) an operational model may seem more
compact than a more conceptual model, but I believe it is
important to stay as non-operational as possible. I don't
have time to give the whole argument here (and this probably
isn't the right forum for such details), but let me quickly
argue by analogy.
High-school geometry uses lots of diagrams. However, a good
geometry teacher will warn students about the dangers of using
diagrams. If I conjecture some property of a triangle and
draw a diagram to illustrate my conjecture, I have to make some
choices (perhaps unconsciously!) that will affect my perception
of what's relevant and what's not. Should my diagram use an
equilateral triangle, an isosceles triangle, a right triangle,
a scalene triange, an obtuse triangle? Each of those choices
may have incidental properties that could be misleading.
> Rather it is important that we build our model then
> incrementally refine / modify & improve it in view of further
> tests, errors, new and better models. What in essence we are
> doing is subjecting our Model to a "Turing Test", if it is
> capable of producing the same results and behaviour as REBOL
> then for all intents and purposes it is a valid working model
> of REBOL, regardless of number of bits per value etc.
>
On this we agree, but I feel compelled to emphasize that we
also have to keep in mind what parts of our model are essential
and what parts are incidental.
> Just like my eyes and hair are brown is controlled by my
> genetics, REBOL is an extension of it's implementation in C.
> One is a direct result of the other.
>
Case in point. I don't know for sure what language(s) the
current REBOL interpreter is written in. I think I shouldn't
have to know.
But let's speculate. Suppose Core 2.5 and View 1.2 were
implemented in C. Now suppose that Carl decides to implement
Core 3.0 and View 2.0 in Ada (or Pascal or raw assembler).
I believe that such a change could happen without our ever
knowing it.
C may be OK for giving examples, but it is certainly not the
only way to think about computing, IMHO.
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
