Re: Class-wide types algebra

[rieachus@comcast.net]

On Monday, September 12, 2016 at 5:39:32 PM UTC-4, Dmitry A. Kazakov wrote:
> On 2016-09-12 23:12, rieachus@comcast.net wrote:
> 
> I am not sure what you mean. Ada's "in" has the mathematical meaning 
> "member of" (∈). If you meant "subset of"/"subsumption" (⊆) then it is 
> just same as
> 
>     T in R'Class

I was using "in" as syntactic sugar, extending R'Class without creating a new (named) subclass.  As unrelated to the Boolean version as to its use in subprogram declarations.

> > Why the second case? The real issue seems to be visibility. You have
> > an interface, and a type which could/should be a member, but the
> > declaration is more deeply nested. (There would still need to be some
> > magic so that the lifetime of T'Class is the same as R'Class. Or better,
> > just a rule that requires them to have the same lifetime from other rules.)
> 
> I don't see any problems with that. All types in question are statically 
> known. Type tests are expressible already
> 
>     X in (T'Class and R'Class)  <=>  (X in T'Class) and (X in R'Class)
> 
> The real problem is declarations not tests.

IMHO the biggest problem in Ada is the namespace pollution of types.  Dotted notation is acceptable when package names hide each other, but I hate having to write "subtype Foo is Bar.Foo."  Subprograms can be overloaded, but adding a (new) type name during maintenance can break something down a chain of derivations.

A long time ago, Lori Clarke and others wrote: "Nesting in Ada is for the Birds."  http://dl.acm.org/citation.cfm?id=948651 There are a few missing pieces when you go to mix class wide types into Ada.  I've started numbering the often never mentioned again types that appear when using interfaces to do mix-ins.