Re: Ada Distilled by Richard Riehle

["Dan'l Miller" <optikos@verizon.net>]

On Friday, July 27, 2018 at 3:07:21 PM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-07-27 20:52, Dan'l Miller wrote:
> > On Friday, July 27, 2018 at 12:11:31 PM UTC-5, Shark8 wrote:
> >> On Friday, July 27, 2018 at 8:30:36 AM UTC-6, rabbi...@gmail.com wrote:
> >>>> That's what I think; but there's also a surprising amount of it that's about sets, too.
> >>>
> >>> In what way? Off hand I can't see where I've used that at all.
> >>
> >> The most obvious one is the TYPE / SUBTYPE relationship:
> >> TYPE: A set of values, and a set of operations on those values.
> >> SUBTYPE: A TYPE with an additional set of restrictions constraining the values.
> >>
> >> Another was the CASE statement and its required coverage.
> >>
> >> A third [IIRC; this may have been my own realization] had to do with visibility being treated as a set
> >> [of sets]: if a name exists uniquely, then that is legal; if there is no existence at all, it's a case of
> >> either mistaking the name or forgetting to WITH the dependency; if there are multiple existences
> >> then the compiler must error-out and demand a qualified name, renaming, or other such resolution.
> >> {Extendible to overloading; which is a set of names distinguished usually by parameter- or return
> >> types.}
> >>
> >>>
> >>>> Would you happen to recall what Richard said that so convinced you about it?
> >>>
> >>> I don't recall his exact words. To me the fact that I can uniquely tailor each type to the real world.
> > 
> > Yes, implicitly those are sets (and sets of sets), especially to complier writers, but in Ada today ••how
> > is that different•• than, say, C++ or OCaml or Rust or any other language that purports itself to be
> > strongly-typed, especially to the app-domain programmer or library programmer.
> 
> Ada has subtypes (domain set constraining/specialization) other 
> languages have only extension (domain set product). Constraining allows 
> a lot of things beyond ranged numbers to be expressed in a regular and 
> natural way, e.g. unconstrained arrays, variants etc.
> 
> And in Ada we can use combinations of both, which is quite powerful, 
> almost everybody uses discriminants with tagged types without even 
> thinking about it.

I wasn't asking what are Ada's type differences vis a vis the other languages.  I was asking:  how does Ada have a focus on •sets of• types that other languages lack or don't bring forth as fully as a focus on •sets•.

> > Conversely, if Ada'Succ or Ada++ or AdaNG or hypoAda/Ada/hyperAda (or whatever its name would be)
> > would embrace overt set operations* over the sets of types, subtypes, class-trees, and so forth at
> > either compile-time or run-time or both, now that might lead to an interesting destination of
> > super-dooper Ada++ doing something special & useful that no** other language can do, including
> > current Ada.
> 
> Ada already has sets of types in two forms: generics and classes. For 
> users the second form is limited to only tagged types. That should be 
> fixed, no doubt.
> 
> > A smidgeon in this direction historically, Z.200 CHILL as Ada's almost-unreadable Steelman-esque
> > alter ego had set & power-set as 1st-class citizens along with array and had grant/revoke***
> > operations on sets of types as something set-semantically richer than Ada's mere public and private.
> > 
> > * e.g.,  element of, set-difference, union/conjunction, intersection/disjunction, not/converse, power-set
> 
> Set-theoretic operations have only limited interest. There is a 
> contradiction to type definition as a set of values and operations. 
> Since operations cannot be deduced from the domain set, there is little 
> merit in producing the domain set of a specific form.
> 
> It is easier for the compiler and the programmer to let the programmer 
> define the domain set using a few built-in constructs, like arrays, 
> records, tagged closure, which provide straightforward and efficient 
> implementation. After all it will be in the end hidden in the private 
> part of the ADT, following the programing practice of information hiding.
> 
> > *** not that that was necessarily a good thing per se, just a strawman/starting-point demonstration of
> > what is conceivable with compile-time set operations on types, subtypes, class-trees, etc.
> 
> Types algebra, yes. Most important type operations Ada lacks are:
> 
> - ad-hoc supertypes,

{Objective-C, C#, Swift}-esque ad-hoc supertype extension mechanism seems like it would violate some fundamental principles/axioms of Ada:  guaranteeing at compile-time that a dispatch to an object will succeed.  (Although by my observation of error messages that I receive, it seems as though C#'s Roslyn compiler can look widely across multiple compilation units to assure this guarantee at least under certain conditions, but I am unsure that Roslyn covers •all• the cases/loopholes.)

> - interface inheritance,

What portion of interface inheritance is Ada lacking?  Are you saying (again) that interface inheritance requires tagged records and that you would like interface inheritance for untagged types?

> - full MI,

Ewwwwwww.  No, as shown by the debacle of C++'s multiple inheritance, full multiple inheritance is not useful beyond mixin-an-interface inheritance which Ada already has for tagged records.

> - full MD

Full multiple dispatch was added experimentally back in the day for Ada as part of the Ada9X exploratory contracts, by SRI iIRC.