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

[aek@vib.usr.pu.ru (Alexander Kopilovitch)]

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