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

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

On Wed,  8 Oct 2003 23:12:35 +0400 (MSD), "Alexandre E. Kopilovitch"
<aek@vib.usr.pu.ru> wrote:

>Dmitry A. Kazakov wrote:
>
>> >  type Y is private envelope of X;
>> >
>> [...]
>>
>> Looks similar to my proposal for defining subtypes.
>
>I think yes, there is much in common, although there is also a difference:
>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.

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

>> It should be something like:
>>
>> type Y is private subtype X;
>>
>> Note that for the sake of genericity one need more than two
>> conversions. There should be four:
>>
>> X_From_Y, X_To_Y - this pair is used when an Y gets substituted for X,
>> i.e. when Y *inherits* a subprogram from X. One of these conversions
>> might be absent. Then Y becomes an in-subtype or an out-subtype of X:
>>
>> type Y is private in subtype X;
>>   -- Only in-subroutines are inherited. So only X_From_Y has to be
>>   -- defined
>>
>> Y_From_X, Y_To_X - this pair is used when X gets substituted for Y,
>> i.e. when Y exports something to X. This is a way to create 
>> supertypes.
>>
>> type Y is private in out supertype X:
>
>Well, it seems that your proposal uses basic diagrams while mine is restricted
>to isomorphic representations.

You are poisoned by LSP! (:-))

>> If all four conversions are present both types become fully
>> interchangeable, which is actually required in case String vs.
>> Unbounded_String.
>
>I don't see why two conversions (which provide isomorhic representation)
>aren't enough for String vs. Unbounded_String... if we have no intention to
>extend current functionality (except of making implicit conversions possible).

Because, I do not want isomorhic representations. 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.

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