Le 21/03/2022 à 20:22, Bald Eagle a écrit :
> Bruno Cabasson <bru### [at] yahoofr> wrote:
> 
>>   > extend() - not sure how far you will be able to .. bend SDL , but
>> think that
>>   > an important macro like extend should be "general".  clipka's advice
>> wrt arrays
>>   > was (paraphrasing) "if you know the #elements in advance, declare the
>> array
>>   > sized"; however, if I were to:
>>   >    #declare A = array [2] {"a","b"};
>>   >    #declare B = array [2] {"c","d"};
>>   >    extend(A,B)
>>   > I'd get: "Parse Error: Array subscript out of range".
>>   >
>>
>> ===> You are correct. The use of some PROOF features may (and will)
>> imply some restrictions. But that's highly secondary for me. In this
>> particular case, I don't know if Sdl can detect if the array is of fixed
>> sized. Please, enlighten me.
> 
> I don't think it can tell in a non-error triggering way.
> 
> Looking at your code,
> 
> #macro extend(arr, extension_arr)
>      // We cannot know whether an array is "array" or "array mixed".
>      // So we let the parser generate an error if elements are of incompatible
> types.
>      #local start = dimension_size(arr, 1);
>      #for (i, 0, dimension_size(extension_arr, 1) - 1)
>          #local arr[start + i] = extension_arr[i];
>      #end
> #end
> 
> I think all you have to do is determine the size of both arrays, create a
> temporary array of either dynamic size, or big enough to hold all the elements
> of both, fill that array, and then declare the original array identifier name to
> now be the new temporary array.

==> this could change the nature of the target array. What would be the 
type of the resulting array (fixed/variable size, array/array_mixed)? 
The code should choose one possibility among 4, for example variable 
size array mixed. I think the code above is quite generic for both 
parameters, except for "arr" which must only be of variable size. That 
is one (small) of the restrictions for using PROOF. The parser does the 
appropriate checks during assignment.

However, my purpose during this VERY early stage of exploring a Proof Of 
Concept, and implementing a feasibility-showing Sdl code, is to 
determine if 3.8b2 features allow to define and implement basic 
Object-Oriented features, such as classes, properties, methods, 
inheritance, without too much dammage concerning syntax and usage ... If 
it is the case - and I think it is, see my future post with oocore.inc 
and its test code in the next hours - it would mean that we can benefit 
from the Object-Oriented'ness, even if it is with some restrictions. But 
it is just an exploration.

"primitives.inc" ans "collections.inc" are just helpers for now. They 
are NOT what is to foscus on now. Despite their quite secondary nature, 
I wrote test code to ensure minimal behaviour.

> 
> That would also let you get around the mixed array error, by making temporary
> array a mixed type.
> 

Hi,

Thanks for the suggestion.

While writing the code, I was facing two possibilities :

1) extend(my_arr, extension_arr),
	restriction :  my_arr is not declared of fixed size (PROOF standard ?)

or

2) #declare my_extended_arr = extend(my_arr, extension_arr)
	restriction : my_extended_arr is of a chosen type
	(variable/fixed size, array/array mixed), unless we use
	a 3rd parameter.


I decided arbitrarilly to write the first one : in-place extension, 
pretty much like Python's my_list.extend(extension_list), and assume the 
"small" restriction that arrays in PROOF are not declared fixed size. I 
am looking for functional OO features, not performance nor memory 
efficiency.

In the second case, perhaps a primitive named something like 
"catenate()" could to the thing. I can write it later.

I was also thinking of someting like python's "zip()"... But for now, I 
concentrate on OO aspects and feasibility.

Cheers


-- 
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus

Post a reply to this message