4 Years Later, I Ran This Question By Claude.AI...
I'm trying to rename the superclass in the Rebol language for BLOCK! and PAREN! from ANY-BLOCK! to something that doesn't suggest that a PAREN! (which I've renamed to GROUP!) is in the category of "block"
The reason for this is that I've expanded it to have many more types of block, such as: [plain blocks], [set blocks]:, :[get blocks], @[the blocks], &[type blocks], and $[var blocks] ... these are the ANY-BLOCK! types.
Similarly there are (plain groups), (set groups):, :(get groups), @(the groups), &(type groups), and $(var groups) ... these are the ANY-GROUP! types.
So if you were trying to name the superclass of all these types, you might think of something like ANY-ARRAY! or ANY-LIST!
Rebol has historically tried to use unintimidating terms instead of "scary" computer science terms. Which makes ANY-LIST! seem friendlier. You can just say these are all lists.
However, from a computer science perspective, "List" often connotes a linked list. The underlying implementation of blocks and groups is an array... more specifically the values are arrays which hold an index. (More like an iterator, even.) They're weird in other ways, such as storing a newline marker on their elements so they lay out two dimensionally.
But I don't know of any sensible word for the superclass besides Array or List. Vector is something else (packed numeric only). I've favored Array since it gives more of a hint at the implementation.
Are there any other words for the superclass? Do you think Array is the smarter option here or is List's friendliness worth it since there is no great parallel to anything that exists? (The Red programming language--derived from Rebol--chose ANY-LIST!, fwiw)
This is an interesting naming challenge. You're right that the choice between ANY-ARRAY! and ANY-LIST! each have their pros and cons. Let's explore some options and considerations:
- ANY-ARRAY!:
- Pro: More accurately reflects the underlying implementation.
- Pro: Distinguishes from linked lists in computer science.
- Con: Might sound more technical to non-programmers.
- ANY-LIST!:
- Pro: Friendlier and less intimidating to newcomers.
- Pro: Aligns with Red's choice, maintaining some consistency in the Rebol family.
- Con: Potentially misleading from a CS perspective.
- Alternative suggestions:
- ANY-COLLECTION!: This is a more general term that doesn't imply a specific implementation.
- ANY-SEQUENCE!: Emphasizes the ordered nature without specifying implementation.
- ANY-CONTAINER!: Very general, but might be too broad.
- ANY-STRUCTURE!: Generic but implies organization.
- Rebol-specific ideas:
- ANY-ENCLOSURE!: Plays on the idea of enclosing elements, whether with brackets or parentheses.
- ANY-GATHER!: A friendly verb-based name that suggests collecting items together.
- ANY-BUNDLE!: Another friendly term that implies a collection of items.
Considering Rebol's philosophy of using unintimidating terms, I lean towards recommending ANY-LIST! despite its potential CS inaccuracy. Here's my reasoning:
- Consistency with Red (ANY-LIST!) could be beneficial for the broader Rebol ecosystem.
- For most users, the implementation details (array vs. linked list) are less important than the concept of an ordered collection of items.
- The term "list" is very intuitive and aligns well with Rebol's user-friendly approach.
However, if you feel strongly about conveying the array-based nature, ANY-ARRAY! is a perfectly valid choice. It's not overly technical and still gives a hint about the implementation.
If you want a middle ground, ANY-SEQUENCE! might be worth considering. It conveys the ordered nature without implying a specific implementation, and "sequence" is a term that's both friendly and somewhat familiar in programming contexts.
Ultimately, the choice depends on whether you prioritize technical accuracy or user-friendliness in this case. Given Rebol's history and philosophy, I'd suggest leaning towards the more approachable term unless you have a strong reason to emphasize the implementation details.
As it happens, I'm actually using ANY-SEQUENCE! for ANY-PATH! and ANY-TUPLE!.
In my model, paths and tuples are immutable sequences of elements (with no position). So you can have a.b.10 or @foo/[bar]/20/30 or whatever. If you have a better idea for what that superclass should be called, I'd be interested to hear it! But it's not often that people need to mention the superclass of those types, so I don't mind it being kind of a longer, more esoteric-sounding word.
The Array/List superclass comes up more often.
ANY-BUNDLE! is kind of funny, I actually have a proposal that might reasonably be called a bundle. Thanks for that--but I don't think it fits here.
I see! That's interesting that you're already using ANY-SEQUENCE! for paths and tuples. Given this context, let's reassess our options for the block/group superclass:
- Sticking with ANY-ARRAY! or ANY-LIST!: These remain valid options. The distinction from ANY-SEQUENCE! actually helps clarify the different nature of these types compared to paths and tuples.
- ANY-COLLECTION!: This becomes more appealing now, as it clearly differentiates from sequences while still being general enough to encompass both blocks and groups.
- ANY-ENCLOSURE!: This option gains some merit, as it nicely captures the idea of elements enclosed in brackets or parentheses, distinguishing it from the sequence types.
- New suggestions based on this information:
- ANY-COMPOUND!: Suggests a compound structure that can hold multiple elements.
- ANY-AGGREGATE!: Implies a collection of items grouped together.
- ANY-SERIES!: While similar to sequence, it might convey a slightly different meaning that fits blocks and groups better.
Given this new context, I'm inclined to recommend ANY-COLLECTION! as the top choice. Here's why:
- It's distinct from ANY-SEQUENCE!, which helps users understand there's a fundamental difference between these types and paths/tuples.
- It's a friendly, intuitive term that aligns well with Rebol's philosophy.
- It's general enough to encompass both blocks and groups without implying a specific implementation.
- It's commonly used in programming contexts, so it won't be unfamiliar to those with some coding experience.
ANY-ENCLOSURE! would be my second choice, as it nicely captures the syntactic nature of these types (enclosed in brackets or parentheses).
If you prefer to lean more towards the implementation details, ANY-ARRAY! remains a solid option. It clearly distinguishes from ANY-SEQUENCE! and gives a hint about the underlying structure.
Regarding the superclass for paths and tuples (ANY-SEQUENCE!), it seems like a reasonable choice given their nature. If you wanted alternatives, you might consider:
- ANY-CHAIN!: Emphasizes the linked nature of elements.
- ANY-PROGRESSION!: Suggests an ordered sequence of elements.
However, ANY-SEQUENCE! is probably sufficient, especially if it's not frequently referenced in everyday use.
ANY-SERIES! would be great, except for the fact that series is the superclass of strings, blocks, groups, binaries... that's pretty much been the whole history of Rebol.
Rewriting the world from scratch, one might say that ANY-SERIES! is specifically the array types, and that the "Rebol Series" -- specifically those arrays-- are the fundamental force of the language. Then something like ANY-SEQUENCE! would be the superset which pulls in the more conventional strings and binaries and such.
Might have been interesting if the terminology hadn't gotten so widely propagated--but definitely wouldn't be worth the disruption just to avoid saying Array or List!
Being mindful of compatibility with Red does seem nice but they're not very interested in consensus with my project. In fact, the only reason I'm thinking about this is from a point of competition and I don't want them to have picked the better term. 
One advantage--albeit a tiny one--is that LIST is one less letter than ARRAY, and a somewhat "cleaner" looking word with no repeated letters and just kind of less "weight" in the letters themselves. ("I" is thinner than "R", etc.)
Anyway, thanks for the ideas!
Thanks for providing that additional context about the history and current structure of Rebol. It's fascinating to see how these naming conventions have evolved and the considerations that go into them.
You're right that ANY-SERIES! being historically used for a broader set of types (including strings and binaries) makes it less suitable for this specific use case. It's indeed an interesting "what if" scenario to imagine reorganizing these concepts, but as you point out, the disruption wouldn't be worth it at this stage.
Given all the information you've shared, and considering the trade-offs between technical accuracy, user-friendliness, and historical context, it seems we're circling back to the original dilemma between ANY-ARRAY! and ANY-LIST!.
Let's summarize the final pros for each:
ANY-ARRAY!:
- More accurately reflects the implementation.
- Clearly distinguishes from ANY-SEQUENCE! and other types.
- Gives a hint about the underlying structure to more technical users.
ANY-LIST!:
- Friendlier and less intimidating to newcomers.
- Shorter word (as you noted, one letter less and "cleaner" looking).
- Potentially more intuitive for describing the concept to non-technical users.
Given Rebol's history of prioritizing user-friendliness and your observation about the visual "weight" of the word, I'm inclined to suggest going with ANY-LIST! after all. Here's my reasoning:
- It maintains Rebol's philosophy of using approachable terminology.
- The visual advantage, while small, adds up when the term is used frequently.
- For most users, the concept of a "list" is likely more immediately graspable than an "array".
- The potential CS inaccuracy is mitigated by the fact that this is a domain-specific term within Rebol, not a general CS concept.
That said, ANY-ARRAY! is still a perfectly valid choice if you feel the technical accuracy outweighs the slight advantage in friendliness.
Ultimately, both terms are good options, and the choice might come down to which aligns better with your vision for the language and its users. If you're aiming to make the language as approachable as possible, ANY-LIST! might have a slight edge. If you're looking to appeal more to technically-minded users or want to hint at the implementation, ANY-ARRAY! could be the way to go.