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

TUPLE! DATA-MODEL & OTHER VALUES

 [1/19] from: robbo1mark:aol at: 7-Jun-2001 7:26


Everybody, for those of you, Larry, Ladislav, Joel, Volker etc. who have been discussing the implementation of REBOL tuple! & other types, well here is an old posting from the OSCAR Project regarding our discoveries of REBOL datatypes. mark Dickson
>> old OSCAR mailing follows >>>
Mark,
> If I understand you correctly you ar saying that all REBOL values > can be contained within 96 bits ie 3 x 32 bit-words. Maximum size
per value
> 12 BYTES. > > Is this correct ?
Yes... Every series! does not fit into 12 bytes. The values fitting into 12 bytes are all values that have no pointers. (with exeption of bitset! The length of bitset is 256 bits) Tuple is a value that has variable length. It extents to 10 bytes. To make a fast REBOL interpreter some rules aply: 1 all values have to be of the same length for fast indexing. 2 values should be as small as possible. (for speed) 3 values should use use most of the reserved room. values have to be at least 2 32 bits words ( = 8 bytes ) to supply enough room for a index and a pointer. (used by series). It also needs some room to store the datatype_id. This could be done in a byte but then you would end up with a value with a length of 9 bytes. This is not fast, so the structure has to expand to 12 bytes for speed. (most processors use 32 or 64 bits words). This extra 2 or 3 bytes are used by some datatypes to store even more data. This applies to rule 3. With tuple all room is used. Example: If the structure is 12 bytes a tuple can be of length 10:
>> 255.255.255.255.255.255.255.255.255.255
If the structure is 10 bytes a tuple can be of length 8:
>> 255.255.255.255.255.255.255.255
If the structure is 16 bytes a tuple can be of length 14:
>> 255.255.255.255.255.255.255.255.255.255.255.255.255.255
Doing some math the most economic size is 12 bytes. Not to big and fast.
> Also I didn't quite follow your tuple explanation, could you
possibly please
> clarify this using Andrews example of a ten value tuple each with
the value
> 255 (ie 1 BYTE number), expalining how this would be structured
including
> the datatype_id & series_length values.
A 10 value tuple needs 10 bytes to store it's value. Because the model has to put this into 12 bytes. 2 bytes are left to store the tuple_length. tuple_length is a integer from 0 to 7. real tuple length = tuple_length + 3 Together with the datatype_id it has to fit into a 16 bit word. 3 bits are needed for the tuple_length. The other 13 bits can be used to store the datatype_id. Daan Oosterveld

 [2/19] from: larry:ecotope at: 7-Jun-2001 10:22


Hi Mark Thanks for the post, I found Daan's discussion of tuples quite insightful. Is there anything in your archives about the fact that creating a empty block allocates 16 bytes per entry?
>> start: system/stats
== 1620752
>> b: make block! 10000
== []
>> rebol/stats - start / 10000
== 16.1792
>>
Note there is a small amount of additional overhead reflected. The longer the block the closer the value is to 16. Cheers -Larry ----- Original Message ----- From: <[Robbo1Mark--aol--com]> To: <[rebol-list--rebol--com]> Sent: Thursday, June 07, 2001 4:26 AM Subject: [REBOL] TUPLE! DATA-MODEL & OTHER VALUES
> Everybody, > > for those of you, Larry, Ladislav, Joel, Volker etc. who have been
discussing the implementation of REBOL tuple! & other types, well here is an old posting from the OSCAR Project regarding our discoveries of REBOL datatypes.

 [3/19] from: carl:rebol at: 7-Jun-2001 11:43


Unless, of course, you are running on a 64 bit processor. Pay no attention to the man behind the curtain. -Carl

 [4/19] from: holger:rebol at: 12-Jun-2001 9:09


On Thu, Jun 07, 2001 at 07:26:44AM -0400, [Robbo1Mark--aol--com] wrote:
> > If I understand you correctly you ar saying that all REBOL values > > can be contained within 96 bits ie 3 x 32 bit-words. Maximum size
<<quoted lines omitted: 3>>
> > Is this correct ? > Yes...
Interesting theory, but wrong, sorry :). -- Holger Kruse [holger--rebol--com]

 [5/19] from: robbo1mark:aol at: 12-Jun-2001 13:03


Holger, Are you saying that REBOL values "can't" be contained in 96 bits or that they "Aren't" contained within 96 bits. As there is a difference! and some people are interested in this. Not wishing to step on anybodies proprietary toes here! Yours in interest. Mark Dickson In a message dated Tue, 12 Jun 2001 12:19:51 PM Eastern Daylight Time, Holger Kruse <[holger--rebol--com]> writes: << On Thu, Jun 07, 2001 at 07:26:44AM -0400, [Robbo1Mark--aol--com] wrote:
> > If I understand you correctly you ar saying that all REBOL values > > can be contained within 96 bits ie 3 x 32 bit-words. Maximum size
<<quoted lines omitted: 3>>
> > Is this correct ? > Yes...
Interesting theory, but wrong, sorry :). -- Holger Kruse [holger--rebol--com]

 [6/19] from: holger:rebol at: 12-Jun-2001 10:50


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. 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. What started this discussion was the behavior of the tuple! datatype. 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. 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 To see that the index of a series is not shared among different values referencing the same series, try: a: [1 2 3] b: a a: next a a == [2 3] b == [1 2 3] -- Holger Kruse [holger--rebol--com]

 [7/19] from: larry:ecotope at: 12-Jun-2001 12:12


Hi Holger,
> 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. > > What started this discussion was the behavior of the tuple! datatype. 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. Thanks Holger, that is very useful information. I am still a bit puzzled by the apparent memory allocation for blocks. Using REBOL/Core 2.5.0.3.1
>> start: system/stats
== 1620752
>> b: make block! 10000
== []
>> system/stats - start / 10000
== 16.1792
>> loop 10000 [insert tail b to-decimal random 1000]
== []
>> system/stats - start / 10000
== 16.1792
>> b
== [695 852 380 196 367 232 853 912 304 415 171 632 767 530 257 786 935 620 566 441 445 704 719 260 715 897 556 599 936 666 728 199...
>> type? first b
== decimal! It seems like there are about 16 bytes allocated per element when the empty block is created, but when I insert 10000 decimal! values at a minimum of 8 bytes per element into it, the memory allocation does not increase. Does this imply the "pointers" for the block elements have room somewhere for short simple types, or does the block creation simply allocate a certain amount of space for short simple values? Are the values of simple block elements stored consecutively in memory, or does the block just contain "pointers" to values in the heap? Any comments would be much appreciated. -Larry

 [8/19] from: holger:rebol at: 12-Jun-2001 15:12


On Tue, Jun 12, 2001 at 12:12:42PM -0700, Larry Palmiter wrote:
> Thanks Holger, that is very useful information. I am still a bit puzzled by > the apparent memory allocation for blocks.
<<quoted lines omitted: 23>>
> Are the values of simple block elements stored consecutively in memory, or > does the block just contain "pointers" to values in the heap?
Conceptually a block is an array of values, and "make block! 10000" ensures that the block has room for 10000 values. That's why you do not see the memory use increase when values are inserted into the block. I am afraid I cannot comment on implementation details. -- Holger Kruse [holger--rebol--com]

 [9/19] 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:
<<quoted lines omitted: 6>>
> 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.
<<quoted lines omitted: 20>>
> 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:
<<quoted lines omitted: 13>>
> 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

 [10/19] from: carl:cybercraft at: 13-Jun-2001 21:00


On 13-Jun-01, Joel Neely wrote:
> Hi, again, Holger, > Holger Kruse wrote:
[snip]
>> Look at the difference: >>
<<quoted lines omitted: 24>>
> (and quite a few gallons of virtual ink!) the past couple of > weeks. ;-)
Because tuples are like integers "simple" (to use Holger's term), I have a feeling the answer is that it makes not a jot of difference to the REBOL programmer. But modified seems the most likely as it'd save on garbage collection.
> -jn- > ------------------------------------------------------------ > "Programming languages: compact, powerful, simple ... > Pick any two!" joel'dot'neely'at'fedex'dot'com > ------------------------------------------------------------
-- Carl Read [carl--cybercraft--co--nz]

 [11/19] from: joel:neely:fedex at: 13-Jun-2001 8:50


Hi, Carl, Let me respond to a couple of statements. I'll take them out of order, as I suspect one to be relevant to more folks than the other. Carl Read wrote:
> On 13-Jun-01, Joel Neely wrote: > > Holger Kruse wrote:
<<quoted lines omitted: 12>>
> > or > > "The tuple in 'a has been replaced."
...
> Because tuples are like integers "simple" (to use Holger's > term)... modified seems the most likely as it'd save on > garbage collection. >
I *really* doubt that inference. Garbage collection applies to dynamically allocated data structures, which are usually managed through some variation of pointers, handles, or references (whether automatic or not). If (e.g.) tuples are non-reference data, it's hard for me to imagine how garbage collection has anything to do with it.
> Because tuples are like integers "simple" (to use Holger's > term), I have a feeling the answer is that it makes not a > jot of difference to the REBOL programmer. >
You're certainly entitled to say that it makes no difference to you, but others (including me) may have more of an interest. This thread arose from an attempt to understand the behavior of SAME? and EQUAL? with respect to the various data types. Understanding how the parts of our language fit (and work) together would seem to contribute to using the language more effectively. There are many places where REBOL exhibits seeming subtleties and inconsistencies. Understanding how the parts of our language fit (and work) together would seem to help a programmer (of any flavor ;-) avoid any unnecessary (and unpleasant) surprises regarding the behavior of his/her program. I am not "a REBOL programmer". I am a programmer who uses many languages, of which REBOL is one. Understanding how the parts of our language fit (and work) together, and doing so in terms of standard computing concepts and terminology, helps with the choice of which lanaguage(s) is/are appropriate for a given task, and helps translate an algorithm expressed in one language into another. I have several friends who teach in higher education. I am on the advisory committees for two computer engineering curricula. I would love to be able to recommend REBOL as suitable for teaching (and perhaps even research in) computer programming, but cannot yet do so. One of the reasons is the current absence of a complete model for REBOL semantics. Whenever one has a language where the most effective response to a question is I don't know; let's try it and find out. one has a language that is not ready for prime time, at least educationally. Those are a few (though not all) of my motivations for being interested. Anyone not interested in any of the above issues is certainly free to ignore the whole discussion. ;-) -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [12/19] from: larry:ecotope at: 13-Jun-2001 9:54


Hi Holger,
> Conceptually a block is an array of values, and "make block! 10000"
ensures
> that the block has room for 10000 values. That's why you do not see the > memory use increase when values are inserted into the block. I am afraid > I cannot comment on implementation details.
Thanks again, for some very useful information. -Larry

 [13/19] from: karlr20:home at: 13-Jun-2001 10:36


> It seems like there are about 16 bytes allocated per element when the empty > block is created, but when I insert 10000 decimal! values at a minimum of 8
<<quoted lines omitted: 6>>
> Any comments would be much appreciated. > -Larry
Hi Larry, I've written a C++ class to read REBOL code as values and now my own REBOL-like language. I'm pretty sure I have a handle on how REBOL stores values. My basic value is something like this: struct Value { DatatypeReference type; union data { int integer; double decimal; bool logic; char tuple[10]; Block* block; String* string; // etc... }; }; For REBOL the sizeof(Value) seems to be 16 bytes. As you can see, adding any simple data type to a block (array of Values) will not increase its size as the data is stored in the value. I hope this helps you to visualize what may be going on. -Karl P.S. Opps, I just realized I have assumed you are a C programmer!

 [14/19] from: larry:ecotope at: 13-Jun-2001 12:54


Hi Karl, You wrote:
> I've written a C++ class to read REBOL code as values and now my own > REBOL-like language. I'm pretty sure I have a handle on how REBOL stores
<<quoted lines omitted: 13>>
> }; > For REBOL the sizeof(Value) seems to be 16 bytes. As you can see, adding
any
> simple data type to a block (array of Values) will not increase its size
as
> the data is stored in the value. I hope this helps you to visualize what
may
> be going on.
Thanks for sharing your insights. BTW do your "values" incorporate, in the case of blocks, the current index as described by Holger in his recent post.
> -Karl > > P.S. Opps, I just realized I have assumed you are a C programmer!
Yes, I am familiar with C and C++ although not using them much at the present time. -Larry

 [15/19] from: carl:cybercraft at: 14-Jun-2001 12:21


On 14-Jun-01, Joel Neely wrote:
> Hi, Carl, > Let me respond to a couple of statements. I'll take them out
<<quoted lines omitted: 36>>
> non-reference data, it's hard for me to imagine how garbage > collection has anything to do with it.
Well, my feeling is that if you replaced the tuple, the one you replaced would be left hanging around and in need of discarding in one way or another.
>> Because tuples are like integers "simple" (to use Holger's >> term), I have a feeling the answer is that it makes not a >> jot of difference to the REBOL programmer. >> > You're certainly entitled to say that it makes no difference > to you, but others (including me) may have more of an interest.
My point is that with "simple" datatypes, REBOL could be either modifying or replacing them and we couldn't tell either way. (Except perhaps with memory usage, which could possibly differ from platform to platform.) The mental model to have though would be that they've been modified, as there's no way (as far as I know) to get at the original again.
> This thread arose from an attempt to understand the behavior > of SAME? and EQUAL? with respect to the various data types.
<<quoted lines omitted: 6>>
> (of any flavor ;-) avoid any unnecessary (and unpleasant) > surprises regarding the behavior of his/her program.
I agree totally.
> I am not "a REBOL programmer". I am a programmer who uses > many languages, of which REBOL is one. Understanding how the
<<quoted lines omitted: 3>>
> a given task, and helps translate an algorithm expressed in > one language into another.
Agree again.
> I have several friends who teach in higher education. I am on > the advisory committees for two computer engineering curricula.
<<quoted lines omitted: 5>>
> "I don't know; let's try it and find out." one has a language > that is not ready for prime time, at least educationally.
I'd say perhaps educationally, just not anywhere else. (;
> Those are a few (though not all) of my motivations for being > interested. Anyone not interested in any of the above issues > is certainly free to ignore the whole discussion. ;-)
Won't be doing that - it's an important one. Though I have to admit that trial and error is sometimes a quicker way to find out how something in REBOL works than looking through the books or on the website for the information, even when it's there. No index with the User Guide was not a good idea. I only hope the View guide has one...
> -jn- > ------------------------------------------------------------ > "Programming languages: compact, powerful, simple ... > Pick any two!" joel'dot'neely'at'fedex'dot'com > ------------------------------------------------------------
-- Carl Read [carl--cybercraft--co--nz]

 [16/19] from: joel:neely:fedex at: 15-Jun-2001 2:05


Hi, Carl, One minor quibble, and one major point of apparent agreement, I think... Carl Read wrote:
...[background snipped]...
> >> > >> Because tuples are like integers "simple" (to use Holger's
<<quoted lines omitted: 10>>
> you replaced would be left hanging around and in need of > discarding in one way or another.
We've agreed (because Holger said so ;-) that integers and tuples are both "simple". So let's get as "simple" as we can. a: 17 a: 42 I would hope we agree that, after the second of these is evaluated, there is not a 17 "left hanging around". It's (simply ;-) GONE because the same bits that used to represent the 17 have been recycled to represent the 42. If that's the case, and if integers and tuples are both "simple" values, then the same logic should apply; there would be no old tuple somehow "hanging around".
> > You're certainly entitled to say that it makes no difference > > to you, but others (including me) may have more of an > > interest. > > My point is that with "simple" datatypes, REBOL could be > either modifying or replacing them and we couldn't tell > either way. >
Rephrasing in terms of REBOL "particle physics", I don't know of any piece of REBOL code whose evaluation would provide different results, depending on whether modification or replacement were the effect of a: now/time a/hour: 12 However, your next comment hits the (my) nail squarely on the head!
> The mental model to have though would be that they've been > modified, as there's no way (as far as I know) to get at the > original again. >
I am concerned with making that mental model as simple as possible, for learnability, teachability, and usability. Please see my most recent post in the "mutability and sameness" thread for why I feel that the distinction (even if not directly testable in REBOL code) make a big difference in the kinds of models needed to describe REBOL. -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [17/19] from: carl:cybercraft at: 16-Jun-2001 12:46


On 15-Jun-01, Joel Neely wrote:
> Hi, Carl, > One minor quibble, and one major point of apparent agreement,
<<quoted lines omitted: 27>>
> (simply ;-) GONE because the same bits that used to represent > the 17 have been recycled to represent the 42.
I say we're just assuming that, because we couldn't tell either way. The interpreter could be storing the 17 somewhere and pointing 'a at somewhere, then storing 42 somewhere-else and pointing 'a at somewhere-else. In fact this is a distinct posibility considering a line or script is checked before it's run...
>> a: 17 a: 42 print a "garbage
** Syntax Error: Missing " at a: 17 a: 42 print a "garbage The 17 and 42 have obviously been looked at by REBOL before it hit garbage. Can you say for sure the 17 and 42 weren't also stored seperately for later use (in integer format instead of as two ASCII bytes) at this syntax checking phase? And if you can't, how can you be sure 'a doesn't change its pointer from pointing to the 17 to the 42, as apposed to placing a 42 where a's pointer points to. Do you see my point! (:
> If that's the case, and if integers and tuples are both
simple"
> values, then the same logic should apply; there would be no > old tuple somehow "hanging around".
And I say you can't be sure, and so I agree with Holger who said this level of speculation about REBOL doesn't get us anywhere. (Well, I think it was Holger who said it.) An interpreter could be written either way (with regard to integers and tuples and their like) and our scripts would behave the same. (Though memory usage and performance mightn't.)
>>> You're certainly entitled to say that it makes no difference >>> to you, but others (including me) may have more of an
<<quoted lines omitted: 20>>
> if not directly testable in REBOL code) make a big difference > in the kinds of models needed to describe REBOL.
Have done, and I've responded to it. And your comments there helped me to better understand what "same" means in relation to REBOL. -- Carl Read [carl--cybercraft--co--nz]

 [18/19] from: joel:neely:fedex at: 16-Jun-2001 9:46


Carl Read wrote:
> >> a: 17 a: 42 print a "garbage > ** Syntax Error: Missing " at a: 17 a: 42 print a "garbage
<<quoted lines omitted: 6>>
> placing a 42 where a's pointer points to. Do you > see my point! (:
Yes. But, see below for mine.
> And I say you can't be sure, and so I agree with Holger who > said this level of speculation about REBOL doesn't get us > anywhere. (Well, I think it was Holger who said it.) >
I belive Holger was actually talking about an even lower level of detail (how many bits a reference or "simple" value might occupy in memory), but still I understand and support his point.
> An interpreter could be written either way (with regard to > integers and tuples and their like) and our scripts would > behave the same. (Though memory usage and performance > mightn't.) >
I am not interested in reverse engineering REBOL's interpreter. I am interested in having an adequate conceptual model of the language that the interpreter implements. There are very many possible models that could be imagined. Therefore: 0) I will reject a model that contradicts what I can find in the documentation or other public statements from RT. 1) I will reject a model that predicts different results or side-effects than I can observe by some test code. 2) I will reject a model that predicts significantly different performance characteristics than I can observe by some test code (i.e., predicting that some operation would be linear when the test exhibits quadratic time complexity, or vice versa). 3) Given alternative models that AFAICT pass all of the above tests, I will consciously choose the one that offers the simplest explanation for what I can observe, that is most consistent with what I know about computing science and programming language implementation, and that contains the least amount of pointless complexity. Having made that choice, I will use and defend that model until either it can be shown to violate any of (0)..(2) or someone can offer an even simpler one. I'm not trying to be pig-headed, and I'll be glad to change my mind based on future disclosures from RT, on evidence, or a compelling argument that there's a simpler way to understand something. But I don't have time to keep changing my mind just because we can imagine another variation.
> Have done, and I've responded to it. >
Thanks! Trying to explain something, and having other folks debate, confirm, or refute that explanation is the only way I know how to learn. (And, of course, I am grateful to all who participate in that process!)
> And your comments there helped me to better understand what > "same" means in relation to REBOL. >
Thanks again! I don't care who is right, only that all of us can jointly come up with the best understanding possible. -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [19/19] from: karlr20:home at: 16-Jun-2001 13:00


On Wednesday 13 June 2001 12:54, you wrote:
> Hi Karl, > You wrote:
<<quoted lines omitted: 34>>
> present time. > -Larry
No, my blocks do not keep a current index. This is trivial to add, though. A block could be implemented with this: struct Block { int reference_count; Value* current_index; // Like an STL vector<Value> Value* start; Value* finish; Value* end_of_storage; }; -Karl

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted