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: 103376,73f81e5f5d6ee80f X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news.buerger.net!uucp.gnuu.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: MI is sloppy Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <493ab375$0$31872$9b4e6d93@newsspool3.arcor-online.net> <10wio06m42skd$.11t1wjs299ul4$.dlg@40tude.net> <493bee06$0$31346$9b4e6d93@newsspool4.arcor-online.net> Date: Sun, 7 Dec 2008 21:04:33 +0100 Message-ID: <3h37pw0xni15$.68gx7sal2rmg.dlg@40tude.net> NNTP-Posting-Date: 07 Dec 2008 21:04:34 CET NNTP-Posting-Host: 9d115ff2.newsspool3.arcor-online.net X-Trace: DXC=>lYE[[1_@mYYI9]OHn9o5^McF=Q^Z^V3X4Fo<]lROoRQ^YC2XCjHcbYa_SBiAJnM8VDNcfSJ;bb[UIRnRBaCd On Sun, 07 Dec 2008 16:38:46 +0100, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: > >> Go outside and look at the left side of >> the roadway. Cross it to the right side and then turn around 180 degrees. >> Study it. Can you note any difference? There is no one! > > Yes, there is a difference, the cars now have transparent glass > above the bumber where they had colorfol arrangements of mostly > red before... ;-> You forgot to turn around! >> A big advantage, >> you know. You don't need another car, another driving license etc in order >> to be able to drive back home. In SW we call it reuse. MI is nothing but >> reuse. > > Reuse isn't enough justification, I think. No it does. As an example consider the languages with large libraries. Whatever rubbish they might be, they beat Ada by margin, because of reuse the library code. > The key issue here is not that this is the wrong choice of > parent types. The issue is that it is a wrong choice of parent > types *because* Quadrupeds and Fish can have different habits, > they can have contradictory operations; maybe some bits of > tissue will cause compatibility problems, too. As any type deviation would. There is no such thing as LSP-subtype. Forget it. There is no way to preserve all properties of a type while changing anything there. Be it a constraint, an extension, inheritance or whatever. > So, Dog_Fish may not be a proper combination of two types. Is > Inout_File a proper combination of types? (Is it like Cat_Fish?) Types are not combined and inheritance is not a combination. It is a contract which can be implemented by a combination, or by something else. > As Martin Krischik observes, an In_File could be a stream. An > Out_File could be a stream, too. They just flow in opposite > directions. Which problems can we expect to occur with > Inout_File and how are they solved in the type system using MI? It is a question about the semantics. As such it is illegal. The language and its type system don't know the semantics. It is up to you to use the type algebra in order to implement the semantics you have in mind. MI is merely an algebraic operation on types. No more, no less. It is wrong even to imagine asking questions about whether, say, addition is appropriate. It has no sense without saying what are you going to add to what. MI is in exactly the same position. > The database illustrates what I mean by a solution necessary > for Inout_File to be practical: Behind the scenes, there are > locks. Actually, there is transaction control. So there is > more than just inheriting the operations of In_File and > Out_File. Preliminary conclusion: "in" and "out" need more > mechanism than simple (or simplistic?) MI can offer. Can the > necessary mechanism be built into MI? With the programmer > controlling the MI hooks, maybe? Concurrency primitives are non-composable, so your question is illegal with regard to any algebraic operation on types, not only MI. Example: array of objects. Do they lock all, individually, by groups when you access the elements of the array? > Taking MI to the level of Ada's in mode and out mode as mentioned > by Dmitry, what MI mechanism is practical enough so that we could > define > > type T is new A and B and in and out; > > Or partially in and partially out? How does T adapt to the > desired parameter modes of new subprograms? Yes. The compiler has right to do it for certain types. > Can T's author > provide for in views and out views, again adding nodes > to the inheritance graph? Nice to have. > My current favorite among type fantasies is to root out all > inheritance of data and implementations (not Ada, I guess). > Then as expected, > > (a) establish a named type T that has the same interface as one > or more other types: T := (_, Op(T1) or Op(T2) ...) > > (b) allow definition of primitive operations of this T: > Op(T) := Op(T1 x T2 ...) This looks like an ad-hoc supertype. It is not a replacement to subtypes, which are more structured, controllable and provide better performance. Yes ad-hoc supertypes are sometimes useful. See below. > In order to switch from one interface to another, view > conversion might be nice, but defining conversion functions > would be more powerful: > > (c) allow defining projection functions from T -> Ti > (nothing new here) Yes, I proposed something like this. It is a unified model of type derivation. When you define a new type related to an old one, you can say that it imports operations (=inherit) and/or export operations. Relatively to the given operation it is a subtype when it imports or a supertype when it exports, or both (an equivalent type). > So for Inout_Files, a duplexed, transactional, intermittend > mode of reading and writing can act as if it were a simple > streaming operation. But it seems unlikely that the added > machinery is always what the client wants: reusing Inout_File > may be prohibitively slow. Therefore, so a conversion function > could lock the Inout_File object, delegate to an Out_File > object (which is quicker) and be back in business. Note that it is no matter how you get the diamond top-down or bottom-up. The order of derivation is unimportant. Important is the relation sub- or supertype = import or export. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de