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 Path: border1.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Seeking for papers about tagged types vs access to subprograms Date: Mon, 6 May 2013 16:16:02 +0200 Organization: cbb software GmbH Message-ID: <1vrhb7oc4qbob$.q02vuouyovp5$.dlg@40tude.net> References: <17ceq51ydy3s0.s94miqqzbg5w.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Original-Bytes: 3565 Xref: number.nntp.dca.giganews.com comp.lang.ada:181449 Date: 2013-05-06T16:16:02+02:00 List-Id: On Mon, 06 May 2013 15:16:21 +0200, Yannick Duchêne (Hibou57) wrote: > Le Mon, 06 May 2013 14:11:32 +0200, Dmitry A. Kazakov > a écrit: >>> I feel the status distinction between tagged and untagged types as an >>> issue in some ways, this breaks something in the big picture, and break >>> Ada, the language, in two too much distinct and foreign parts. >> >> Yes it does. That was a flaw of Ada 95 design. I guess it was the maximum >> of what Tucker Taft could press through fierce opposition. > > Fierce opposition from who? For what reasons? What did Tucker initially > wanted? I wasn't there. >> There is nothing non-deterministic in tagged types. All calls with >> specific objects are statically resolved. Dynamic are only dispatching >> calls involving class-wide objects. > > Theoretically. In practice, GNAT don't agree (*). It has a pragma for > that, `pragma Restrictions (No_Dispatching_Calls)` which should even > enforce it in a whole application, but seems even with this active, it > still requires the whole part of the runtime dedicated to it, a part which > depends on this part, I suppose it would be difficult to implement this so that the code used to maintain dispatching tables and tags could be removed. It may require two versions of the compiler. Furthermore there are packages defining operations on tags which could require some of the stuff. Why do you bother? Especially, because dispatching calls are deterministic and could be done time bounded, unless you manipulate tags. (Not everything in people write in their guidelines for RT projects makes sense.) > However and in the large, I > agree with you and share the same understanding of the topic, at least > theoretically. There are far reaching consequences of having classes for all types. > (*) Don't know if SPARK agree and believe something can be proved about > such a system, it's a too long time I didn't use it. A quick search on the > web seems to show it may be possible. Yes, through global analysis. Though I would prefer a much finer approach when time constraints could be imposed on the interface rather than checked afterwards. What is in the interface cannot be decided before you have interfaces properly articulated. Thus type system overhaul is the first step to make. Without doing that you get only mess. See Ada 2012 dynamic pre-/postconditions as an example. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de