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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: How come Ada isn't more popular? References: <1169531612.200010.153120@38g2000cwa.googlegroups.com> <1mahvxskejxe1$.tx7bjdqyo2oj$.dlg@40tude.net> <2tfy9vgph3.fsf@hod.lan.m-e-leypold.de> <1g7m33bys8v4p.6p9cpsh3k031$.dlg@40tude.net> <14hm72xd3b0bq$.axktv523vay8$.dlg@40tude.net> <4zwt33xm4b.fsf@hod.lan.m-e-leypold.de> <1j7neot6h1udi$.14vp2aos6z9l8.dlg@40tude.net> <1170347180.14376.104.camel@localhost.localdomain> <1nxunq6pci4r1$.1nnigcjicppwy.dlg@40tude.net> <11g5kv93fm3ua.1p5hykfsdax5l$.dlg@40tude.net> From: Markus E Leypold Organization: N/A Date: Sat, 03 Feb 2007 15:16:21 +0100 Message-ID: <14ejp7cone.fsf@hod.lan.m-e-leypold.de> User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:N9Dj4dj/SnwFeWAgAyT0wMKQfuM= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.212.247 X-Trace: news.arcor-ip.de 1170511883 88.72.212.247 (3 Feb 2007 15:11:23 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news1.google.com!news4.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!news.tele.dk!feed118.news.tele.dk!news.tele.dk!small.news.tele.dk!news-fra1.dfn.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:8915 Date: 2007-02-03T15:16:21+01:00 List-Id: "Dmitry A. Kazakov" writes: > On Fri, 02 Feb 2007 13:34:21 +0100, Markus E Leypold wrote: > >> "Dmitry A. Kazakov" writes: >> >>> Sure you can: >>> >>> type Additive is abstract; -- Should be enough for an interface >>> function "+" (A, B : Additive) return Additive is abstract; >>> >>> Here I am not sure about "increment" variable, because it is not >>> initialized. Anyway: >>> >>> function Increment return Additive is abstract; >>> -- Better be getter/setter pair. Unfortunately Ada does not have >>> -- "abstract variable interface" it should have >>> >>> function Inc (Arg : Additive'Class) return Additive'Class is >>> begin >>> return Increment + Arg; >>> end Inc; >>> >>> There is a very simple rule for all this: >>> >>> 1. Formal generic subroutines -> abstract primitive operations >>> 2. Subroutines in the body -> class-wide operations. >> >> So you derive from Additive to get a specific implementation? >> >> Like >> >> type Vector is Additive with ...; >> type CountVal is Additive with ...; >> >> Right? But then, you should note that with >> >> C: Countval; >> >> Inc(C). >> >> returns an 'Additive', not a 'CountVal'. > > No, it does Additive'Class! Thus, no problem. I've been expressing myself sloppily. It should return a CountVal, not an Additive'Class. CountVal(s) could not be added to Vectors -- there is a difference. > (note that the goal was polymorphic Inc, if you wanted it covariant that No. The goal was to have mechanism to write the algorithms once and being able to pull various actual operators/procedures from that without replicating the specification of the algorithm. I really think you're mixing something up here, but the example is not really useful to demonstrate the advantages of generics. Let me suggest 1 other example for the usefulness of generics and than 1 example where generics (Ada-style) help, but parametric polymorphism (what I have been talking about as parametrized types) would actually bring an advantage. Example 1: An abstract vector space is defined as a sets of vectors u,v,w,... and scalars a,b,c, ... with a number of operations: - scalars are a field, i.e. have additions an multiplication with certain properties - there is amultiplication between scalars and vectors: a*v - there is an addition between vectors. A normalized vector space introduces the idea of distance between verctors, Again certain laws apply. For the programmer: There is a dist-functions which takes 2 vectors a parameters. You can do a really huge amount of mathematics with this axioms. Examples of vector spaces with thos properties would be certain subsets of functions, finite vectors (i.e. arrays of N components), polynomes, etc. One application would be, given a function on the vector space f : V -> Real_Numbers to find minima of this function. There is an algorithm that is not very efficient but works in a vast number of cases without having to use specific knowledge of the underlying vector space. With Ada generics I'd define the vector space interface a generic and instantiate accordingly. The algorithm to fin minima would be implemented as generic and take a vector space package as generic parameter. Example 2 Write a quicksort algorithm on arrays which can be reused for arrays of almost arbitrary elements, if a suitable order relationship is defined. Note that I might want to sort _the same_ elements with different orders (like insurance number or alphabetically ...). > would automatically exclude polymorphism) > >> That is one problem. The >> other is of course that Increment is not initialized. This is exactly >> what generics are here to solve. > > As it was in Georg's example. Yes. But Georg used generics, so it worked. You said, you don't want generics, but it doesn't work. I fail to see, how George has to use select an example that makes your misguided hypothesis -- that generics are not neeeded -- hold up. Quite the opposite. > But with inheritance covariant Increment > would be required to be overridden (praised be Ada). So an initialization > will be enforced anyway. I don't see how. And what is more: With generics I could istantiate a Large_Step (increment by 100) and a Small_Step (increment by 1) function from the generic. That would not work at all with your method. If suspect you're missing the respective application areas of generics vs. inheritanc+overriding. As an software engineer I'd always prefer generics, since they avoid polymorphism where no polymorphism is required or intended. That is good, since it's nearer to the contract. Regards -- Markus