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!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!news.etla.org!feeder.erje.net!eu.feeder.erje.net!eweka.nl!lightspeed.eweka.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Fri, 02 Aug 2013 11:50:15 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Generics vs. O-O? References: <6238c325-79c5-4537-ba55-2800110dc6df@googlegroups.com> <1wugpqyea6s39$.e2e8eshup5wn$.dlg@40tude.net> <51fadf40$0$6557$9b4e6d93@newsspool4.arcor-online.net> <15qso6tlt3uf1.h45wqc019b00$.dlg@40tude.net> In-Reply-To: <15qso6tlt3uf1.h45wqc019b00$.dlg@40tude.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <51fb80d8$0$6561$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 02 Aug 2013 11:50:17 CEST NNTP-Posting-Host: b1791394.newsspool4.arcor-online.net X-Trace: DXC=fhMS3?cU:`FI7\_^6>c20J4IUKJLh>_cHTX3jMbTJ2^=JJPNJ X-Complaints-To: usenet-abuse@arcor.de Xref: news.eternal-september.org comp.lang.ada:16653 Date: 2013-08-02T11:50:17+02:00 List-Id: On 02.08.13 10:11, Dmitry A. Kazakov wrote: >> package N is >> >> type T is range -1 .. 1; >> >> generic >> type S is new T; >> package Pointless is end; >> >> type Q is range -1 .. 1; >> >> package Exmpl is new Pointless (Q); -- error >> >> end N; >> >> Equivalent structure of scalar types T and Q won't do. > > You cannot specify what belongs to a formal class it is decided by the > structure of given type. Formal classes exist only when meta-talking about Ada templates. Or about whether or not generics can be used as if some extraneous formalism influences the choice of one or other Ada mechanism. It might be helpful to name this context, explicitly, as the discussion confuses concepts that are defined outside Ada and concepts from "inside" Ada, such as the structure of a given type, I assume. Translating to Ada, and with reference to generic formal types, I can indicate a category of types. There are no formal classes. > Regarding your example the class you used is one created outside the > generics. It is good that Ada 95 allowed this, but it does not change the > nature of the language of formal generic specifications. View 1: The nature of formal generic specifications is not one whose instantiations will produce typed instances, because the latter is not defined, or intended, in Ada. In a different theory, things will appear differently. View 2: Not all generic formals allow indicating the "formal classes" you find important WRT "belonging", but don't care to say what a "formal class" is, or what "belonging" might mean WRT outreach and"verifiable substitutability". > Here substitutability encompasses all parameters generics take, not just > types. E.g. > > generic > with function Foo (X : Integer) return Real; > package Bar is ... > > You cannot verify if Baz > > function Baz (X : Integer) return Real; > > were substitutable in Bar for Foo. I cannot verify substitutability of unspecified nature anywhere in Ada except maybe within unspecified confines of some verifiable part of programs, and limiting "verifiable substitution", rather tautologically, to what happens to be so testable within a given choice of language features as to show whether or not something satisfies the definition of exactly that "verifiable substitution" the speaker has in mind. It will be helpful to pinpoint this idea more precisely, or verifiably, if you will. For example, a formal type may be one that has T as an ancestor, T giving enough of verifiable information such that each instance specifies sets of values that objects will assume as a consequence of certain operations. > Parametric polymorphism of generics is way too loose, because it basically > untyped. Worse is that it is any useful so long it remains untyped. Once > you try to put types on it, it will be as "inconvenient" as any type > system, while keeping all disadvantages of being strictly compile-time. If something *is* known at compile time, but *could* be different for a different compilation, then static choice of shape (μορφή, morphi) facilitated by generic instantiation turns out to be one-time dispatching without the need for anything at run-time. Polymorphic things are not needed for monomorphic programs. Choosing generics can remove the disadvantages of the unneeded "much" (πολύς, polys). Simple generics can reduce complexity by removing the overhead of polymorphic dummy parameters of a single, specific type. Choice of a single type may in cases be achieved by editing a single definition in some top level package, too, for example when the type is a scalar type. But this does not always work well. For example, if you'd want a callback to be passed somewhere. Then, dismissing generics might entail the introduction of one level of indirection (subprogram pointer), or some dummy parameter (polymorphic, type based choice). These artifacts serve no purpose other than sustaining geniophobia. ;-) ;-) And they might be inefficient in inner loops.