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-10 13:58:29 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: aek@vib.usr.pu.ru (Alexander Kopilovitch) Newsgroups: comp.lang.ada Subject: Re: U : Unbounded_String := "bla bla bla"; (was: Is the Writing...) Date: 10 Oct 2003 13:58:29 -0700 Organization: http://groups.google.com Message-ID: References: <86u4ov4ojmuugvp2p4qsg725ah45p01c2h@4ax.com> <8i6aov011dia1vsiv3ihsh1kvmul5nlesk@4ax.com> NNTP-Posting-Host: 213.221.48.59 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1065819509 5294 127.0.0.1 (10 Oct 2003 20:58:29 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 10 Oct 2003 20:58:29 +0000 (UTC) Xref: archiver1.google.com comp.lang.ada:649 Date: 2003-10-10T13:58:29-07:00 List-Id: Dmitry A. Kazakov wrote: > >your proposal is significantly broader; it is certainly heavier as it pertains > >to possible consequences, and I have no immediate opinion whether it will be > >easier to find sound applications for that your proposal than for mine, more > >narrow one. > > Yes. 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... 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. > >> Why to call "envelope" something which is a subtype? (:-)) > > > >"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, 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. For a theoretical one I'd prefer (well, actually I long dreamed for that) that somebody will give a grant to Grothendieck (while he is alive) for exploring and reviewing structuring systems in programming in general and object systems in particular; most probably this way we'll acquire superior theoretical foundation, which we will be unable to reach otherwise for decade or or two. For a practical one, you (yes, you, as you expressly wish this construct -:) should provide Ada-specific example where this construct is natural for some problem space. You may notice that this my "requirement" somehow differs from the standard one -:) -- this is needed not for justification of efforts, but rather for a guidance in dealings with subtleties and consequences. > >Well, it seems that your proposal uses basic diagrams while mine is restricted > >to isomorphic representations. > > You are poisoned by LSP! (:-)) I can't deny it because I don't know what it means (I'm not a native English speaker who can easily differentiate POW = Prisoner of War from POW = Prince of Wales). So, what is that LSP? Late Super Power? Large Sentence Propagator? Lightweight Streamline Processing? -:) > I want a > fundamentally new, universal concept of subtyping which would cover > all known cases. > > For instance, it would work for tagged extensible types. If the > subtype just extends the base (contains it representation), then the > pair of conversions Base_*_Derived are just view conversions, because > Derived has an instance of Base. Another pair Derived_*_Base should > create and destroy a completely new Derived object. Presently the > second pair is outlawed in Ada, so we have only view conversions from > Derived to Base (forth and back). This limits use of tagged types. For > example, they cannot be directly used to implement multiple > representations, I mean the cases when Derived has to be an equivalent > [sub- and supertype] of Base, and not just a subtype. Well, I must confess I can't understand all this - probably because I never learned Computer Science -;) . I have learned some mathematics, including functional analysis and algebraic topology - so I can understand abstract algebraic and categorical models; I have some experience with real programming applications - so I can understand structuring of a problem space; but I become essentially lost in a "professional" mixture of Computer Science and Software Engineering - I simply cannot catch true meaning of words. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia