I Had An Afterthought On An Advantage for ANY-LIST!
I just thought of an advantage of List that I had not really thought about before... pertaining to the implementation code.
Right now, we have a situation where there's a datatype for representing the allocated memory for the vector of cells, and that's called an Array. e.g.:
Array *a = Make_Array_Core(10, NODE_FLAG_MANAGED); // 10-element managed array
But then, there's initialization code to make the value cell that holds it. Sometimes you know the precise kind of thing you want to make so you use a function for that:
Init_Block(OUT, a); // make a BLOCK! at index 0 whose data uses this array
However, sometimes you have the kind of thing in a variable, and you have to pass it in to a generalized initializer. If it was Init_Array() that would kind of suck... you're passing an Array into something that inits an array?
So I've used Init_Any_Array() to distinguish it by pointing out the value class.
Heart heart = set_flag ? TYPE_SET_GROUP : TYPE_GROUP;
Init_Any_Array(OUT, heart, a);
It's not super great. But if List were the superclass, it could be:
Heart heart = set_flag ? TYPE_SET_GROUP : TYPE_GROUP;
Init_List(OUT, heart, a);
While this may not be compelling to those who don't work on the code, it's definitely compelling to me to have the source get cleaner with this distinction. Enough to actually sway my vote to ANY-LIST!.
(A similar thing drove me to call the internal type for runtime frames a "Level" instead of a "Frame", so that Frame could refer to FRAME! values... and that's a decision I don't regret.)
That's an excellent point you've raised, and it's a perfect example of how naming decisions can have far-reaching impacts on code clarity and maintainability. Your insight about the distinction between the underlying Array implementation and the List as a higher-level concept is very valuable. Let's break down why this is indeed a compelling reason to choose ANY-LIST!:
- Code Clarity: The distinction between
Make_Array()(for the low-level array implementation) andInit_List()(for the higher-level concept) provides immediate clarity about what's being initialized. This reduces the cognitive load on developers working with the codebase.- Abstraction Levels: Using LIST for the higher-level concept helps maintain a clear separation between the implementation details (Arrays) and the abstract data type (Lists). This is good software engineering practice, as it allows for potential future changes to the implementation without affecting the higher-level API.
- Consistency: As you mentioned with the "Level" vs "Frame" example, having distinct terms for internal implementation and user-facing concepts can lead to more consistent and intuitive naming throughout the codebase.
- Readability:
Init_List(OUT, heart, a);is indeed more readable and self-explanatory thanInit_Any_Array(OUT, heart, a);. It immediately conveys what's being initialized without the need for the "Any" qualifier.- Flexibility: If you ever decide to change the underlying implementation from an array to something else, the LIST abstraction would make this transition smoother, as the high-level concept remains the same.
- Pedagogical Value: For those learning the language or working with its internals, this clear distinction between Lists (the concept) and Arrays (the implementation) can be educational, helping them understand the layers of abstraction in the language design.
Given this new perspective, I strongly agree that ANY-LIST! is the better choice. It not only aligns with Rebol's philosophy of user-friendliness but also offers tangible benefits in terms of code organization, readability, and maintainability.
This is a great example of how sometimes the best naming decisions come from considering not just the end-user perspective, but also the perspective of those working on the language itself. The fact that it makes the source code cleaner and more intuitive is a significant advantage that will pay dividends in the long term, both for you as the maintainer and for anyone else who may work on the codebase in the future.