-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems with GOOL arrays #3508
Comments
Commenting in same order:
|
Yes, I think I bring up L-values specifically in reference to the function
where by I think at a minimum (in part driven by my desire to use arrays as the underlying type for vectors) we should have
|
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. |
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. |
We do have an open issue about adding L-values in GOOL, just FYI: #1715 |
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 😂) |
Yes. vectors and matrices are 'semantic' objects and arrays are 'storage' objects, but both have intrinsic dimensions. |
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. |
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.
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 classList
. 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 inlistAccess
inGOOL.Drasil.LanguageRenderer.LanguagePolymorphic
refers to both arrays and lists as "list types").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.
The text was updated successfully, but these errors were encountered: