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,84f721148b16bb3 X-Google-Thread: fac41,b501d1c53ed57c5b,start X-Google-Attributes: gid103376,gidfac41,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!news.germany.com!newsfeed.straub-nv.de!noris.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Thu, 05 Jun 2008 21:40:55 +0200 From: Georg Bauhaus Reply-To: rm.tsoh-bauhaus@maps.futureapps.de User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.eiffel Subject: Re: The A-Z of Programming Languages: Ada, interview with S. Tucker Taft References: <910cef1d-2ba2-4130-8f1f-2ce192756cfa@d77g2000hsb.googlegroups.com> <4846a33e$0$27453$9b4e6d93@newsspool4.arcor-online.net> <2f24888f-35fc-4b7d-b188-d121d950063d@b1g2000hsg.googlegroups.com> <4847f10d$0$6543$9b4e6d93@newsspool3.arcor-online.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <48484147$0$7547$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 05 Jun 2008 21:40:55 CEST NNTP-Posting-Host: 97420945.newsspool1.arcor-online.net X-Trace: DXC=;[G\d:TZLhe_0Po7BmQ3]lic==]BZ:afn4Fo<]lROoRa<`=YMgDjhgbLkNlRKiA?OhPCY\c7>ejVhgQAcZLo\Hdo_O Jean-Pierre Rosen wrote: > Georg Bauhaus a �crit : >> IIUC what Taft says in the interview, Ichbiah didn't like the >> _way_ OOP was to be implemented. OTOH he had been working on a >> Simula compiler at INRIA. So maybe OOP alone was not the elephant. >> > Certainly. Actually, Ichbiah was well aware of the benefits of OOP, and > actually that's why he insisted for having derived types in Ada83, > against the opinion of the rest of his team. Thanks. As promised, here is what Meyer quotes from Ichbiah's resignation letter: "A massive increase in complexity will result from 9X adding one or more additional possibilities where Ada now offers two. For example, 9X adds: [...] access parameters, to IN, OUT, and IN OUT; tagged types, to normal types; dispatched subprogram calls, to normal subprogram calls; use type clause, to use package clauses; ... With 9X, the number of interactions to consider is close to 60,000 since we have 3 or more possibilities in each case (that is, 3^10)." (OOSC2, �33.7, p.1095) The comment "adds: tagged types, to normal types" is particularly interesting, I think, because it touches on a consequence of this distinction: sloppy versus exact base type systems: Eiffel tries to have basically one kind of type definition, namely the class---even though "expanded class" "adds one or more additional possibilities", if I may aim Ichbiah's comment at Eiffel. Compiler magic is/was used for types such as INTEGER or REAL. Some operations of INTEGER are "require"-predicates used for testing whether or not an integer value fits a subsets of INTEGER, e.g. 8-bit integers. Ada, as mentioned by Ichbiah, has "normal" types for defining integers, reals, etc., and tagged types for defining polymorphic types. You want integers between 0 and 10_000 only? Define a corresponding normal type, or do "normal" derivation from another integer type adding the needed constraint. (Part of the language since Ada 83 as pointed out by J.-P. Rosen above.) What I find so interesting is that these ways to define basic types might show that there are undeniable reasons to require two type definition mechanisms. (I guess this is not news to people who worked on either Ada 9X or Eiffel, but it appears to be news to a new audience tackling the base type system. And the presence of one or the other always affects programs.) Do the Eiffel base types work well? Do they match the "normal" integer types of Ada in practice? Using cut&paste polymorphism and renaming one can change INTEGER to a different INTEGER with more specific require predicates, predicates even more powerful than Ada's range constraints(*). Still, people coming to Eiffel have more than once asked for more programmer control of basic Eiffel types such as INTEGER and FLOAT. Messing with base types, renaming and cluster management do not look like the best solution. So maybe there is good reason to have both normal types, and tagged types, even if this complicates the language? _____ (*) Some hard work has been done with the goal of enhancing Ada's type constraints in the sense of DbC. It has been published as AIs and elsewhere. X'Post -- Georg Bauhaus