Problems with GOOL arrays

[hrzhuang]

Each of these might need to be its own issue, but I thought to create this issue to start a high-level discussion about what we want from arrays in GOOL.

• There is no way to query the length of an array in GOOL. Fixing this would involve switching from C arrays to std::array in C++, but I think this is idiomatic in modern C++ and brings it in line with our other OO languages.
• listAccess works for both arrays and lists (this is not a happenstance, it explicitly pattern matches on the type of its argument). This is not true for any other method of the class List. I think we should restrict it to only lists and create separate functions for arrays, to avoid confusion about what we mean by "list" (the error message in listAccess in GOOL.Drasil.LanguageRenderer.LanguagePolymorphic refers to both arrays and lists as "list types").
• Another way to index into arrays is with arrayElem which treats an element of an array as a variable whose name is literally "arr[i]" (as an example). I think this is an abuse of the notion of a variable, especially in relation to my recent work on tracking and generating variable names. Ideally we should have a separate notion of an "L-value" (to borrow a word from C++) that includes both variables and array elements, but a much smaller change we can make is to have separate functions in GOOL to get and set array elements.

Note that none of these changes would affect any currently generated code, as we currently have nothing that actually uses arrays instead of lists.

[JacquesCarette]

Commenting in same order:

• agreed
• well, I think the issue here is a mismatch between external API and implementation. We need to think about what GOOL offers. We might need to think in terms of interfaces instead. I think the current design only offers a single container type.
• yes, internally to GOOL, it would make sense to have the concept of an L-value. This shouldn't leak onto its API though.

[hrzhuang]

Yes, I think listAccess works this way for implementation reasons, it allows the at function (which I assume is supposed to operate on both lists and arrays) to be defined to be just listAccess. But from the perspective of a new developer reading this code, I found it confusing. I think it would be less confusing for the polymorphism over lists and arrays to be in at as opposed to listAccess.

I bring up L-values specifically in reference to the function

arrayElem :: Integer -> SVariable r -> SVariable r

where by SVariable r it really means L-value, because currently it constructs a variable with the name "arr[i]" which is an abuse. Now having this be an SVariable r allows us to assign to array elements the same way we assign to variables, using +=, -=, ++, etc. in addition to =. And if we want to continue to have assignment be polymorphic over variables and array elements without abusing variables, then assignments would operate on L-values and L-values would be part of the API.

I think at a minimum (in part driven by my desire to use arrays as the underlying type for vectors) we should have

1. arrayLength to query the length of an array
2. arrayIndex to get an element of an array
3. arraySet to set an element of an array

[JacquesCarette]

I just want to make sure that not all languages are forced to implement these. But it does make sense for the backend to know about all these features of a language.

[hrzhuang]

Do you mean L-values? L-value is a C++ term but I am borrowing it just to mean "something that can be read from and assigned to," which is universal across languages. Currently we are abusing the notion of a variable for this purpose, but array elements (e.g. arr[i]) are not variables but they can still be read from and assigned to.

[bmaclach]

We do have an open issue about adding L-values in GOOL, just FYI: https://github.com/JacquesCarette/Drasil/issues/1715

[samm82]

This may be related to your first point about querying the length of arrays in GOOL: we currently have an issue open for allowing the dimensions of vectors and matrices to be either known at creation (static) or not (dynamic); should this also be done for arrays? (This question is directed at everyone 😂)

[JacquesCarette]

Yes. vectors and matrices are 'semantic' objects and arrays are 'storage' objects, but both have intrinsic dimensions.

[JacquesCarette]

Just FYI for @hrzhuang : L-value is a generic programming language term meaning "any expression that occurs on the left-hand-side of an assignment which denotes a memory location". The 'L' comes from "left hand side". The odd thing about them is that they really look like expressions (aka values) but are used to denote locations. This is super-confusing to language learners.