Making Revolution faster using dimensioned arrays

[Dennis Brown]

On Jul 5, 2005, at 12:04 AM, Ken Ray wrote:

> I really like this idea, Dennis, but I'm not sure I like the  
> approach to
> dimensioning, only because of Transcript's history of being able to
> interpret things as strings, even if not quoted. So is:
>
>   local myArray[100,300]="false"
>
> a boolean array, or a 5-character word array? Perhaps it's  
> acceptable to be
> more picky about this (i.e. the above would be a 5 character word  
> array),
> since we don't currently have a way of assigning a type, but I  
> think there's
> a better way. For example, using your approach, if you wanted a 25  
> character
> word array, you'd have to provide a 25-character-long string.
>
> It seems to me that the main thing is not the *type* of data, but  
> for the
> interpreter to know that there is a fixed size to array elements.  
> So perhaps
> something like:
>
>   local myArray[100,300] length 5
>
> or something like that...

Ken,

Yes, that is why I wanted to start a discussion about his before  
putting in a BZ request.  There is more than one approach to the  
syntax even though the basic idea is the same.

It might be better to separate the declaration of the variable from  
the dimension statement.  Since Transcript does not care what type or  
length a variable is when it is declared, no change would actually be  
needed to declare its scope.  That way it is easier to include the  
dimension command later with non-constant arguments --which would be  
better for resizable graphics.  There is no reason that a variable  
could not be re-dimensioned more than once --however the contents  
would get reset.

I thought that it would be just as easy to specify the type implicit  
in the data value that was used to initialize the string --fixed  
dimension arrays have every element filled except in the case of a  
string array that includes a char count which could be zero.  I don't  
think the user should have to know the exact internal format of the  
data type chosen --unless he is writing an external.  If there are  
two sizes of integer formats, then perhaps they are specified a short  
or long instead of 2 byte or 4 byte.

Having a variable length string type is another fine point.  Does it  
make sense to have a variable length string type at all, since  
Transcript is already very robust in the string area.  Perhaps it is  
sufficient to have only a fixed number of chars that are padded out  
with a "blank" char.  I could go either way, but having a char count  
for a string type would be more general and it would increase the  
number of uses.  Perhaps the length is a max of 127 or 255 characters  
--only short strings would benefit from a fixed length array.

I still have a lot of questions about how different people would use  
this type of array.  Right now, I could use over half of the types  
below in just one application that does not even use any images:

local myArray

dim myArray[ imageHeight, imageWidth ] RGBpixel=0,0,0 --how many  
image pixel formats do we need?
dim myArray[ rows, columns, pages ] realNumber=0 --do we need 32 and  
64 bit numbers?
dim myArray[ rows, columns ]  short integer=0 --do we need 8,16,32  
bit numbers?  What does Rev internally support now?
dim myArray[ rows, columns ] string=20 --length initialized to 0,  
good for short variable length strings
dim myArray[ rows, columns ] chars="abcd" --always 4 bytes long, good  
for fixed format words
dim myArray[ rows, columns, map ] boolean=0 --compact one bit logic  
arrays, bit masks


Dennis