[REBOL] Re: TUPLE! DATA-MODEL & OTHER VALUES
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,
> I think...
> Carl Read wrote:
>>
> ...[background snipped]...
>>>>
>>>> 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.
>>
>> 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.
>>
> 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.
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
>>> 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.
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]
