Version 1.1 of ai05s/ai05-0292-1.txt

Unformatted version of ai05s/ai05-0292-1.txt version 1.1
Other versions for file ai05s/ai05-0292-1.txt

!standard 4.1.6(0)          12-02-16 AI05-0292-1/01
!standard 5.5.1(0)
!standard 5.5.2(0)
!class Amendment 12-02-15
!status Amendment 2012 12-02-15
!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"
!proposal
"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".
!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"
!discussion
We considered "Indexable type" => "Indexable nonarray type" as an alternative. But this doesn't help the second problem.
!corrigendum 4.1.6(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict file.]
!corrigendum 5.5.1(0)
Insert new clause:
[A placeholder to cause a conflict; the real wording is found in the conflict file.]
!corrigendum 5.5.2(0)
Insert new clause:
[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" <ROFL!>

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".

****************************************************************

Questions? Ask the ACAA Technical Agent