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

["Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru>]

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.

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

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

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

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

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

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

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

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

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

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




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia