Re: next "big" language?? (disagree)

["Kevin J. Weise" <kweise@c3i-ccmail.sed.redstone.army.mil>]

James_Rogers <jrogers> wrote (with deletions):
>rav@goanna.cs.rmit.EDU.AU (++           robin) wrote:
>
>>   Are you seriusly suggesting that EACH time the program
>>is run that it be edited and recompiled?  And what
>>happens -- as is often the case -- the size of the array
>>changes DURING the run?
>
>Now you are approaching the real problem.  Arrays are must
>always have a specific size.  That size may be defined at
>compile time or it may be det4rmined at run time using
>dynamic allocation.  Either way a given instance of an array
>does not change its size.  If this is not enough reason to
>use some other more dynamic data structure such as a list or
>a tree, then the common methods used with arrays include the
>concept of declaring a size which is the largest expected for
>current needs.  A subset of that array is typically used for
>the problem at hand, wasting the remainder for future growth.
>
>The point is that every array must be accompanied by some method
>of indicating the specific subset of elements to be processed.
>In C this means one typically either passes an array pointer and
>a size parameter, or a special character is expected to be
>embedded in the array to mark the end of useful data ( the NULL
>character, for instance).

Methinks you missed one other alternative, Mr. Rogers.  It is 
also possible to elaborate, at runtime, an array of appropriate
size without having to use dynamic (i.e., heap) memory.  E.g.:

    procedure Made_Up_Example (MAX_SIZE : Natural) is
       THIS_STRING : String (1..MAX_SIZE);
    begin
       -- whatever
    end Made_Up_Example;

Obviously, the parameter value cannot be expected to be static, 
so you (and the compiler) can safely assume the amount of memory
needed for THIS_STRING will probably vary from one invocation to
another.  (In fact, the memory gets allocated for it on the stack 
when its declaration is elaborated.)  Then you only need to figure 
out how big an array you need *before* invoking your subprogram.  
This works great with blocks,too.  On nice machines that let your 
stack space float to however much virtual memory your program
needs, you can have great flexibility without having to use the 
heap or the old FORTRAN-style "declare it as big as your biggest 
possible need" method.  And you don't have to edit/recompile/relink 
everytime the size changes!  The only problem I recall having with 
this is when the subprogram (or block) is executed within the 
context of a task whose default stack size is insufficient to 
handle the block creation.  But that is relatively easy to solve 
with a 'Size pragma.

-------------------------------------------------------------
Kevin J. Weise                kweise@c3i-ccmail.sed.redstone.army.mil
COLSA Corporation             voice:  (205) 842-9680
Huntsville, AL