Re: U : Unbounded_String := "bla bla bla"; (was: Is the Writing...)

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On 10 Oct 2003 13:58:29 -0700, aek@vib.usr.pu.ru (Alexander
Kopilovitch) wrote:

>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...

Why should we compare? And frankly, there is no language with a good
ADT, presently.

>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. I see where it comes from. C++ classes
are usually compared with Ada packages. Why should we slavish follow
C++, which has *incurable* problems with ADT?

>> >> 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,

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.

>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. 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.

>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? -:)

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.
For this reason "subtype" cannot become a language term. 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 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.

It is quite simple. 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.

That's it.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de