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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,5d4ade2fd8fd67c6 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder.news-service.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Legit Warnings or not Date: Tue, 2 Aug 2011 12:01:53 +0200 Organization: cbb software GmbH Message-ID: <110nibt4tsn7q.162t6eli286tt.dlg@40tude.net> References: <531193e0-3305-4292-9ed8-0176226c1d00@x12g2000yql.googlegroups.com> <1rx6dwrxmc81p.eazb4fjqztox$.dlg@40tude.net> <1hi6gva8jhf7o.tq1yp29jn3qu.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: NoaUN4bWUeg0ayP2hXFU5g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: g2news1.google.com comp.lang.ada:20445 Date: 2011-08-02T12:01:53+02:00 List-Id: On Mon, 1 Aug 2011 17:12:23 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:gfjkj1eowd8x.1q86rn9zvkfd.dlg@40tude.net... >> On Fri, 29 Jul 2011 19:17:25 -0500, Randy Brukardt wrote: > ... >>> Interfaces require multiple inheritance. Multiple inheritance is >>> unimplementable (at least efficiently). It's completely unimplementable >>> in >>> Janus/Ada which is based on fixed, statically sized objects and >>> components. >>> (Generic code sharing is a lot easier.) >> >> 1. Ada 2005 has interfaces. > > Ada 2005 interfaces are unimplementable in Janus/Ada. (That's a tiny bit > strong, there is a way to implement them, but no one would ever want to use > the result.) It is sad. Ada needs a compiler diversity. There is a huge niche which GNAT didn't gnaw - the microcontrollers. A reasonably priced Ada compiler could be a hit there, because the alternatives are either C (unbearable developing costs) or Java (catastrophic performance). The customer mentality is: buy the processor first, search for a compiler afterwards. >> 2. The case I gave is fully static, without classes (of arrays or records). >> This is not a dynamic interface it is just same thing as "type X is >> private;" Private and limited private were interfaces already in Ada 83. > > If you have a generic sharing compiler, there is nothing that is not a > dynamic interface. *All* properties of a type are dynamic. > The presence or absence of array manipulations is pretty much the only > exception, which makes it reasonably efficient. Changing that would make a > decent implementation impossible. As you know, I don't value generics in whatever implementation. >> 3. It was you arguing for objects which size were indeterminable and >> components dynamically allocated. And now? > > No, I was arguing for "non-contiguous objects". I *am* guilty of mixing up > Janus/Ada terminology with Ada's, however; for Janus/Ada, all top-level > objects are contiguous and statically allocated. They may, however, have > implicitly managed sub-parts that are neither. That's why Janus/Ada > considers the array descriptor (which is static sized) the object and not > the data. That's not quite the meaning of "object" in Ada, and presumably > you read it to mean something closer to that definition - sorry. > > So far as I can tell, it is impossible to come up with anything reasonable > which would allow multiple inheritance in this scheme, because the compiler > has to know in advance how many parts there are and where to find them -- > and that is not possible with multiple inheritance. The language needs a scheme to support "an instance of the type S viewed as the type T". > > 4. Why a built-in implementation of array of S'Class (what you seemed to be >> arguing for) should be easier/more efficient/more compatible to Ada than an >> implementation trough Ada.Container only publicly visible as an array? > > There is no new magic needed to allow S'Class as a component type -- only > the removal of a single legality rule (much like Ada 2005 eliminated the > library-level requirement on derived tagged types). That is because your compiler already implements this magic. Other compilers may have problems with that. And for a programmer the problem is to have control over the constraints (when the tag can be changed and when not) and over copying (when dynamic components get copied, when shared). You will need a lot of new keywords and syntax constructs to specify all possible and needed combinations of these, plus terrible rules about how these constraints are propagated upon composition and inheritance. What happens in generics etc. To me it is just an overkill. Ada already suffers a plethora of unorganized special cases of types instead of a clean and *small* type system. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de