comp.lang.ada
 help / color / mirror / Atom feed
* Ada Distilled by Richard Riehle
@ 2018-07-15 18:09 rabbibotton
  2018-07-16  1:02 ` Shark8
  0 siblings, 1 reply; 29+ messages in thread
From: rabbibotton @ 2018-07-15 18:09 UTC (permalink / raw)


Any one know if Ada Distilled by Richard Riehle for 2012 is available?

David Botton

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-15 18:09 Ada Distilled by Richard Riehle rabbibotton
@ 2018-07-16  1:02 ` Shark8
  2018-07-21  6:07   ` Randy Brukardt
  0 siblings, 1 reply; 29+ messages in thread
From: Shark8 @ 2018-07-16  1:02 UTC (permalink / raw)


On Sunday, July 15, 2018 at 12:09:57 PM UTC-6, rabbi...@gmail.com wrote:
> Any one know if Ada Distilled by Richard Riehle for 2012 is available?
> 
> David Botton

I haven't heard about it in some time. (I think I have a copy of the previous version somewhere though; but that's no help if it's specifically Ada 2012 you're looking for.)

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-16  1:02 ` Shark8
@ 2018-07-21  6:07   ` Randy Brukardt
  2018-07-26  0:42     ` rabbibotton
  0 siblings, 1 reply; 29+ messages in thread
From: Randy Brukardt @ 2018-07-21  6:07 UTC (permalink / raw)


"Shark8" <onewingedshark@gmail.com> wrote in message 
news:72ccb7fa-a9cb-42e6-8c29-3c06da281a45@googlegroups.com...
> On Sunday, July 15, 2018 at 12:09:57 PM UTC-6, rabbi...@gmail.com wrote:
>> Any one know if Ada Distilled by Richard Riehle for 2012 is available?
>>
>> David Botton
>
> I haven't heard about it in some time. (I think I have a copy of the 
> previous version somewhere though; but that's no help if it's specifically 
> Ada 2012 you're looking for.)

The Ada 2005 version is available on AdaIC.org (and probably other places). 
I haven't heard about an Ada 2012 version being available -- but I haven't 
heard from Richard in a long while, either.

                                               Randy.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-21  6:07   ` Randy Brukardt
@ 2018-07-26  0:42     ` rabbibotton
  2018-07-26 20:17       ` Shark8
  0 siblings, 1 reply; 29+ messages in thread
From: rabbibotton @ 2018-07-26  0:42 UTC (permalink / raw)


It has been on GetAdaNow.com since it started, I was really hoping for an update. It is an important work. It gets a developer into the right mindset for Ada. I met Richard many years ago and he sat me down and explained the secret of Ada, its all about types.

David Botton


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-26  0:42     ` rabbibotton
@ 2018-07-26 20:17       ` Shark8
  2018-07-26 21:10         ` Jeffrey R. Carter
  2018-07-27 14:30         ` rabbibotton
  0 siblings, 2 replies; 29+ messages in thread
From: Shark8 @ 2018-07-26 20:17 UTC (permalink / raw)


On Wednesday, July 25, 2018 at 6:43:00 PM UTC-6, rabbi...@gmail.com wrote:
> It has been on GetAdaNow.com since it started, I was really hoping for an update. It is an important work. It gets a developer into the right mindset for Ada. I met Richard many years ago and he sat me down and explained the secret of Ada, its all about types.
> 
> David Botton

That's what I think; but there's also a surprising amount of it that's about sets, too. (Someone here on comp.lang.ada made a really convincing illustration of how/where the language uses sets; I wish I could find the discussion.)

The blog-post here http://blog.kickin-the-darkness.com/2007/08/fundamental-theory-of-ada.html is one of the best things I've seen simply explaining the Ada mindset.

Would you happen to recall what Richard said that so convinced you about it?

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-26 20:17       ` Shark8
@ 2018-07-26 21:10         ` Jeffrey R. Carter
  2018-07-27  3:01           ` Paul Rubin
                             ` (2 more replies)
  2018-07-27 14:30         ` rabbibotton
  1 sibling, 3 replies; 29+ messages in thread
From: Jeffrey R. Carter @ 2018-07-26 21:10 UTC (permalink / raw)


On 07/26/2018 10:17 PM, Shark8 wrote:
> On Wednesday, July 25, 2018 at 6:43:00 PM UTC-6, rabbi...@gmail.com wrote:
>> It has been on GetAdaNow.com since it started, I was really hoping for an update. It is an important work. It gets a developer into the right mindset for Ada. I met Richard many years ago and he sat me down and explained the secret of Ada, its all about types.
>>
>> David Botton
> 
> That's what I think; but there's also a surprising amount of it that's about sets, too. (Someone here on comp.lang.ada made a really convincing illustration of how/where the language uses sets; I wish I could find the discussion.)

I thought the secret of Ada was visibility. As it says in /Ada Distilled/, "Once 
you understand visibility, nearly everything else about Ada will be clear to you."

Visibility is similar to the secret of S/W engineering: encapsulation and 
information hiding.

> The blog-post here http://blog.kickin-the-darkness.com/2007/08/fundamental-theory-of-ada.html is one of the best things I've seen simply explaining the Ada mindset.

This gives me a Server Not Found error.

-- 
Jeff Carter
"I unclog my nose towards you."
Monty Python & the Holy Grail
11

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-26 21:10         ` Jeffrey R. Carter
@ 2018-07-27  3:01           ` Paul Rubin
  2018-07-27 14:32           ` rabbibotton
  2018-07-27 17:02           ` Shark8
  2 siblings, 0 replies; 29+ messages in thread
From: Paul Rubin @ 2018-07-27  3:01 UTC (permalink / raw)


"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
>> http://blog.kickin-the-darkness.com/2007/08/fundamental-theory-of-ada.html
>> is one of the best things I've seen simply explaining the Ada mindset.
> This gives me a Server Not Found error.

Wayback has it: 

https://web.archive.org/web/20120211105920/http://blog.kickin-the-darkness.com/2007/08/fundamental-theory-of-ada.html

I remember reading it a while back and thinking it was interesting but
not amazing.  It explains that the Ada type system connects a bunch of
useful info with any variable, and that's important, but there are many
other aspects of Ada that are also important.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-26 20:17       ` Shark8
  2018-07-26 21:10         ` Jeffrey R. Carter
@ 2018-07-27 14:30         ` rabbibotton
  2018-07-27 17:11           ` Shark8
  1 sibling, 1 reply; 29+ messages in thread
From: rabbibotton @ 2018-07-27 14:30 UTC (permalink / raw)


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

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


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-26 21:10         ` Jeffrey R. Carter
  2018-07-27  3:01           ` Paul Rubin
@ 2018-07-27 14:32           ` rabbibotton
  2018-07-27 20:18             ` Paul Rubin
  2018-07-27 17:02           ` Shark8
  2 siblings, 1 reply; 29+ messages in thread
From: rabbibotton @ 2018-07-27 14:32 UTC (permalink / raw)


> I thought the secret of Ada was visibility. 

Ada has many talents, its type system is unique in modern languages.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-26 21:10         ` Jeffrey R. Carter
  2018-07-27  3:01           ` Paul Rubin
  2018-07-27 14:32           ` rabbibotton
@ 2018-07-27 17:02           ` Shark8
  2 siblings, 0 replies; 29+ messages in thread
From: Shark8 @ 2018-07-27 17:02 UTC (permalink / raw)


On Thursday, July 26, 2018 at 3:10:26 PM UTC-6, Jeffrey R. Carter wrote:
> 
> > The blog-post here http://blog.kickin-the-darkness.com/2007/08/fundamental-theory-of-ada.html is one of the best things I've seen simply explaining the Ada mindset.
> 
> This gives me a Server Not Found error.

Web archive:
https://web.archive.org/web/20170313055745/http://blog.kickin-the-darkness.com/2007/08/fundamental-theory-of-ada.html


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-27 14:30         ` rabbibotton
@ 2018-07-27 17:11           ` Shark8
  2018-07-27 18:52             ` Dan'l Miller
  0 siblings, 1 reply; 29+ messages in thread
From: Shark8 @ 2018-07-27 17:11 UTC (permalink / raw)


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.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-27 17:11           ` Shark8
@ 2018-07-27 18:52             ` Dan'l Miller
  2018-07-27 20:07               ` Dmitry A. Kazakov
  2018-07-27 20:35               ` Paul Rubin
  0 siblings, 2 replies; 29+ messages in thread
From: Dan'l Miller @ 2018-07-27 18:52 UTC (permalink / raw)


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

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

** or that only metatemplate programming in C++'s accidentally Turing-complete template engine “can” conceivably do contortedly, obliquely, and via only write-once< illegible< verbose< excessively< subtle< syntax< utilizing< deeply-nested< tree< of< special-case< specializations > > > > > > > > > > >.  (Btw, C++ MTP never reads as lucidly as that tongue-in-cheek example.)

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


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-27 18:52             ` Dan'l Miller
@ 2018-07-27 20:07               ` Dmitry A. Kazakov
  2018-07-27 20:38                 ` Dan'l Miller
                                   ` (2 more replies)
  2018-07-27 20:35               ` Paul Rubin
  1 sibling, 3 replies; 29+ messages in thread
From: Dmitry A. Kazakov @ 2018-07-27 20:07 UTC (permalink / raw)


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


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-27 14:32           ` rabbibotton
@ 2018-07-27 20:18             ` Paul Rubin
  0 siblings, 0 replies; 29+ messages in thread
From: Paul Rubin @ 2018-07-27 20:18 UTC (permalink / raw)


rabbibotton@gmail.com writes:
> Ada has many talents, its type system is unique in modern languages.

I'd be interested in a description of how it's unique.  I like that
there are integer range types, though it's very hard to check statically
that a value is guaranteed to be in the permitted range.  The other
parts of Ada's type system that I've encountered seem pretty standard,
though I know there are parts that I haven't looked at and don't
understand.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-27 18:52             ` Dan'l Miller
  2018-07-27 20:07               ` Dmitry A. Kazakov
@ 2018-07-27 20:35               ` Paul Rubin
  1 sibling, 0 replies; 29+ messages in thread
From: Paul Rubin @ 2018-07-27 20:35 UTC (permalink / raw)


"Dan'l Miller" <optikos@verizon.net> writes:
> 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.

Doing those sorts of checks at runtime is not too bad and you can
specify signatures like that for runtime checking with Ruby's contracts
gem.  You can also specify them for the Erlang Dialyzer, which does
static checks but which is intentionally unsound ("success typing").
That is necessary because of Erlang's runtime typing and the body of
existing code that relies on it.  It lets some errors through to avoid
reporting false positives.  I've used both of these and they work,
though Ruby contracts can impose a lot of runtime overhead if you use
them carelessly.  Example: if you have a function whose contract says
its input is an array of widgets, Ruby's contract checker has to scan
the array (which could have a million elements) to make sure that each
element is in fact a widget.

I think for Ada, for that level of precision and given that Ada wants to
be statically checked to the extent possible, you probably want SPARK
rather than stuff in the type system.  You really do need a theorem
prover once the types get that complicated.  But, once you're ok with
that, you can encode anything in types.  That's how Coq works, and
similarly Agda, Idris, etc.  SPARK is probably more in Ada's spirit.

Links:

Ruby contracts: https://github.com/egonSchiele/contracts.ruby
Erlang Dialyzer: http://erlang.org/doc/man/dialyzer.html
Idris example: https://www.idris-lang.org/example/


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-27 20:07               ` Dmitry A. Kazakov
@ 2018-07-27 20:38                 ` Dan'l Miller
  2018-07-27 21:32                   ` Dmitry A. Kazakov
  2018-07-27 21:34                 ` Shark8
  2018-07-28  3:52                 ` Dan'l Miller
  2 siblings, 1 reply; 29+ messages in thread
From: Dan'l Miller @ 2018-07-27 20:38 UTC (permalink / raw)


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.

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-27 20:38                 ` Dan'l Miller
@ 2018-07-27 21:32                   ` Dmitry A. Kazakov
  2018-07-28  2:41                     ` Dan'l Miller
  0 siblings, 1 reply; 29+ messages in thread
From: Dmitry A. Kazakov @ 2018-07-27 21:32 UTC (permalink / raw)


On 2018-07-27 22:38, Dan'l Miller wrote:

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

No other language has a proper type representing a closure of a class 
(the set of types rooted in a type T).

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

=> It does not have it.

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

Interface inheritance means that you inherit only the interface and 
nothing else. Inheritance from a tagged type inherits interface, 
operations and partially the representation. Inheritance per subtype 
inherits everything.

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

It is evidently useful:

    type Input_File is
       new Abstract_File with private;
    type Output_File is
       new Abstract_File with private;
    type Input_Output_File is
       new Input_File and Output_File with private;

Mix-in is incredibly dangerous as anybody who actually deployed it knows 
for sure.

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

MD is a difficult problem with regard to separate compilation. I don't 
know how to solve it in a consistent way.

But the language design goal should be that any operation declared 
publicly must have all arguments and results controlling or class-wide. 
No contravariance. No type-specific operations.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-27 20:07               ` Dmitry A. Kazakov
  2018-07-27 20:38                 ` Dan'l Miller
@ 2018-07-27 21:34                 ` Shark8
  2018-07-27 22:16                   ` Dmitry A. Kazakov
  2018-07-28  3:52                 ` Dan'l Miller
  2 siblings, 1 reply; 29+ messages in thread
From: Shark8 @ 2018-07-27 21:34 UTC (permalink / raw)


On Friday, July 27, 2018 at 2:07:21 PM UTC-6, Dmitry A. Kazakov wrote:
> 
> Types algebra, yes. Most important type operations Ada lacks are:
> 
> - ad-hoc supertypes,
> - interface inheritance,
> - full MI,
> - full MD

Ad-hoc supertypes are, I think, a mistake. The value in SUBTYPE is that it is a singular set of restrictions [possibly null] placed upon it's "supertype". What this means is that for every SUBTYPE S there's an application of 'Base to get to the first subtype (Ada "TYPE") -- This means that the relation of TYPE/SUBTYPE can be graphed as a tree; if we introduce ad-hoc supertypes, we lose this property and now have to contend with a full many-to-many possibility TYPE-network rather than TYPE-tree. And I fail to see how this would be useful in-practice. (IOW, what is the real use-case? Does that use-case justify such an increase in complexity?)

I'm in agreement with interface-inheritance, I think: IIRC, you're referring to what is essentially my idea for "abstract interfaces" whereby we could define Ada's type-system in terms of the stated hierarchy; as per this picture:  https://en.wikibooks.org/wiki/Ada_Programming/Type_System#The_Type_Hierarchy -- exposing what is already fairly explicit in the LRM. 

Multiple Inheritance -- I'm not sure this is a good idea at all. Looking at C++ programmers and their experiences it seems to be more trouble than it's actually worth. (Interfaces aren't so bad, but can still conflict; Delphi has the IMPLEMENTS keyword that can be used for both disambiguation as well as delegation.) ...Why do you think Ada (or its successor) should have full MI?

Multiple Dispatch -- This one I can see having more usability than Multiple Inheritance.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-27 21:34                 ` Shark8
@ 2018-07-27 22:16                   ` Dmitry A. Kazakov
  0 siblings, 0 replies; 29+ messages in thread
From: Dmitry A. Kazakov @ 2018-07-27 22:16 UTC (permalink / raw)


On 2018-07-27 23:34, Shark8 wrote:
> On Friday, July 27, 2018 at 2:07:21 PM UTC-6, Dmitry A. Kazakov wrote:
>>
>> Types algebra, yes. Most important type operations Ada lacks are:
>>
>> - ad-hoc supertypes,
>> - interface inheritance,
>> - full MI,
>> - full MD
> 
> Ad-hoc supertypes are, I think, a mistake. The value in SUBTYPE is that it is a singular set of restrictions [possibly null] placed upon it's "supertype". What this means is that for every SUBTYPE S there's an application of 'Base to get to the first subtype (Ada "TYPE") -- This means that the relation of TYPE/SUBTYPE can be graphed as a tree; if we introduce ad-hoc supertypes, we lose this property and now have to contend with a full many-to-many possibility TYPE-network rather than TYPE-tree.

No, we don't lose anything. It is only about the order of declarations. 
Supertype can be declared after is child:

    def A
    def B <: A

vs.

    def B
    def A :> B

The topology of type relationships is same.

> And I fail to see how this would be useful in-practice. (IOW, what is the real use-case? Does that use-case justify such an increase in complexity?)

You could inject interfaces into existing types by creating their 
adoptive parents. E.g. create a descendant of Root_Stream_Type which is 
an ad-hoc supertype of String, and here is you streaming into/from strings.

You can create classes of equivalent types, e.g. resolving messy design. 
Consider Unbounded_String and String. You create

1. a descendant of String which is an ad-hoc parent of Unbounded_String. 
Now any operation of String applies to Unbounded_String.

2. a descendant of Unbounded_String which is an ad-hoc parent of String. 
Now any operation of Unbounded_String applies to String.

It almost always a combination of a super and subtype (in non-Ada sense):

    A <: ad-hoc glue type <: B

To create a relation between two totally unrelated existing types A and B.

> I'm in agreement with interface-inheritance, I think: IIRC, you're referring to what is essentially my idea for "abstract interfaces" whereby we could define Ada's type-system in terms of the stated hierarchy; as per this picture:  https://en.wikibooks.org/wiki/Ada_Programming/Type_System#The_Type_Hierarchy -- exposing what is already fairly explicit in the LRM.

Yes, you could formally describe such hierarchies because you would not 
inherit representations and thus could bring let differently implemented 
types to participate in a class and have class-wide objects of that class.

> Multiple Inheritance -- I'm not sure this is a good idea at all. Looking at C++ programmers and their experiences it seems to be more trouble than it's actually worth. (Interfaces aren't so bad, but can still conflict; Delphi has the IMPLEMENTS keyword that can be used for both disambiguation as well as delegation.) ...Why do you think Ada (or its successor) should have full MI?

Because it desperately needed in practical work.

In my actual project it could possibly reduce the code size tenfold. 
MI's code reuse is emulated per interfaces passed as parameters to 
generics. This leads to a huge  explosion of compilation units, just 
because I cannot inherit bodies of operations from the interfaces, which 
must be interfaces and cannot be abstract types. Instead of

    type A is abstract ...
    procedure FA (X : in out A);

    type B is abstract ...
    procedure FB (X : in out B);

    type C is new A and B ...;

You must stuff "inherited" bodies into a generic to be added to whatever 
descendant type:

    type A_Interface is abstract ...
    procedure FA (X : in out A) is abstract;

    type B_Interface is abstract ...
    procedure FB (X : in out B) is abstract;

    generic
       type Base_Type is new A_Interface and B_Interface ...
    package Standing_On_The_Head is
       type C is new Base_Type with ...;
       overriding procedure FA (X : in out C);
       overriding procedure FB (X : in out C);
    end Standing_On_The_Head;

If you have several lines of inheritance this gives you a ballistic 
combinatorial explosion of generic instances.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-27 21:32                   ` Dmitry A. Kazakov
@ 2018-07-28  2:41                     ` Dan'l Miller
  2018-07-28  7:10                       ` Dmitry A. Kazakov
  0 siblings, 1 reply; 29+ messages in thread
From: Dan'l Miller @ 2018-07-28  2:41 UTC (permalink / raw)


On Friday, July 27, 2018 at 4:32:52 PM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-07-27 22:38, Dan'l Miller wrote:
> > On Friday, July 27, 2018 at 3:07:21 PM UTC-5, Dmitry A. Kazakov wrote:
> >> - full MD
> > 
> > Full multiple dispatch was added experimentally back in the day for Ada as part of the Ada9X exploratory contracts, by SRI iIRC.
> 
> MD is a difficult problem with regard to separate compilation. I don't 
> know how to solve it in a consistent way.
> 
> But the language design goal should be that any operation declared 
> publicly must have all arguments and results controlling or class-wide. 
> No contravariance. No type-specific operations.

http://www.stroustrup.com/multimethods.pdf
Above is an interesting research report (and survey of the 2007 then-state of the art) from C++world on this topic of how to efficiently implement openmultimethods.  (Ada95 fortunately chose a variant of open methods for the syntax of single-dispatch, which should extend quite nicely to openmultimethod syntax, whereas C++ with openmultimethod feature would need to graft on a foreign-language-feeling Ada95-esque syntax.)

Cutting to the chase scene:
A) they seem to drop breadcrumbs per compilation-unit that are then stitched together  in the linker to then author the (dense?) multidimensional array in one fell swoop,
instead of
B) each compilation-unit contributing its portion fully-formed in situ in the one multidimensional dispatch array.

I am not understanding how the Chinese-remaindering alternative design is better in •any• metric at all (e.g., smaller memory footprint? but why the N/A in the table in §7.2?), unless their multidimensional dispatch array was sparse (for no good reason) instead of dense.


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-27 20:07               ` Dmitry A. Kazakov
  2018-07-27 20:38                 ` Dan'l Miller
  2018-07-27 21:34                 ` Shark8
@ 2018-07-28  3:52                 ` Dan'l Miller
  2018-07-28  7:12                   ` Dmitry A. Kazakov
  2 siblings, 1 reply; 29+ messages in thread
From: Dan'l Miller @ 2018-07-28  3:52 UTC (permalink / raw)


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

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.51.200&rep=rep1&type=pdf
I disagree.  From 2 decades ago, Holzmüller & Plödereder seem to find quite a fascinating use for one set-theoretic operation in particular:  union/conjunction as the basis for openmultimethods dispatched more like PL/I generics (dispatched on subprograms by curated type) than Ada95/C++ single-dispatch OO (i.e., dispatched on types by curated subprogram).

> There is a 
> contradiction to type definition as a set of values and operations. 
> Since operations cannot be deduced

There is where you went wayward:  •introduced• overtly as per Holzmüller & Plödereder, not •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


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-28  2:41                     ` Dan'l Miller
@ 2018-07-28  7:10                       ` Dmitry A. Kazakov
  2018-07-28 15:01                         ` Dan'l Miller
  0 siblings, 1 reply; 29+ messages in thread
From: Dmitry A. Kazakov @ 2018-07-28  7:10 UTC (permalink / raw)


On 2018-07-28 04:41, Dan'l Miller wrote:
> On Friday, July 27, 2018 at 4:32:52 PM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-07-27 22:38, Dan'l Miller wrote:
>>> On Friday, July 27, 2018 at 3:07:21 PM UTC-5, Dmitry A. Kazakov wrote:
>>>> - full MD
>>>
>>> Full multiple dispatch was added experimentally back in the day for Ada as part of the Ada9X exploratory contracts, by SRI iIRC.
>>
>> MD is a difficult problem with regard to separate compilation. I don't
>> know how to solve it in a consistent way.
>>
>> But the language design goal should be that any operation declared
>> publicly must have all arguments and results controlling or class-wide.
>> No contravariance. No type-specific operations.
> 
> http://www.stroustrup.com/multimethods.pdf
> Above is an interesting research report (and survey of the 2007 then-state of the art) from C++world on this topic of how to efficiently implement openmultimethods.  (Ada95 fortunately chose a variant of open methods for the syntax of single-dispatch, which should extend quite nicely to openmultimethod syntax, whereas C++ with openmultimethod feature would need to graft on a foreign-language-feeling Ada95-esque syntax.)

Yes, Ada's OO model is the only correct one, IMO.

The concept of operations nested class type declaration is evident 
garbage in the light of MD.

> Cutting to the chase scene:
> A) they seem to drop breadcrumbs per compilation-unit that are then stitched together  in the linker to then author the (dense?) multidimensional array in one fell swoop,
> instead of
> B) each compilation-unit contributing its portion fully-formed in situ in the one multidimensional dispatch array.
> 
> I am not understanding how the Chinese-remaindering alternative design is better in •any• metric at all (e.g., smaller memory footprint? but why the N/A in the table in §7.2?), unless their multidimensional dispatch array was sparse (for no good reason) instead of dense.

Before considering aspects of linking dispatching tables, the problem to 
resolve is guaranteeing completeness of the table. Considering:

    package MD is
       type T1 is ...;
       type S1 is ...;
       procedure Doubly (X : T1; Y : S1);
    end MD;

    package P is
       type T2 is new T1;
       overriding procedure Doubly (X : T2; Y : S1);
    end P;

    package Q is
       type S2 is new S1;
       overriding procedure Doubly (X : T1; Y : S2);
    end P;

Where is

    overriding procedure Doubly (X : T2; Y : S2);

How to statically ensure its appearance, when lexically (clearly it must 
be done before linking), where (visibility issue S2 must know nothing 
about T2 and conversely)?

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-28  3:52                 ` Dan'l Miller
@ 2018-07-28  7:12                   ` Dmitry A. Kazakov
  0 siblings, 0 replies; 29+ messages in thread
From: Dmitry A. Kazakov @ 2018-07-28  7:12 UTC (permalink / raw)


On 2018-07-28 05:52, Dan'l Miller wrote:
> On Friday, July 27, 2018 at 3:07:21 PM UTC-5, Dmitry A. Kazakov wrote:

>> Set-theoretic operations have only limited interest.
> 
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.51.200&rep=rep1&type=pdf
> I disagree.  From 2 decades ago, Holzmüller & Plödereder seem to find quite a fascinating use for one set-theoretic operation in particular:  union/conjunction as the basis for openmultimethods dispatched more like PL/I generics (dispatched on subprograms by curated type) than Ada95/C++ single-dispatch OO (i.e., dispatched on types by curated subprogram).

Ad-hoc supertype would do that job. Instead of building a class by 
specifying its members:

    type T is union (T1, T2, T3);

as authors propose, we could simply declare a common ancestor:

    type Semantics_Interface is ...
    procedure Eval (X : in out Semantics_Interface) is abstract;

for all tree types.

Then for each type we create a supertype that also inherits from 
Semantics_Interface. Doing so we will be required to override Eval.

Now all three types are in the same class Semantics_Interface'Class and 
we can dispatch on Eval on class-wide instances from 
Semantics_Interface'Class.

The advantage of this approach is that it is still inheritance, nothing 
new, just Ada OO model. Another important advantage is that members of 
the ad-hoc class need not to be all known in advance. We can add members 
as needed in separate packages.

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


^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-28  7:10                       ` Dmitry A. Kazakov
@ 2018-07-28 15:01                         ` Dan'l Miller
  2018-07-28 15:41                           ` Dmitry A. Kazakov
  0 siblings, 1 reply; 29+ messages in thread
From: Dan'l Miller @ 2018-07-28 15:01 UTC (permalink / raw)


On Saturday, July 28, 2018 at 2:10:07 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-07-28 04:41, Dan'l Miller wrote:
> > On Friday, July 27, 2018 at 4:32:52 PM UTC-5, Dmitry A. Kazakov wrote:
> >> On 2018-07-27 22:38, Dan'l Miller wrote:
> >>> On Friday, July 27, 2018 at 3:07:21 PM UTC-5, Dmitry A. Kazakov wrote:
> >>>> - full MD
> >>>
> >>> Full multiple dispatch was added experimentally back in the day for Ada as part of the Ada9X exploratory contracts, by SRI iIRC.
> >>
> >> MD is a difficult problem with regard to separate compilation. I don't
> >> know how to solve it in a consistent way.
> >>
> >> But the language design goal should be that any operation declared
> >> publicly must have all arguments and results controlling or class-wide.
> >> No contravariance. No type-specific operations.
> > 
> > http://www.stroustrup.com/multimethods.pdf
> > Above is an interesting research report (and survey of the 2007 then-state of the art) from C++world on this topic of how to efficiently implement openmultimethods.  (Ada95 fortunately chose a variant of open methods for the syntax of single-dispatch, which should extend quite nicely to openmultimethod syntax, whereas C++ with openmultimethod feature would need to graft on a foreign-language-feeling Ada95-esque syntax.)
> 
> Yes, Ada's OO model is the only correct one, IMO.
> 
> The concept of operations nested class type declaration is evident 
> garbage in the light of MD.
> 
> > Cutting to the chase scene:
> > A) they seem to drop breadcrumbs per compilation-unit that are then stitched together  in the linker to then author the (dense?) multidimensional array in one fell swoop,
> > instead of
> > B) each compilation-unit contributing its portion fully-formed in situ in the one multidimensional dispatch array.
> > 
> > I am not understanding how the Chinese-remaindering alternative design is better in •any• metric at all (e.g., smaller memory footprint? but why the N/A in the table in §7.2?), unless their multidimensional dispatch array was sparse (for no good reason) instead of dense.
> 
> Before considering aspects of linking dispatching tables, the problem to 
> resolve is guaranteeing completeness of the table. Considering:
> 
>     package MD is
>        type T1 is ...;
>        type S1 is ...;
>        procedure Doubly (X : T1; Y : S1);
>     end MD;
> 
>     package P is
>        type T2 is new T1;
>        overriding procedure Doubly (X : T2; Y : S1);
>     end P;
> 
>     package Q is
>        type S2 is new S1;
>        overriding procedure Doubly (X : T1; Y : S2);
>     end P;
> 
> Where is
> 
>     overriding procedure Doubly (X : T2; Y : S2);
> 
> How to statically ensure its appearance, when lexically (clearly it must 
> be done before linking), where (visibility issue S2 must know nothing 
> about T2 and conversely)?

Don't get stuck in an Ada95 syntactic structure; think a little in PL/I or in Algol68.  You are gratuitously insisting on placing the multimethods near the Ada95-era (singly-dispatched) method syntax.  Scattering the multimethods among T1, S1, T2, and S2 is what is called •multimethods•—and what is causing your unnecessary conundrum.  Divorcing their placement so that they are no longer juxtapositioned with T1, S2, T2, and S2 is called •openmultimethods•; the movement of all the multimethods to a confederation-of-multidispatching package away from the packages that contain the singly-dispatched methods is what is meant by the “open” there.

The answer is effectively already in Holzmüller's & Plödereder's work (and crudely 5 decades ago in PL/I), although I change the /overriding/ openmultimethod syntax to better visually correspond to your example (than to Holzmüller's & Plödereder's syntax) and to call to mind the PL/I GENERIC-esqueness of it all:

package MD is
    type T1 is ...;
    type S1 is ...;
    procedure SinglyT (A: T1);  -- not participating in multimethod type-condeferation
    procedure SinglyS (A: S1);  -- not participating in multimethod type-condeferation
end MD;

package P is
    type T2 is new T1;
    overriding procedure SinglyT (A: T2);  -- not participating in multimethod type-condeferation
end P;

package Q is
    type S2 is new S1;
    overriding procedure SinglyS (Y : S2);  -- not participating in multimethod type-condeferation
end P;

-- à la a blend of GENERIC in PL/I with UNION in Algol68 with OO dispatching
package TypeConfederationForMD is
    type UT is union (T1, T2);     -- Algol68 UNION-esque
    type US is union (S1, S2);     -- Algol68 UNION-esque
    procedure Doubly (X : UT; Y : US);                    -- PL/I GENERIC-esque
    overriding procedure Doubly (X : T1; Y : S1);    -- PL/I GENERIC-esque
    overriding procedure Doubly (X : T1; Y : S2);   -- PL/I GENERIC-esque
    overriding procedure Doubly (X : T2; Y : S2);   -- PL/I GENERIC-esque
end U;

Q.E.D.

Btw, because T2 is an extended tagged T1 and because S2 is an extended tagged S1, I think an alternate syntax would be expressive and useful for this special case as well instead of the explicitly-itemized same-named variants above.  Note however that (just like in PL/I GENERIC) union can confederate any types, not merely tagged types and not merely tagged-type extensions in a 'Class tree.

    type UT is union (T1'Class);     -- a blend of Algol68 UNION and Ada95 'Class
    type US is union (S1'Class);     -- a blend of Algol68 UNION and Ada95 'Class

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-28 15:01                         ` Dan'l Miller
@ 2018-07-28 15:41                           ` Dmitry A. Kazakov
  2018-07-28 16:05                             ` Dan'l Miller
  2018-08-06 19:33                             ` Vincent
  0 siblings, 2 replies; 29+ messages in thread
From: Dmitry A. Kazakov @ 2018-07-28 15:41 UTC (permalink / raw)


On 2018-07-28 17:01, Dan'l Miller wrote:
> On Saturday, July 28, 2018 at 2:10:07 AM UTC-5, Dmitry A. Kazakov wrote:
>> On 2018-07-28 04:41, Dan'l Miller wrote:
>>> On Friday, July 27, 2018 at 4:32:52 PM UTC-5, Dmitry A. Kazakov wrote:
>>>> On 2018-07-27 22:38, Dan'l Miller wrote:
>>>>> On Friday, July 27, 2018 at 3:07:21 PM UTC-5, Dmitry A. Kazakov wrote:
>>>>>> - full MD
>>>>>
>>>>> Full multiple dispatch was added experimentally back in the day for Ada as part of the Ada9X exploratory contracts, by SRI iIRC.
>>>>
>>>> MD is a difficult problem with regard to separate compilation. I don't
>>>> know how to solve it in a consistent way.
>>>>
>>>> But the language design goal should be that any operation declared
>>>> publicly must have all arguments and results controlling or class-wide.
>>>> No contravariance. No type-specific operations.
>>>
>>> http://www.stroustrup.com/multimethods.pdf
>>> Above is an interesting research report (and survey of the 2007 then-state of the art) from C++world on this topic of how to efficiently implement openmultimethods.  (Ada95 fortunately chose a variant of open methods for the syntax of single-dispatch, which should extend quite nicely to openmultimethod syntax, whereas C++ with openmultimethod feature would need to graft on a foreign-language-feeling Ada95-esque syntax.)
>>
>> Yes, Ada's OO model is the only correct one, IMO.
>>
>> The concept of operations nested class type declaration is evident
>> garbage in the light of MD.
>>
>>> Cutting to the chase scene:
>>> A) they seem to drop breadcrumbs per compilation-unit that are then stitched together  in the linker to then author the (dense?) multidimensional array in one fell swoop,
>>> instead of
>>> B) each compilation-unit contributing its portion fully-formed in situ in the one multidimensional dispatch array.
>>>
>>> I am not understanding how the Chinese-remaindering alternative design is better in •any• metric at all (e.g., smaller memory footprint? but why the N/A in the table in §7.2?), unless their multidimensional dispatch array was sparse (for no good reason) instead of dense.
>>
>> Before considering aspects of linking dispatching tables, the problem to
>> resolve is guaranteeing completeness of the table. Considering:
>>
>>      package MD is
>>         type T1 is ...;
>>         type S1 is ...;
>>         procedure Doubly (X : T1; Y : S1);
>>      end MD;
>>
>>      package P is
>>         type T2 is new T1;
>>         overriding procedure Doubly (X : T2; Y : S1);
>>      end P;
>>
>>      package Q is
>>         type S2 is new S1;
>>         overriding procedure Doubly (X : T1; Y : S2);
>>      end P;
>>
>> Where is
>>
>>      overriding procedure Doubly (X : T2; Y : S2);
>>
>> How to statically ensure its appearance, when lexically (clearly it must
>> be done before linking), where (visibility issue S2 must know nothing
>> about T2 and conversely)?
> 
> Don't get stuck in an Ada95 syntactic structure; think a little in PL/I or in Algol68.

Two language design failures, one that reached production code, another 
that luckily never did?

> You are gratuitously insisting on placing the multimethods near the Ada95-era (singly-dispatched) method syntax.

? Ada's syntax is naturally multiply dispatching. There is no 
syntactically preferable argument or result.

> Scattering the multimethods among T1, S1, T2, and S2 is what is called •multimethods•—and what is causing your unnecessary conundrum.

Actually it is full multiple dispatch: several controlling arguments 
from different type hierarchies, e.g. Print (Surface, Text)

Mutimethod traditionally is a narrower case when all controlling 
arguments are from one hierarchy, e.g. arithmetic operations: Left + Right.

> Divorcing their placement so that they are no longer juxtapositioned with T1, S2, T2, and S2 is called •openmultimethods•; the movement of all the multimethods to a confederation-of-multidispatching package away from the packages that contain the singly-dispatched methods is what is meant by the “open” there.

Ada 95 never had methods nested in type declaration. (Ada 83 did this 
error for protected objects and tasks, but the lesson was learned)

> The answer is effectively already in Holzmüller's & Plödereder's work (and crudely 5 decades ago in PL/I), although I change the /overriding/ openmultimethod syntax to better visually correspond to your example (than to Holzmüller's & Plödereder's syntax) and to call to mind the PL/I GENERIC-esqueness of it all:
> 
> package MD is
>      type T1 is ...;
>      type S1 is ...;
>      procedure SinglyT (A: T1);  -- not participating in multimethod type-condeferation
>      procedure SinglyS (A: S1);  -- not participating in multimethod type-condeferation
> end MD;
> 
> package P is
>      type T2 is new T1;
>      overriding procedure SinglyT (A: T2);  -- not participating in multimethod type-condeferation
> end P;
> 
> package Q is
>      type S2 is new S1;
>      overriding procedure SinglyS (Y : S2);  -- not participating in multimethod type-condeferation
> end P;
> 
> -- à la a blend of GENERIC in PL/I with UNION in Algol68 with OO dispatching
> package TypeConfederationForMD is
>      type UT is union (T1, T2);     -- Algol68 UNION-esque
>      type US is union (S1, S2);     -- Algol68 UNION-esque
>      procedure Doubly (X : UT; Y : US);                    -- PL/I GENERIC-esque
>      overriding procedure Doubly (X : T1; Y : S1);    -- PL/I GENERIC-esque
>      overriding procedure Doubly (X : T1; Y : S2);   -- PL/I GENERIC-esque
>      overriding procedure Doubly (X : T2; Y : S2);   -- PL/I GENERIC-esque
> end U;
> 
> Q.E.D.

This is a non-starter because sets of types (classes) must be open. All 
real-life cases for MD are when types to be added to the existing 
classes. Late bindings support is a KO criterion.

Otherwise, if you let expansion of your sets, you will run into exactly 
same problem I described. It is *not* a syntactic problem.

> Btw, because T2 is an extended tagged T1 and because S2 is an extended tagged S1, I think an alternate syntax would be expressive and useful for this special case as well instead of the explicitly-itemized same-named variants above.  Note however that (just like in PL/I GENERIC) union can confederate any types, not merely tagged types and not merely tagged-type extensions in a 'Class tree.
> 
>      type UT is union (T1'Class);     -- a blend of Algol68 UNION and Ada95 'Class
>      type US is union (S1'Class);     -- a blend of Algol68 UNION and Ada95 'Class

That does not make sense because T1'Class is a singular type. For the 
set of types rooted in T1 there is no name in Ada, since it does not 
have types of types.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-28 15:41                           ` Dmitry A. Kazakov
@ 2018-07-28 16:05                             ` Dan'l Miller
  2018-08-06 19:33                             ` Vincent
  1 sibling, 0 replies; 29+ messages in thread
From: Dan'l Miller @ 2018-07-28 16:05 UTC (permalink / raw)


On Saturday, July 28, 2018 at 10:41:53 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2018-07-28 17:01, Dan'l Miller wrote:
> > Btw, because T2 is an extended tagged T1 and because S2 is an extended tagged S1, I think an alternate syntax would be expressive and useful for this special case as well instead of the explicitly-itemized same-named variants above.  Note however that (just like in PL/I GENERIC) union can confederate any types, not merely tagged types and not merely tagged-type extensions in a 'Class tree.
> > 
> >      type UT is union (T1'Class);     -- a blend of Algol68 UNION and Ada95 'Class
> >      type US is union (S1'Class);     -- a blend of Algol68 UNION and Ada95 'Class
> 
> That does not make sense because T1'Class is a singular type. For the 
> set of types rooted in T1 there is no name in Ada, since it does not 
> have types of types.

Well, Dmitry, you had better get busy correcting all the factually-incorrect Ada reference material out there an planet Earth, letting them know the error of their ways.  Here are some places to start your correction campaign of lots of emails to write and lots of telephone calls to make:

https://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation#Terminology
“Class (of types) [plural] : a tree [!] of classes, rooted by a base class and including all the (recursively-)derived classes of that base class”

http://adapower.com/index.php?Command=Class&ClassID=FAQ&CID=352
“class is a set [!] of types [plural!] with similar values and operations; in particular, ••a type and and all [!] of its derivatives [!], direct and indirect••, represents a (derivation) class.”

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-07-28 15:41                           ` Dmitry A. Kazakov
  2018-07-28 16:05                             ` Dan'l Miller
@ 2018-08-06 19:33                             ` Vincent
  2018-08-06 22:01                               ` Dmitry A. Kazakov
  1 sibling, 1 reply; 29+ messages in thread
From: Vincent @ 2018-08-06 19:33 UTC (permalink / raw)


Le samedi 28 juillet 2018 17:41:53 UTC+2, Dmitry A. Kazakov a écrit :
 
> Ada 95 never had methods nested in type declaration. (Ada 83 did this 
> error for protected objects and tasks, but the lesson was learned)

What is the problem with methods nested in type declaration ?

It seems to me that with the Ada95 OO style, we have awful "freezing rules", and less visibility of which operation is dispatching and which is not.

> Yes, Ada's OO model is the only correct one, IMO. 
> The concept of operations nested class type declaration is evident garbage in the light of MD. 

But that's a paradox since as you mentioned, this Ada model is not able to deal with MD !

In both cases (in Ada and in languages that nest methods in types) one needs to deal with multiple dispatch "at hand" by an ad hoc procedure that uses class wide arguments and test them. For the obvious reason that there is no evident ordering of a pair of elements, event if each element is ordered.

Regards,

Vincent

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-08-06 19:33                             ` Vincent
@ 2018-08-06 22:01                               ` Dmitry A. Kazakov
  2021-12-09 11:13                                 ` Kevin Chadwick
  0 siblings, 1 reply; 29+ messages in thread
From: Dmitry A. Kazakov @ 2018-08-06 22:01 UTC (permalink / raw)


On 2018-08-06 21:33, Vincent wrote:
> Le samedi 28 juillet 2018 17:41:53 UTC+2, Dmitry A. Kazakov a écrit :
>   
>> Ada 95 never had methods nested in type declaration. (Ada 83 did this
>> error for protected objects and tasks, but the lesson was learned)
> 
> What is the problem with methods nested in type declaration ?

That no type has operations that only involve that type. Nested 
declarations prevent most of the types to have classes. In a sane 
language design all types must have classes.

> It seems to me that with the Ada95 OO style, we have awful "freezing rules", and less visibility of which operation is dispatching and which is not.

How are they awful? Clearly an incomplete type cannot be fully used. So 
there must be a freezing point where the type becomes usable.

This has nothing to do with style, of which there is no choice. The only 
possible style is the Ada's one. All C++ proposals for MD switch to Ada 
style at once. Operations simply do not belong to a single type, there 
is no way they can be nested in a single type declaration.

Considering dispatching, all operations should always be dispatching. 
Even a class-wide operation is dispatching on the class class etc.

>> Yes, Ada's OO model is the only correct one, IMO.
>> The concept of operations nested class type declaration is evident garbage in the light of MD.
> 
> But that's a paradox since as you mentioned, this Ada model is not able to deal with MD !

On the contrary, nested declaration of operations automatically preclude 
MD. Where to place Print (Surface, Text)? In Ada model this problem does 
not exist:

    type Surface is ...;
    type Text is ...;
    procedure Print (X : in out Surface; Y : Text);

Problems with MD lie elsewhere.

> In both cases (in Ada and in languages that nest methods in types) one needs to deal with multiple dispatch "at hand" by an ad hoc procedure that uses class wide arguments and test them.

That is not MD and it cannot handle MD except for few very special 
cases. In other cases it violates basic implementation requirements like 
compile time guaranty that all combinations of types are covered and 
that no faulty implementations are inherited.

> For the obvious reason that there is no evident ordering of a pair of elements, event if each element is ordered.

MD dispatching table is a multidimensional array. There is no ordering 
and therefore it is impossible to inherit all MD bodies. But some bodies 
can and must be inherited.

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

^ permalink raw reply	[flat|nested] 29+ messages in thread

* Re: Ada Distilled by Richard Riehle
  2018-08-06 22:01                               ` Dmitry A. Kazakov
@ 2021-12-09 11:13                                 ` Kevin Chadwick
  0 siblings, 0 replies; 29+ messages in thread
From: Kevin Chadwick @ 2021-12-09 11:13 UTC (permalink / raw)


2012 is available on the Amazon Kindle store.

It's subprogram function in out parameter table is out of date though.

^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2021-12-09 11:13 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-15 18:09 Ada Distilled by Richard Riehle rabbibotton
2018-07-16  1:02 ` Shark8
2018-07-21  6:07   ` Randy Brukardt
2018-07-26  0:42     ` rabbibotton
2018-07-26 20:17       ` Shark8
2018-07-26 21:10         ` Jeffrey R. Carter
2018-07-27  3:01           ` Paul Rubin
2018-07-27 14:32           ` rabbibotton
2018-07-27 20:18             ` Paul Rubin
2018-07-27 17:02           ` Shark8
2018-07-27 14:30         ` rabbibotton
2018-07-27 17:11           ` Shark8
2018-07-27 18:52             ` Dan'l Miller
2018-07-27 20:07               ` Dmitry A. Kazakov
2018-07-27 20:38                 ` Dan'l Miller
2018-07-27 21:32                   ` Dmitry A. Kazakov
2018-07-28  2:41                     ` Dan'l Miller
2018-07-28  7:10                       ` Dmitry A. Kazakov
2018-07-28 15:01                         ` Dan'l Miller
2018-07-28 15:41                           ` Dmitry A. Kazakov
2018-07-28 16:05                             ` Dan'l Miller
2018-08-06 19:33                             ` Vincent
2018-08-06 22:01                               ` Dmitry A. Kazakov
2021-12-09 11:13                                 ` Kevin Chadwick
2018-07-27 21:34                 ` Shark8
2018-07-27 22:16                   ` Dmitry A. Kazakov
2018-07-28  3:52                 ` Dan'l Miller
2018-07-28  7:12                   ` Dmitry A. Kazakov
2018-07-27 20:35               ` Paul Rubin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox