[Info-vax] DEC Basic and dynamic memory ?

[Dave Froble]

On 1/31/2022 12:06 PM, Arne Vajhøj wrote:
> On 1/31/2022 11:38 AM, Dave Froble wrote:
>> On 1/31/2022 8:55 AM, Simon Clubley wrote:
>>> On 2022-01-30, Dave Froble <davef at tsoft-inc.com> wrote:
>>>> On 1/30/2022 7:09 PM, Simon Clubley wrote:
>>>>> On 2022-01-30, Arne Vajhøj <arne at vajhoej.dk> wrote:
>>>>>> On 1/30/2022 6:54 PM, Simon Clubley wrote:
>>>>>>> On 2022-01-29, Arne Vajhøj <arne at vajhoej.dk> wrote:
>>>>>>>> In this case Simon outlined a problem where Pascal and C are obvious
>>>>>>>> languages and me with no Basic experience wrote some Basic code - that
>>>>>>>> is almost ensure an "unsual style". Or to put it another way: I am
>>>>>>>> (or was) a Fortran programmer and Fortran programmers can program
>>>>>>>> in Fortran in any language.  :-)
>>>>>>>
>>>>>>> Thanks for the demo program Arne.
>>>>>>>
>>>>>>> The approach you are forced to use in DEC Basic is way more ugly than
>>>>>>> doing it in C or Pascal.
>>>>>>
>>>>>> Ugly or just unfamiliar?
>>>>>>
>>>>>
>>>>> Ugly because of all the tree management stuff you have to do for
>>>>> yourself that you get for free in C or Pascal.
>>>>>
>>>>> In addition, there's the overhead of copying the tree everytime
>>>>> you run out of allocated spare space and need to extend it.
>>>>
>>>> Bullshit!  Just not true.
>>>
>>> Arne's example makes it very clear that when you run out of spare nodes
>>> in your backing storage in DEC Basic, and hence have to grow the backing
>>> storage by the growth increment, you have to do a copy of the existing data.
>>
>> Arne tried to provide a simple and quick and dirty example.  Doesn't have to
>> be that way.  Would not be that way in well designed code.
>>
>> The nice thing about links is that the storage does not have to be linear.
>>
>>> How would you grow the existing backing storage without either you or
>>> the DEC Basic RTL doing a copy of the existing data when you extend it
>>> by the growth increment ?
>>
>> I'd just point to additional storage.
>
> I am sure there are other possible designs.
>
> But a single contiguous array is a simple design.

Yes, it is, and that is what anyone with any sense would do, if it is adequate 
for the job.  Most likely needing more is few and far between.  But, if needed, 
one can go beyond that.

> And it seems primitive but it is not as bad as it seems.

I don't see it as bad in any way.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486