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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Extending a third party tagged type while adding finalization Date: Fri, 8 Dec 2017 18:17:20 -0600 Organization: JSA Research & Innovation Message-ID: References: <4db43571-7f86-4e73-8849-c41160927703@googlegroups.com> <6496a10f-c97e-4e42-b295-2478ad464b2f@googlegroups.com> <6106dfe6-c614-4fc1-aace-74bf8d7435e3@googlegroups.com> <24767ee5-cda8-45e4-98d1-7da44757bd40@googlegroups.com> <037e7f02-9149-4648-b7c5-91f67c1c1961@googlegroups.com> Injection-Date: Sat, 9 Dec 2017 00:17:21 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="31190"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:49428 Date: 2017-12-08T18:17:20-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:p0dm3g$dgf$1@gioia.aioe.org... > On 08/12/2017 00:22, Randy Brukardt wrote: ... >> There can be other operations that are built >> on the set of operations, but they are definitely not part of the ADT. > > How can you tell? To me it is meaningless without considering the > semantics. If an operation implements some part of the ADT semantics, it > is of ADT. If it does not then it is an implementation detail and must be > hidden unless it belongs to some other ADT. This seems to suggest that you are trying to make everything into an ADT (as opposed to just a DT - "Data Type"). The crux of the matter here is the "abstract" part - there has to be a consise description of the purpose of the type and operations. Something spread all over the place can't have the abstract semantics necessary for an ADT. ... >>> 1. Private type means that parts of the representation is hidden. Your >>> definition is not related to that. >> >> All of the operations need to be explicit and a closed set. >> If the representation is not hidden, that cannot be true. > > The representation can exactly match the type semantics, e.g. an > enumeration type or discrete type: > > type Alarm is (Low, High); > type Room_Temperature is digits ... range 0.0..30.0; > > [If you consider these representations.] > > There is nothing wrong in exposing representations telling the problem > space's truths. Only implementation artifacts need to be hidden and only > when they expose things breaking the abstraction. The problem here is that you are exposing a lot more than just the fact that Room_Temperature is a numeric value with a range. You're also exposing the representation details (Size, Alignment, the fact this is a float rather than fixed representation), and a large bunch of inherent operations which may or may not make sense for this data type (what does "**" mean for a temperature, for instance?). The number of ADTs where exactly what Ada gives you is correct sensible is essentially zero. Thus, the statement that the type of an ADT has to be private. The types you have above cannot be ADTs (at least not in Ada), since they expose many irrelevant implementation details. I use a lot of such types, but I wouldn't care to try to give any sort of abstract definition for them. ... >>> 2. Primitiveness of an operation is not related either. >> >> If the type is private, the operations have to be declared there, and >> that >> makes them primitive. (No Ada ADTs outside of an Ada package.) > > You can declare non-primitive operations at same places. You are trying to > define a general concept in terms of Ada design artifacts (if not design > faults). The purpose of Ada packages was to model ADTs. A package+private type+operations=ADT is fundamental to the Ada design. In any case, if you presume as I do that the type of an ADT has to be private, you have little choice but to put the basic operations in the same package. And one should not consider operations that can be build out of the basic ones as part of the ADT, lest you harm reusability and maintainability (the only reasons for writing ADTs in the first place). >>>> If a type is not private, it cannot be an ADT, as it provides an >>>> unlimited number of other operations that are not described explicitly. >>> >>> How primitiveness changes that? I still can define new subprograms >>> taking >>> and returning values of the type regardless. >> >> If they're not part of the package, then they are operations that use the >> ADT, but are not part of the ADT. > > Now you are attempting to tie ADT with packages. Why should these be > related. Aren't types partially defined in a chain of packages and > completed in some other package ADT? No, I wouldn't say that. An ADT might be built out of some other types (including other ADTs), but pretty much only by composition. The only exception would be inheritance of operations from some parent type, and those can be thought of as being repeated (implicitly) in the definition of the new type. >> For many programs, most of the code is >> built on ADTs but are not themselves part of any ADT (because they >> require >> the services of many ADTs - which one does it belong to? Any answer is >> arbitrary). > > No you want to deny ADT reuse or abstraction. A matrix element can be ADT > but the matrix and vector cannot because it uses element ADT? ?? Composition of ADTs makes perfect sense. That doesn't make the vector operations (having element parameters) part of the element ADT (its clearly part of the vector ADT). But most mixed operations don't clearly belong to one ADT or another. They're just things that need to be done. (Indeed, the entire top-level of a program tends to be in this category - it's not going to be reusable since it is tied to a particular task, it's not going to be commonly used since it is the high-level operations for a particular task - and as such, spending much time at all figuring out what abstract entities are involved is wasted. Just get the job done, spend the effort on the building block parts of the system that will be reused.) ... >> Based on this definition, almost nothing should be an ADT, because very >> little can be described only by its semantics. Humm, that's actually a >> true >> statement; probably we are feeling different parts of the elephant and >> describing it very differently. > > Probably. Things you cannot associate with the semantics are > implementation aspects. They can be any so long the semantics maintained. I suspect you are trying to describe much more of a system by its semantics than I do. As I previously noted, it just isn't worth the effort to figure about abstract meanings for things unless they are either very common in a system or likely candidates for reuse. There's a lot of stuff that has to be done in programs that defies logical explanation, but that's irrelevant -- one just has to implement something that passes the test, no one cares if it is elegant. (It took me a long time to come to grips with this truth.) So it's important to realize that one is a lot more productive if one picks their spots where to be elegant (where to use an ADT, in this discussion). ... > You are right that the interface of an ADT must be clear. This is why > Ada has means for information hiding. Any aspects irrelevant to the > semantics of the ADT must be hidden. It is not always possible in Ada and > I always wished more help to that, especially interfaces for and of > arrays, record, access, tasks, protected object types, constructors, user > aggregates etc. I suspect that programmers always will want more help at that. Ada 2020 is likely to give you some additional help (but not in the generalized manner that you are always touting). We're working on user aggregates and literals for private types, and probably some other things I've forgotten. Randy.