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