[REBOL] Re: On mutability and sameness
From: robbo1mark:aol at: 19-Jun-2001 7:27
< snip >
Iam not trying to reverse engineer REBOL......
< snip >
< snip >
Iam not trying to make discoveries or
statements about REBOL implementation
< snip >
; disclaimer, I'm not sure if I've quoted
; Joel & Ladislav here precisiely word for
; word, I don't have thier original postings
; & docs to hand, but I think these statements
; portray accurately what they were trying to
; convey. Sincere apologies if I misrepresent
; them in any way!
With the utmost respect to both Joel & Ladislav
whom I admire & respect both greatly, and thank
them for the knowledge and insight I gained from
them with their thoughtful & considered posts
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.
Now I know that both Joel & Ladislav and myself
are all striving for basically the same thing.
We want to REALLY UNDERSTAND REBOL.
REALLY UNDERSTANDING REBOL means having an
accurate model & conception of the structure
of REBOL that can properly predict REBOL
behaviour for any given function or datatype.
To me this "understanding" means how REBOL is
implemented as well. Now as we all know REBOL
is not open source and only Carl & the RT gang
can truly know it's inner secrets & full
implementation details & specification.
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 and it puts us in a position
of dependancy on RT to clarify further or reveal
parts of REBOL secrets / mystery we don't fully
grasp. Sometimes they are very good and they do
explain things more fully at other they say either
nothing or nothing helpful as it may impinge on
Joel & Ladislav both find areas where the existing
REBOL documentation and / or REBOL behaviour is
either misleading, inconsistent, confusing, not
fully or properly documented, or sometimes in their
Though they sometimes disagree / agree to disagree,
and appear to come at things from conflicting
angles or viewpoints, in essence they strive for
the same thing and that is to UNDERSTAND REBOL
and be able to describe / document concisely
and comprehensively ( and consistently ) REBOL values
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.
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.
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.
The behaviour of series! and their associated functions are
direct result of the way they are implemented in C. The same
applies to whether set-words or set-paths etc. create a new
instance or copy of a value or merely reference existing
Whilst any C code model we might build for REBOL values, whether
they be "simple" values like integer! or char!, series! values
like block! string! etc. or compound values like date! time!
tuple! etc. 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.
What is important is NOT that we precisely match the official
REBOL implementation from scratch, that would be impossible
as we are essentially working blind and cannot know all the
platform specifics in advance.
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.
Charles Moore of Forth fame has been quoted "To fully understand
your tools you have to build / re-build them yourself from scratch."
Now Chuck Moore is famously an extreme perfectionist and harsh
taskmaster but there is a strong element of truth and wisdom here.
On the otherhand there is also the saying "if you want to create
an omelette from scratch, you have to devise a way of re-creating
the Big Bang". Hopefully we don't have to go that far back or
that "low level" 8-)
I liked Joel's recent example of an equivalence test using C code
to display strings as char pointers, char arrays, variable references
etc. This example showed how to produce a boolean true or false
that mimics actual REBOL behaviour.
Unless REBOL Technologies produce the "REALLY UNDERSTANDING REBOL" book
subtitle: REBOL Implementation Explained for Tech. Experts & Hackers
then to gain the knowledge and clarity we seek I think it's inevitable
sometimes we will have look under the hood and build our model upwards
from C code to properly understand and explain topics of debate and / or
dispute, regardless of whether we get the bit numbers slighlty wrong.
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.
Credit to Joel, Ladislav and others for the high quality and insight
of posts thus far.
In a message dated Sun, 17 Jun 2001 1:44:03 PM Eastern Daylight Time, "Ken Anthony"
Much appreciation for your discussions in this list.
> Kind of datatype Comparison to be performed
> ---------------- --------------------------
> 1) Simple data Compare the data values
> 2) Reference data Compare the "pointer" values
> 3) Reference data Compare the "final data" values
> > ...is there a referenced? vs. non-referenced? type function?
> Not AFAIK. The following is a quick cut at a function that
> tells whether the current value of a word is of a reference
May I propose or suggest that RT consider adding a 'simple?' function (the
word seems to be common to the thread whereas sharable? seems to add a
nuiance not explicit in your chart above) which could act as a lawman for
> sharable?: func ['w [word!]] [
> found? any [
> series? get w
> any-function? get w
> object? get w
> It may be used as follows:
> >> a: "123" == "123"
> >> sharable? a == true
> >> a: 123 == 123
> >> sharable? a == false
> >> a: 12:30 == 12:30
> >> sharable? a == false
> >> a: [1 2 3] == [1 2 3]
> >> sharable? a == true
> No warranties expressed or implied! I believe it to be true
> for the "ordinary data" cases, but it may require tweaking
> for the more esoteric REBOL-specific types.
But I *want* warranties!
Deputy, round up a posse! I have a warrant here for any genius language
designer that leaves too many undefined issues hanging around the saloon. I
don't give a lick for what that there Godel hombre has to say about it.
While we're at it, let's throw in a few divide by zero's laws just for
kicks. It may be infinity to those there mathmatical fella's, but us
programmer's around these here parts usually just define the result to be
But Sheriff, my boy told me that 0/0 is undefined soes we might as well make
a law that it's ta be nought... wouldn't it be more correct for sum number
there divided by nought to be a really big number like those mathmedical
Now deputy, if they want to test for zero, they can test for zero, but I'm
telling ya we got ta have a civilized town here. That means no shootin'
irons in the town limits and zero begets zero whether ya multiply or divide.
Well I don't rightly know Sheriff, sounds kinda dangerous like to cipher
BTW, Sheriff didya notice they got this cp thing that does the same thang as
I saw that there deputy, and I plan to make eunix atta those there rustlers
as soon as we get this zero issue all cleared up. Now let's go down to the
corral and see what Ike and his boys are up to.
Well of course.