Re: class wide iterable (and indexable)

[George Shapovalov <gshapovalov@gmail.com>]

On Sunday, January 6, 2019 at 3:13:45 PM UTC+1, Dmitry A. Kazakov wrote:
> 3. Constraints. Interfaces cannot have discriminants.
Well, discriminants (at their basis) are essentially glorified record members treated in a special way, so I grouped them together with 2. But that special treatment can quickly become "sufficiently special" to warrant a separate category. Especially when we start considering all special-cased derived tagged/untagged types overriding or hiding discriminants, so that it turns "simple parameters of the type" into a mixture of data and code (at least according to some discussions of gnat internals I read at some point)..

 
> There is no difference between operations and record members except than 
> language design faults/artifacts. Publicly visible record members should 
> have been overridable as other operations are. 
From purely logical point of view, perhaps. But once we start considering implementation details, there is a very clear distinction between code and data. Code, you only (usually) have one copy that can be called many times as needed. Data entries can and are duplicated. (At least according to classical paradigm, which is no longer true of course, but see just below).

Overriding method (from this point of view) is trivial - so what that we got some extra block of code which is called perhaps once? But what do we do with overridden record entry? Do we eliminate it? But then what if some grand-grand-child decides to cast some ancestor access to reach out to now hidden entry? Do we keep them around? What, in all millions or billions copies of our records in the running system? Do we make a monstrous compiler that would require a cluster of Blue Genes to figure out the specifics and only keep data records individually as needed? But then, what if this is a dynamically running (indeed large) system only parts of which can be "rebooted" but it cannot be taken down as a whole? So I'd say it does make sense to make this distinction (between code and data, even logically) if we want to have a practically sensible compiler, code for which we can any hope ourselves to comprehend..

And now, of course, we come back to generics, or rather their "abuse, beyond initial intention". Having powerful and type-checked generics is a big plus of Ada, except when we use that mechanism to blend the boundaries between "code" and "data" by creating millions of specialized code copies thus ending up with "callable data". You refer to just such a situation being common in your projects and I feel your pain. This is also exactly the reason why I try to avoid such scenario as much as possible - going as far as breaking compiler while (ab)using interfaces (compared to what is expected in Ada, although it is a normal use case in some other languages) but to avoid overusing generics beyond their "original intention".
And so, we have come a full circle in this discussion, leading again to this:

> Note also that any so small problem becomes a nightmare when generics 
> come into play. A honest macro does not have any of this because it 
> simply expands whatever garbage into the source. 
Indeed, exactly in view of all above (both sets of quotes). But it (honest macro) is also more limited and often leads to completely unintended consequences, because ones logical intention rarely maps exactly onto lexical representation in a code snippet..

Well, what can be said about this? Complex systems are complex. And "for every problem there exists a solution that is clear, simple and wrong". I don't think we can have a rainbow unicorn that would make everything magically simple[*]. But we can, at least, strive to keep our tools sane/verifiable in order to guard our own sanity :). Even a very simplistic tool can always be abused. Therefore I think it it more important to provide a clear base/most common case use pattern. This will provide more safeguarding by decreasing desire to abuse than a strong but convoluted attempt to prohibit unintended use. People will always find a way.
That was an attempt to get back to the subject of multiple inheritance and unintended consequences of prohibiting useful applications of its basic features :).

[*] Except that may be we can, in the form of "true AI". If such thing is indeed possible[**], it may also be that it can generate "magic" (from our point of view, because we will not understand them) solutions that appear simple in action. Only that would make us also irrelevant and it would be more likely to concentrate itself on its own problems, rather than ours. Unless we involve ourselves deeply in its upbringing to the point of blending in and becoming a part of it.. But that is an entirely different philosophical topic :)

[**] And the premise of its possibility is based on observation that systems that we perceive as alive and intelligent (e.g., ourselves) are essentially complex biophysical systems based around a fixed set of laws. So far the latest set of laws, as we could formulate them, stood up unviolated for over 70 years. But the underlying systems, even "simple" eucariotic cells, are indeed very complex, easily beyond the level of our "biggest systems" - as a practicing Biology/Biophysics Prof. involved in both experiments and simulations I can attest to that first hand. As well as to a funny observation that vast majority of "proper biologists" are already hopelessly lost in anything beyond their very specific and small project :). 

But I digress, this went completely off the rails at this point, so  I better stop here..

George