!standard 4.1.6(0) 12-03-15 AI05-0292-1/02 !standard 5.5.1(0) !standard 5.5.2(0) !class Amendment 12-02-15 !status Amendment 2012 12-02-15 !status ARG Approved 10-0-0 12-02-24 !status work item 12-02-15 !status received 12-02-03 !priority Low !difficulty Easy !subject Terminology: "Indexable type" is confusing !summary We rename some concepts: "Indexable type" => "Indexable container type" "Indexable object" => "Indexable container object" "Iterable type" => "Iterable container type" "Iterable object" => "Iterable container object" !problem "Indexable type" as defined in 4.1.6 does not include array types. This is likely to be very confusing; the term either should be inclusive or an alternative term adopted. There is a similar confusion between "iterator type" and "iterable type". !proposal (See wording.) !wording In all of 4.1.6, 5.5.1, and 5.5.2, change: "Indexable type" => "Indexable container type" "Indexable object" => "Indexable container object" "Iterable type" => "Iterable container type" "Iterable object" => "Iterable container object" Replace 5.5.2(2/3) with: iterator_specification ::= defining_identifier in [reverse] iterator_name | defining_identifier [: subtype_indication] of [reverse] iterable_name [This completely deletes the second production.] Replace 5.5.2(3/3) with: For the first form of iterator_specification, called a generalized iterator, the expected type for the iterator_name is any iterator type. For the second form of iterator_specification, the expected type for the iterable_name is any array or iterable container type. If the iterable_name denotes an array object, the iterator_specification is called an array component iterator; otherwise it is called a container element iterator. In all of 5.5.2, change "array_name" to "iterable_name". !discussion We considered "Indexable type" => "Indexable nonarray type" as an alternative. But this doesn't help the second problem. !corrigendum 4.1.6(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum 5.5.1(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !corrigendum 5.5.2(0) @dinsc [A placeholder to cause a conflict; the real wording is found in the conflict file.] !ACATS Test No additional tests needed, this is only a terminology change. !ASIS No change needed. !appendix From: Randy Brukardt Sent: Friday, February 3, 2012 12:27 AM Erhard wrote in his review: > =============== > 5.5.2 2/3, 3/3 (and also 5.5.1 and 4.1.6) > > Part 1 (which is really on 4.1.6) > It comes as a big surprise that array types are not considered > indexable types. Under common sense interpretation of "indexable", > they would be and this will be forever confusing. How do you explain > to someone that "In Ada, array objects are not indexable."? > > 4.1.6. 5/3 should read > An indexable type is a view of an array type or of a tagged type > with .... > > Array types would of course be iterable and reverse iterable in 5.5.1 > 11/3, again on the grounds that they really are :-). > > "tagged" would need to be added to indexable and iterable in a few > selected places, e.g. in 5.5.1 (7.3). (I can certainly identify all of > them on short notice and it does not look like many.) > > 5.5.2 2/3, 3/3 > With the change above, one alternative is enough and the Grammar and > RM-verbiage can be simplified: > | defining_identifier [: subtype_indication] of [reverse] > iterable_name > > "... The second form of iterator_specification is called an array > component iterator if the iterable_name denotes an array object; it is > called a container element iterator if the iterable_name denotes an > iterable tagged object." > ===================== I have a lot of sympathy for this concern, but the suggested change does not work very well. First, you're suggesting that a "tagged indexable type" is how we differentiate these from an array. That looks to be confusing at best, and morevoer is a maintenance hazard (if we ever extend tagged types to include arrays, currently the only composite type that cannot be tagged -- which seems like a wart). But a bigger problem is how to handle "indexable object"; this is an object of an "indexable type", and that term is used as a syntax prefix and all over 4.1.6. If we include arrays as indexable objects, then we have massive ambiguities between indexed_components and generalized_indexing. If we says that indexable objects are only those that have "tagged indexable types" (or whatever), then the original confusion is back. And saying "tagged indexable objects" everywhere is insane and emphasizes the wrong thing ("tagged"). Lastly, changing the terminology at the last minute to include arrays is likely to introduce bugs. Lots of bugs. Especially as we tried that long ago and had quite a few problems with it. So while I think you're right that there's a problem, I don't think the solution flies. -------- It's clear to me that we need different terms than "indexable type" and "indexable object". The best I can come up with (perusing an on-line thesaurus) is to call this "generalized_keying" and then we would have "keyable type" and "keyable object". Other options don't work well ("list" - has a meaning; "guide" - too general; "register" - doesn't seem to have the right meaning). But this idea tends to obscure the similarities with arrays. We probably don't want to do that too much. --------- Thus my best idea is to prefix these terms with a form of "generalized". It will make the wording more wordy, but will avoid (or at least reduce) the likelyhood that someone will expect arrays to be covered. Unfortunately, "generalized" itself doesn't work very well ("generalized indexable type" is clunky - "generalized" is the wrong kind of word). My next thought is "generally indexable type", but (after I stopped laughing) that has the wrong connotation. So my "best idea" doesn't work, either. --------- So I think we need to get rid of the term "generalized" and replace it with something that does work as a prefix. (I've never much liked it.) The thesaurus is not much help: "vague", "obscure", "unspecified", "hazy", "nebulous"! "Unspecified" already has a meaning, of course, and the rest are good for a laugh but probably not for a language term: "hazy_indexing" => "hazily indexable type" :-) "nebulous_indexing" => "nebulously indexable type" :-) :-) "vague_indexing" => "vaguely indexable type" Going out to "general", we find words like: "across-the-board", "blanket", "broad-brush", "common", "generic", "global", "overall", "universal", most of which have Ada meanings already or really would be weird: "blanket_indexing" => "blanketly indexable type". Another list gives: "all-around (also all-round), all-purpose, catholic, general-purpose, unlimited, unqualified, unrestricted, unspecialized, mixed-use, multipurpose, broad, wide, nonspecific, unspecified, vague". "catholic_indexing" :-) "broad" almost works "broad_indexing" => "broadly indexable type". But it doesn't feel right to me. --------- So I'm almost out of ideas. The last idea is to sort of use Erhard's original idea, and call them "non-array indexable types". (Or should that be "nonarray"? I can never remember what we decided.) Perhaps there could be a small amount of simplification if we actually defined "indexable type" as "non-array indexable type" or "array type", but I'm skeptical that it would be worth the effort (and it surely would be risky). Anyway, as this is going to take a half a day or so to actually do, I think we need some agreement on how to proceed (and specifically what terms to use) before I do this. And in order to meet the deadlines after the meeting, this has to be decided now so I can make the changes in the meeting draft -- there is little value to talking about these terms when we have real work to do. **************************************************************** From: Erhard Ploedereder Sent: Friday, February 3, 2012 6:48 AM I meant to make it "indexable tagged type", not "tagged indexable type". (just like "indexable array type", not "array indexable type") (If one ever considered tagged arrays (what is the brand you're smoking ;-)), it would fall under tagged type, surely, not under array type, or else lots and lots of array rules would have to be rewritten.) To pick up Randy's idea, though: any term in lieu of "indexable" that would not immediately apply to arrays in a common usage interpretation of the word would be fine with me to resolve the comment. **************************************************************** From: Tucker Taft Sent: Friday, February 3, 2012 12:11 PM We use "user-defined" as a prefix in some cases (e.g. in 3.2.3 when talking about "predefined" vs. "user-defined" operators, primitive subprograms, operations, etc. So "user-defined indexable type/object" might be the way to avoid having to say that an array is *not* an indexable object. Essentially substitute "user-defined" for Erhard's suggested use of "tagged". **************************************************************** From: Edmond Schonberg Sent: Friday, February 3, 2012 12:23 PM You mean to imply that: type toolbox is array (integer range <>) of widget; is NOT user-defined? **************************************************************** From: Tucker Taft Sent: Friday, February 3, 2012 12:42 PM Good point. It's indexing operation is predefined, even though the type is user defined. So we might have to say "type with user-defined indexing". Ugh. So we are back to indexable tagged types/objects? That is similar to our "synchronized tagged types, so there is somewhat of a precedent. **************************************************************** From: Randy Brukardt Sent: Friday, February 3, 2012 10:48 PM I still don't like this, because the fact that the type is tagged is pretty much irrelevant to the user -- it's just an accident of the construction of this feature. (Not to mention it would cause trouble if we ever expanded the scope of tagged types.) The user cares that the indexing is user-defined vs. pre-defined. This seems most important for the "object" part of the definition (it seems strange to call an object tagged). No one ever commented on my preferred suggestion of "nonarray" (or is that "non-array"?). That seems to be closer to the user view of what is going on here. (But the lack of comments might be an answer in itself.) Also, I should note that in my laundry list last night, I didn't try anything as a suffix. For instance, we could use some form of general as a suffix: "indexable general type", "indexable general object". Or maybe: "indexable generalized type", "indexable generalized object". Ordinary? "indexable ordinary type", "indexable ordinary object". Nah. So I think we have 5 serious suggestions: (index => key): "keyable type", "keyable object" (tagged as a suffix): "indexable tagged type", "indexable tagged object" (tagged as a prefix): "tagged indexable type", "tagged indexable object" (non-array as a prefix): "non-array indexable type", "non-array indexable object" (non-array as a suffix): "indexable non-array type", "indexable non-array object" Any other suggestions? Any good reason to rule any of these out? Do we need a straw poll to decide on an option? **************************************************************** From: Randy Brukardt Sent: Friday, February 3, 2012 11:01 PM > I meant to make it "indexable tagged type", not "tagged indexable > type". > (just like "indexable array type", not "array indexable type") > > (If one ever considered tagged arrays (what is the brand you're > smoking ;-)), it would fall under tagged type, surely, not under array > type, or else lots and lots of array rules would have to be > rewritten.) There is always some interest in allowing all types to be tagged, with the intent that the tag is not stored with the object (of a specific type), but rather is created at the call site if needed for dispatching. I know that something on this line was considered for Ada 9x, and was dropped in "scope reduction". (The best idea is that all types are tagged, period.) Indeed, if you every want to get rid of my incessant "generic sharing" mantra, something like this would need to be adopted. It would provide a way to write routines that would work pretty much like our Ada 83 generic implementation (without the clunky need for instantiation); and I think it would push about 90% of the use cases for generic sharing to use Root_Integer'Class and the like instead. (It also would provide a possible solution for the string representation nightmare.) If we reduced the value of sharing that much, I probably could be persuaded to give it up. [Maybe. ;-)] Anyway, if something like this was adopted, a "tagged array type" surely would have predefined indexing (and slicing) [I can't imagine what else it would mean, or why we'd want it without those things], and as such we wouldn't want it to allow "generalized indexing". So for the purposes of these rules we surely would not want to seem like it belonged to the generalized indexing rules. Of course, this is a minor consideration for Ada 2012. I'd rather not use "tagged" here for these reasons and the (better) reasons outlined in my other message. But I surely can live with it if we don't find anything better. **************************************************************** From: Tucker Taft Sent: Saturday, February 4, 2012 10:52 AM "keyable" doesn't make it for me. Indexable non-array type is OK, though a bit of a mouthful. Another possibility would be "indexable container type." "Container type" isn't defined, but that seems OK, presuming we are going to define the whole phrase "indexable container type" and "indexable container object." **************************************************************** From: Erhard Ploedereder Sent: Saturday, February 4, 2012 12:16 PM > "indexable container type" and "indexable container object." I like that! Same for iterable, I presume? **************************************************************** From: Randy Brukardt Sent: Saturday, February 4, 2012 4:02 PM > I like that! Me, too. Its certainly better than the other choices we've looked at. > Same for iterable, I presume? How so? We don't define an "iterable type", we define an "iterator type", which is clearly something different (there is no reason to assume that an array or scalar type is an "iterator", as opposed to "iterable"). Ohhh, sorry, I see that we do in fact define "iterable type" later in 5.5.1. I already find that confusing, so I agree, that should also have container added into it. "iterable container type". ****************************************************************