From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:42c3:: with SMTP id i186mr6698397itb.2.1546792411358; Sun, 06 Jan 2019 08:33:31 -0800 (PST) X-Received: by 2002:a9d:bd5:: with SMTP id 79mr1185116oth.7.1546792411102; Sun, 06 Jan 2019 08:33:31 -0800 (PST) Newsgroups: comp.lang.ada Date: Sun, 6 Jan 2019 08:33:30 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=85.168.19.89; posting-account=O_NgcgoAAABs6pgCjroQBmOBL5ZZGPUc NNTP-Posting-Host: 85.168.19.89 References: <2a6929c5-72fa-4d84-953a-44ea4597ab38@googlegroups.com> <9e6b4219-d6ba-4c89-814d-5ea6e48ed8ea@googlegroups.com> <9179093f-4765-47a9-9dc6-147c9d7d6c56@googlegroups.com> <809a445d-cf73-4525-a732-67dbf24e8394@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <1e4f3e15-afe4-4ca3-b039-11c6918f9977@googlegroups.com> Subject: Re: class wide iterable (and indexable) From: George Shapovalov Injection-Date: Sun, 06 Jan 2019 16:33:31 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!feed.ac-versailles.fr!proxad.net!feeder1-2.proxad.net!209.85.166.216.MISMATCH!q69no561919itb.0!news-out.google.com!v71ni542ita.0!nntp.google.com!q69no561918itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Xref: reader01.eternal-september.org comp.lang.ada:55225 Date: 2019-01-06T08:33:30-08:00 List-Id: 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 membe= rs treated in a special way, so I grouped them together with 2. But that sp= ecial treatment can quickly become "sufficiently special" to warrant a sepa= rate category. Especially when we start considering all special-cased deriv= ed tagged/untagged types overriding or hiding discriminants, so that it tur= ns "simple parameters of the type" into a mixture of data and code (at leas= t according to some discussions of gnat internals I read at some point).. =20 > There is no difference between operations and record members except than= =20 > language design faults/artifacts. Publicly visible record members should= =20 > have been overridable as other operations are.=20 >From purely logical point of view, perhaps. But once we start considering i= mplementation details, there is a very clear distinction between code and d= ata. Code, you only (usually) have one copy that can be called many times a= s needed. Data entries can and are duplicated. (At least according to class= ical 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 go= t 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 gra= nd-grand-child decides to cast some ancestor access to reach out to now hid= den 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 dyna= mically 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 m= ake this distinction (between code and data, even logically) if we want to = have a practically sensible compiler, code for which we can any hope oursel= ves to comprehend.. And now, of course, we come back to generics, or rather their "abuse, beyon= d initial intention". Having powerful and type-checked generics is a big pl= us of Ada, except when we use that mechanism to blend the boundaries betwee= n "code" and "data" by creating millions of specialized code copies thus en= ding up with "callable data". You refer to just such a situation being comm= on in your projects and I feel your pain. This is also exactly the reason w= hy I try to avoid such scenario as much as possible - going as far as break= ing compiler while (ab)using interfaces (compared to what is expected in Ad= a, although it is a normal use case in some other languages) but to avoid o= verusing generics beyond their "original intention". And so, we have come a full circle in this discussion, leading again to thi= s: > Note also that any so small problem becomes a nightmare when generics=20 > come into play. A honest macro does not have any of this because it=20 > simply expands whatever garbage into the source.=20 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 conseq= uences, because ones logical intention rarely maps exactly onto lexical rep= resentation in a code snippet.. Well, what can be said about this? Complex systems are complex. And "for ev= ery 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 decrea= sing desire to abuse than a strong but convoluted attempt to prohibit unint= ended 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 fea= tures :). [*] Except that may be we can, in the form of "true AI". If such thing is i= ndeed possible[**], it may also be that it can generate "magic" (from our p= oint of view, because we will not understand them) solutions that appear si= mple in action. Only that would make us also irrelevant and it would be mor= e likely to concentrate itself on its own problems, rather than ours. Unles= s 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 philosophica= l topic :) [**] And the premise of its possibility is based on observation that system= s that we perceive as alive and intelligent (e.g., ourselves) are essential= ly 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 ov= er 70 years. But the underlying systems, even "simple" eucariotic cells, ar= e indeed very complex, easily beyond the level of our "biggest systems" - a= s a practicing Biology/Biophysics Prof. involved in both experiments and si= mulations I can attest to that first hand. As well as to a funny observatio= n that vast majority of "proper biologists" are already hopelessly lost in = anything beyond their very specific and small project :).=20 But I digress, this went completely off the rails at this point, so I bett= er stop here.. George