Re: Ada Distilled by Richard Riehle

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

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.

> 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,
- interface inheritance,
- full MI,
- full MD

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de