[REBOL] Re: TUPLE! DATA-MODEL & OTHER VALUES
From: joel:neely:fedex at: 13-Jun-2001 1:44
Hi, again, Holger,
Holger Kruse wrote:
> On Tue, Jun 12, 2001 at 01:03:14PM -0400,
> [Robbo1Mark--aol--com] wrote:
> > Holger,
> >
> > Are you saying that REBOL values "can't" be contained in
> > 96 bits or that they "Aren't" contained within 96 bits.
>
> What I am saying is that you probably should not speculate
> about such details, because these things are not only subject
> to change but can (and do) also vary by platform. Consider
> 64-bit CPUs, for example.
>
I think I understand your point, and agree with it (if I do
understand it, that is!)
However... In the absence of a comprehensive published
specification, we're forced to resort to doing "particle
physics" on REBOL to try to understand what's going on in
many aspects of the language.
Such facts as the maximum number of bits in an integer, the
maximum number of octets in a tuple, etc. are truly useful
to a high-level programmer. And it's certainly possible to
write experimental code to figure out the answer for oneself.
But as the issues become more involved (such as the issue of
reference vs. non-reference data types, the meaning of SAME?,
and so on), it becomes progressively harder to draw the line
between those results of our experiments that are fundamental
to what REBOL was intended to do/be versus those that are
simply artifacts of how REBOL is currently implemented. In
addition, few of use can afford to keep one of every REBOL-
enabled platform around for "particle physics" experiments,
so it's difficult for us poor users to do quick tests to see
which experiments produce platform-dependent results.
> In any case, whether or not a datatype behaves like a series
> is not determined by the exact number of bits it requires.
> That kind of reverse engineering attempt simply does not help
> to explain or understand the issue discussed in this thread.
>
> What IS safe to say is:
>
> "Simple" types (integer, decimal, time etc.) only take up a
> small amount of memory and have "copy" semantics.
>
> More complex types, in particular those that have a variable
> size (series, object, function) or complicated underlying data
> structures (port), but also some fixed-size types which are
> quite large (e.g. bitset) always consist of two parts: the
> "value" part and the "data" part. The "value" part is unique
> for each value and conceptually references (points to) the
> "data" part. The "data" part is what is shared by several
> values and is subject to garbage collection. For a series,
> e.g., the value part contains the index, and the data part
> contains everything else, i.e. the series contents, its
> length etc.
> ...
> In REBOL a tuple! value is considered "simple". That's why its
> length is limited and why there is no underlying "data" that
> can be changed. A tuple! is not a series!, even though it is
> a linear sequence of items, like a series!, and supports some
> of the same syntax.
>
Thank you!
Except for the "etc." and "e.g.", the above paragraphs are the
closest thing we've had yet to an answer for some questions
that I know have been recurring on this list for over a year!
(And it would be really nice, since it is a fairly fundamental
concept to understanding REBOL data types, if there were some
standard terminology for the "value part" and "data part" you
referred to.)
While I sense (and probably would share, were I in your shoes)
your frustration when users "speculate about ... details" to the
level of how many bits may be in a "value" part, I hope you can
understand the frustration I feel (and I think I'm not alone)
about *HAVING* to speculate and experiment over legitimate
high-level issues. In come cases we've had months and months
of imaginings and debates and outright holy wars on this list
without any response whatsoever from RT.
I know that you busy beavers have more to do than you have hours
in the day! I appreciate your dedication to getting usable
results out the door!
But I also know that you read the list, and I know that both you
at RT and we users have more to do than wade through the head-
scratching and experimenting and speculation, when a simple
paragraph or two such as the ones you wrote above can go so far
toward setting us on the right path.
So let me beg of you (plural), PLEASE, when you see us getting
bogged down in trying to improve our understanding of this
language that we all want to see survive, thrive, and grow...
Chip in with a choice word or two of wisdom! Whether it's
"Integers are 32-bit, two's-complement values"
or
"The size of an INTEGER! value is platform-dependent, but
will always be at least 32 bits."
or something like
"That's an implementation artifact that may change in
the future, so don't worry about trying to nail it down.
The only thing you need to know is ..."
I can assure you that ANY tidbits you can offer will be
received with much appreciation (and will probably help cut
down on our speculation and your resulting frustration).
OBTW...
> Look at the difference:
>
> Series:
>
> a: [1 2 3]
> b: a
> a/1: 0 ;Changes the data shared by 'a and 'b.
> a
> == [0 2 3]
> b
> == [0 2 3]
>
> Tuple:
>
> a: 1.2.3
> b: a
> a/1: 0 ;Changes 'a only. 'a and 'b do not share data.
> a
> == 0.2.3
> b
> == 1.2.3
>
If you'll just clarify whether you meant that
"The tuple in 'a has been modified."
or
"The tuple in 'a has been replaced."
you'll put to rest an issue that has consumed several hours
(and quite a few gallons of virtual ink!) the past couple of
weeks. ;-)
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
