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,39579ad87542da0e X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 X-Received: by 10.224.88.200 with SMTP id b8mr34955620qam.8.1367842231236; Mon, 06 May 2013 05:10:31 -0700 (PDT) Path: y6ni14420qax.0!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!news.glorb.com!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 14:11:32 +0200 Organization: cbb software GmbH Message-ID: <17ceq51ydy3s0.s94miqqzbg5w.dlg@40tude.net> References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Date: 2013-05-06T14:11:32+02:00 List-Id: On Mon, 06 May 2013 12:55:31 +0200, Yannick Duchêne (Hibou57) wrote: > Le Mon, 06 May 2013 12:18:40 +0200, Dmitry A. Kazakov > a écrit: > >> On Mon, 06 May 2013 12:00:25 +0200, Yannick Duchêne (Hibou57) wrote: >> >>> Or else, may be it suggest types should rather be tagged by default >> >> No. All untagged types should have untagged classes. > > If I understand you correctly, that was something very close I was > thinking about when reading the RM page about user‑defined indexing (and > other tagged‑types only allowed features), I just though “so, why not > considerer untagged types has a fixed static class (*) and on that basis, > naturally allow the same definitions to be applied to untagged types”. > While some features are defined for tagged types only, no requirement is > never made any where for these same tagged types to be derived, so it > could be defined for untagged types as well (or else I am missing > something). Perhaps that this feature (static classes) existed since Ada 83. http://www.adahome.com/rm95/rm9x-N.html Pos. 6. What is needed is dynamic classes for untagged types with articulated interfaces. Operations on a class-wide object will dispatch as usual. Ada 83 classes were implicit. The interface was not stated but described informally in the RM. That is because there is no language means to describe such interfaces (integers, reals, arrays, records, tasks etc). Tagged types were first in Ada to have explicit used-defined interfaces. > (*) class with no dispatching or deterministic dispatching, so would be > untagged, indeed, if I understand you correctly. > > 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. Little changed since then. You will find a lot of people praising "orthogonality" of tagged types, which was nothing but a language design fault, an ugly compromise. > That's not > that I'm against tagged types, just that I would prefer to not force the > use of tagged types (hence the “lack of orthogonality”); tagged are > sometime nice, sometime not nice, that depends on the area, on the > requirements, …, both should be treated equally with regards to primitives > and constructs, except for any primitives and construct which would > *requires* there are indeed tagged (non‑deterministic members and > sub‑programs) classes (like any operations which involves classes, as an > immediate example). 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. It should work exactly same with "untagged" classes. BTW, there will be no problem to have mixed cases. There seems to be nothing wrong in inheriting from both a tagged and an untagged interfaces. There result would be tagged, of course. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de