Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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