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

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

Dmitry A. Kazakov wrote:

> >I disagree with use of sub- prefix for something that is not a proper restriction
> >(in some respect) relative to the base.
>
> There are clear restrictions:
>
> A, a subtype of B (A <: B), means that A is substitutable for B =
> there is a conversion forth and back to B.
>
> B, a supertype of A (B :> A) means A <: B.

I meant that "subtype" should be in some sense smaller then the base type,
or at least should be somehow subordinate to the base type. But for the
relations you presented it is unclear which kind of subordination they imply.
Can you put it all in more rigorous terms?

> >Well, you can change landscape completely without touching usable lands -
> >just breaking the borders between them.
>
> That is what I want.

So, as you want to change landscape completely (or at least very substantially),
you should have some general image of that new landscape beforehand, right?
And you should have some grounds to assert that new landscape is viable,
that is, sufficiently stable and usable. Or you just want to make changes
and then see consequences as they emerge?

> > 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?
>
> Yes, and more than that. Probably one need an experimental version of
> the language.

This made me pretty sceptical. Well, just one more experimental language,
created just for illustration of some concept(s) or construct(s) (in the best
case) or for pleasing author's ambitions (in the worst case). Nobody knows
and nobody cares. Well, if you know more substantial purpose for that language
then tell it - it is too hard to guess what it may be.

> However the idea is pretty simple. Actually it is just separating
> implementation and interface. If you follow it consequently, you will
> define a type is a set of public operations applied to the values of
> private representation. If then you will try to define what a derived
> type could be, the only way you could do it is in terms of
> conversions. If you do that you will see, that in fact all known cases
> of derived types fall under this model.

Simple idea do not imply simple consequences. And the consequences, and methods
to deal with them is a bitter field to be explored.

Well, I vaguely remember that there were metaclasses... quite popular thing
N years ago. I think that there were something in common with that you propose.
Perhaps even in more developed form. But I may be mistaken here, I remember
nothing concrete about those metaclasses... except of that a flavor of them
was present, for example, in IBM's SOM.

> >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".
>
> No. I want to evolve Ada's ADT. I want *less* "flexibility", less
> built-in types, less generics, less access discriminants, less
> pointers, less kludges of any kind.
>
> It is a pitty that each new change adds new pragmas, attributes and
> other hard-wired things to Ada. It is the time to make the language
> simplier.

But complexity of a language must somehow correspond to complexity of the
informational body for which it is used. And typical Ada applications so far
are relatively close to real world, which certainly has complex informational
body, as we view it scientifically/technically.

Therefore you can't just make the language simplier - before that you should
provide some new view on the real world, which decrease complexity of
informational body. Well, like Copernicus did. -:)

> >> 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.
>
> This is again a usual misconception. People with a mathematical
> background just cannot imagine what LSP goes after.

Well, I must tell you that there are people that have more than one background,
and mathematics can be just one of them -:)  Yes, this phenomen is not common,
but nevertheless it happens sometimes.

> It is not about
> rectangles, it is about types, i.e. about sets of rectangles in
> general. Now consider this statement:
>
> for all X, Y there is a <rectangle> with height=X and width=Y
> 
> For a square to be a LSP-subtype of rectangle, means that the above
> will remain true if you change <rectange> to <square>!

Incorrect, though. Your example statement is not about all rectangles...
it isn't sufficient just use the words "for all" somewhere in the statement -;)

> >> >> 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?
>
> The idea is too simple to call it a concept.

But it may be just starting, undeveloped idea; and it may appear that it has
unavoidable consequences, which lead to substantial extension etc., etc.

> As for implementations, I know no language, which allows this.

Isn't it strange? Simple idea, allegely useful, but still unused after 50+
years of programming.



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