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: g2news2.google.com!news4.google.com!feeder.news-service.com!eweka.nl!hq-usenetpeers.eweka.nl!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Sun, 07 Dec 2008 16:38:46 +0100 From: Georg Bauhaus Reply-To: rm.tsoh-bauhaus@maps.futureapps.de User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: MI is sloppy References: <493ab375$0$31872$9b4e6d93@newsspool3.arcor-online.net> <10wio06m42skd$.11t1wjs299ul4$.dlg@40tude.net> In-Reply-To: <10wio06m42skd$.11t1wjs299ul4$.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <493bee06$0$31346$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 07 Dec 2008 16:38:46 CET NNTP-Posting-Host: fdb2c3c2.newsspool4.arcor-online.net X-Trace: DXC=nHD;X_GWcQe@Ro\fff[ X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:3888 Date: 2008-12-07T16:38:46+01:00 List-Id: 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... ;-> > 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. Even leaving out issues with -> LOOK RIGHT -> written on some roads in some countries. (IOW, the assumptions that a road being a road here it must be a same-use road there, too, may be misleading.) >> Can't we just make Inout_File some composition and hide the details >> completely, behind a suitable collection of primitive operations? > > A hidden composition does not exist for observers <=> it does not exist at > all. Exactly. More on its faint existence below. > The > diamond diagram is a counterexample: > [...] > type Inout_File is .. ? > > No way. Here is one. I'm not speaking in favor single parenthood but against an attempt to inflate the existing type system as is, I guess. Maybe to the contrary. Assume type Animal = ({+Fish, +Bird, +Snail, +Quadruped, +Insect, ...} =: V, {Move, Eat, Multiply, ...} =: Op ); (Sorry if this seems improper biological classification. A type Animal = ({+Bones, +Skin, +Veins, +Intestines, ...} =: V, {Move, Eat, Multiply, ...} =: Op)) or otherwise more fine grained will be less handy for my purpose.) The + designates the bit patterns that represent the respective animals in the program's state space. Then I use specialization, type Dog is new Animal ...; as if I had written type Dog = ({+Quadruped | ...} =: V, {Move, Eat, Multiply, ...} =: Op); (Leaving out the overridings for the moment.) So Dog's value set will actually be a proper subset of the value set of Animal, with a suitable restriction. Employing MI, I could have type Dog_Fish = ({+Quadruped, +Fish | ...} =: V, {Move, Eat, Multiply, ...} =: Op); 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. A Fish will suffocate where a Dog Moves, a Dog will drown where Fish Eats. (Not implying that contradiction is a necessity of MI. A freaky Asian restaurant will offer a dog and fish for dinner, no problem.) 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?) 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? Are the problems relative to the combination, or are they relative to the observer/user/programmer's intentions? IOW, is this specific example actually a good example of MI or is it just an example of something (Inout_File) that we only think we know to be multiply polymorphic? 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? 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? Can T's author provide for in views and out views, again adding nodes to the inheritance graph? 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 "inheritance", to stress the difference, is a collection of tags, at best. (It is not necessarily MD, I think, rather a "multitag" mapped to the set of primitives of T.) For Inout_File, then, you have only interface requirements. An concrete type will *require* an implementation of a properly crafted set of operations of type Inout_File = (_, Op(In_File) or Op(Out_File)). Properly crafted means that the programmer takes care of issues that do never occur with In_File or Out_File alone. The issue emerging in the product type will likely affect the way that Read or Write can be performed. Duplexing, say. So these operations would have to be overridden anyway. You'd effectively be writing for a new type. 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) 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. -- Georg Bauhaus Y A Time Drain http://www.9toX.de