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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e1bb9627c57b7d5b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-14 01:09:35 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: U : Unbounded_String := "bla bla bla"; (was: Is the Writing...) Date: Tue, 14 Oct 2003 10:09:57 +0200 Message-ID: <8e8novk48g4g7ucvtmfh83jbbt57jg809m@4ax.com> References: <29mkov4si58udaojtipbepgptk16518g5h@4ax.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1066118973 22658675 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:804 Date: 2003-10-14T10:09:57+02:00 List-Id: On Tue, 14 Oct 2003 01:43:46 +0400 (MSD), "Alexandre E. Kopilovitch" wrote: >Dmitry A. Kazakov wrote: > >> >> ... I wish Ada's ADT be fully reviewed. Yet, I believe, that it can >> >> remain compatibile to Ada 83. >> > >> >Well, I don't think that Ada 95 ADT is inferior relative to ADT system in any >> >other programming language... >> >> Why should we compare? > >Well, what should we do otherwise? -;) Yes, we can compare not against other >programming languages, but against perceived needs or against sound theoretical >models (which one you prefer?), but we still should compare. > >> And frankly, there is no language with a good ADT, presently. > >Well, I don't know ALL languages... for example (as it pertains to ADT) I >don't know Eiffel, I don't know recent Norwegian branch (Abel, Beta), I don't >know ML descendants (which some algebraically-oriented teams are developing), >to name a few. I recall that ADT in Limbo language were somehow original, >at least in that they were called exactly ADT, and in fact there was 3-level >object system, in which ADT was 2nd level. Well, probably, there is a ready to use fusion reactor hidden somewhere. Who knows... (:-)) >> >But I'd like to note here that in Ada 95 you >> >should consider ADT alongside with packages, because structuring in Ada 95 >> >relies upon both these system in their interdependent combination. >> >> It is a common misconception. > >Really? I am slightly surprised - not only with your opinion that this is a >misconception, but also with the claim that it is "common". Packages are pretty orthogonal to types. And it is good so. BTW all cases in Ada where it is not so (like requirements to do something at the library level) are rather boring. >> I see where it comes from. C++ classes >> are usually compared with Ada packages. > >I did not imply that, and I really don't think so. In Ada, hierarchies of >packages are clearly separated from hierarchies of types, while in C++ we have >single kind of hierarchy - of classes (which has multiple inheritance in some >compensation). Yes, this is why Ada packages have little to do with ADT. >> >> >"subtype" in Ada implies a possibility of some kind of restriction imposed on >> >> >the base type, while the word "envelope" implies some kind of extension (of >> >> >functionality or applicability). You see, for a language terms I strongly >> >> >prefer application/user view to a compilation theory's view, even for advanced >> >> >entities/constructions. >> >> >> >> This is the crucial point. Subtype should imply nothing, but >> >> substitutability, in the sense that you can pass objects of the >> >> subtype where the base type is expected. The rest is implementation >> >> details. A subtype can be made either by a specialization (like >> >> constraining) or a generalization (like type extension) or by >> >> providing a completely new implementation (interface inheritance from >> >> a non-abstract type). But all these ways are no more than >> >> implementation details which could be moved to the private part. >> > >> >I think that then it should not be called "subtype", there should be another, >> >> Well, there is "subclass", but "class" is already in use, Ada's class >> is a type closure. But I see nothing wrong in calling it sub- and >> supertype. > >I disagree with use of sub- prefix for something that is not a proper restriction >(in some respect) relative to the base. There are clear restrictions: A, a subtype of B (A <: B), means that A is substitutable for B = there is a conversion forth and back to B. B, a supertype of A (B :> A) means A <: B. > I always found usage of the word >"subtype" in Ada very appropriate; at the same time I found informal use of >"subclass" term in C++ and some other languages quite corresponding to their >eclectic and over-pragmatic character. Frankly, I see no difference. Ada 83 had "type", so its constrained descendant became "subtype". C++ had "class", so "subclass" was invented. >> >more precise name. Further, such a construct probably will have far fetched >> >consequences (being combined with other, already existing features). I don't >> >think that such a big leap should be made into the dark, and without much >> >appeal, simply following a vague analogy. Some good justification must be >> >provided in advance, as we aren't in C++. That justification may be either >> >theoretical or practical. >> >> I think that this construct will have very little influence on the >> existing ones. > >Well, you can change landscape completely without touching usable lands - >just breaking the borders between them. That is what I want. >> However it will allow to express the existing ones in >> new terms. For instance, both Ada's "tagged types" and "subtypes" >> could be then viewed as abbreviations. > >Don't you think that this quite serious claim? I do. > Don't you think that such >"groundbreaking" views deserve complete and consistent presentation - not >within a newsgroup dialogue, but in the form of an article? Yes, and more than that. Probably one need an experimental version of the language. However the idea is pretty simple. Actually it is just separating implementation and interface. If you follow it consequently, you will define a type is a set of public operations applied to the values of private representation. If then you will try to define what a derived type could be, the only way you could do it is in terms of conversions. If you do that you will see, that in fact all known cases of derived types fall under this model. >Whether these your >views are right or wrong, it is practically impossible to analyze them (or >to decide that there is nothing to analyze -;) , until they are presented >in the form of a set of refutable statements. See above. It is not just one article, but several. Do you have a grant for me? (:-)) >For example, I can't conclude from your present words whether you are trying >to add some dose of SmallTalk-like flexibility to Ada's "type machine". No. I want to evolve Ada's ADT. I want *less* "flexibility", less built-in types, less generics, less access discriminants, less pointers, less kludges of any kind. It is a pitty that each new change adds new pragmas, attributes and other hard-wired things to Ada. It is the time to make the language simplier. >> LSP = Liskov Substitutability Principle. The idea is that a derived >> thing is a subtype (LSP-subtype) if and only if all its instances are >> in all contexts substitutable where the base is expected. Then under >> substitutability LSP the program semantics (behaviour) is understood. > >Well, let it be LSP, although I find this not much different from the notion >of "particular case" in mathematics. > >> For this reason "subtype" cannot become a language term. > >You mean that it is meta-language term, right? Yes. It becomes OOA/D term and disappears in the swamp. >> So people >> have invented "subclass", which is a language term then. And of >> course, "subclass" /= "subtype". Then it is obvious, that an absolute >> LSP requires isomorphic value sets, which makes it useless. >> Mathematically LSP is sort of: Y is a subtype of X if any statement >> including X remains true if Y is substituted for X (and under all >> quantifiers). So square is not a LSP-subtype of rectangle; constant >> Integer is not of Integer; String (1..80) is not of String etc. > >I can't agree with all that: not "any statement", far from that, but only >statements expressed in terms of operations defined for that type, and moreover, >only statements that are valid for all values of the type (vs. statements that >are valid for some individual values only). So square IS a particular case of >rectangle: all statements that are valid for ALL rectangles are automatically >valid for all squares. This is again a usual misconception. People with a mathematical background just cannot imagine what LSP goes after. It is not about rectangles, it is about types, i.e. about sets of rectangles in general. Now consider this statement: for all X, Y there is a with height=X and width=Y For a square to be a LSP-subtype of rectangle, means that the above will remain true if you change to ! >> >> I want a >> >> fundamentally new, universal concept of subtyping which would cover >> >> all known cases. > >Do you mean that this concept is completely original, or you have some >references to somehow similar concepts? The idea is too simple to call it a concept. As for implementations, I know no language, which allows this. >> > When you write: >> > >> > type Y is new X with ...; >> > >> > then each Y contains an instance of X. This is programming by >> > extension. Because each Y has X, to substitute an Y for X you need not >> > create any new object if: >> > >> > 1. X is passed by reference >> > 2. X in Y is aliased >> > >> > So to call Foo (Object : in out X); on some Y you can calculate a >> > reference to X in Y (X_From_Y conversion); call Foo; drop the >> > reference (X_To_Y conversion). So this pair is just view conversions. >> > [ See now, why in Ada tagged types are by-reference ones? ] >> > >> > Now, imagine, that you have defined Bar (Object : in out Y); and want >> > to export it to X (which is illegal in Ada), so that Bar could be >> > called with an X. For this you have to provide true conversions. >> > Y_From_X and Y_To_X which would create a new object Y: >> > >> > You create a new Y from X; you pass it to Bar; you store X-part of Y >> > back into the argument. > >Well, I think I understand now. Perhaps some languages will accept this construct, >but as for Ada, I'm pretty sure that Ada will reject it (Ada does not like >tools/features that are both powerful and without a bunch of restraints). >Ada may accept it informally, as a design pattern, but will never accept it >as an intrinsic feature, which (after all) is permitted to act implicitly. Do you mean tagged types (:-)), or supertypes or something else? --- Regards, Dmitry Kazakov www.dmitry-kazakov.de