Re: Generics vs. O-O?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 02.08.13 10:11, Dmitry A. Kazakov wrote:

>> package N is
>>
>>     type T is range -1 .. 1;
>>
>>     generic
>>       type S is new T;
>>     package Pointless is end;
>>
>>     type Q is range -1 .. 1;
>>
>>     package Exmpl is new Pointless (Q);  -- error
>>
>> end N;
>>
>> Equivalent structure of scalar types T and Q won't do.
>
> You cannot specify what belongs to a formal class it is decided by the
> structure of given type.


Formal classes exist only when meta-talking about Ada templates. Or
about whether or not generics can be used as if some extraneous
formalism influences the choice of one or other Ada mechanism. It
might be helpful to name this context, explicitly, as the discussion
confuses concepts that are defined outside Ada and concepts from
"inside" Ada, such as the structure of a given type, I assume.

Translating to Ada, and with reference to generic formal types, I can
indicate a category of types. There are no formal classes.

> Regarding your example the class you used is one created outside the
> generics. It is good that Ada 95 allowed this, but it does not change the
> nature of the language of formal generic specifications.

View 1:

The nature of formal generic specifications is not one whose
instantiations will produce typed instances, because the latter
is not defined, or intended, in Ada. In a different theory,
things will appear differently.

View 2:

Not all generic formals allow indicating the "formal classes"
you find important WRT "belonging", but don't care to say what
a "formal class" is, or what "belonging" might mean WRT outreach
and"verifiable substitutability".

> Here substitutability encompasses all parameters generics take, not just
> types. E.g.
>
> generic
>     with function Foo (X : Integer) return Real;
> package Bar is ...
>
> You cannot verify if Baz
>
>     function Baz (X : Integer) return Real;
>
> were substitutable in Bar for Foo.

I cannot verify substitutability of unspecified nature anywhere
in Ada except maybe within unspecified confines of some verifiable
part of programs, and limiting "verifiable substitution", rather
tautologically, to what happens to be so testable within a given
choice of language features as to show whether or not something
satisfies the definition of exactly that "verifiable substitution"
the speaker has in mind.

It will be helpful to pinpoint this idea more precisely,
or verifiably, if you will.

For example, a formal type may be one that has T as an ancestor,
T giving enough of verifiable information such that each
instance specifies sets of values that objects will assume
as a consequence of certain operations.


> Parametric polymorphism of generics is way too loose, because it basically
> untyped. Worse is that it is any useful so long it remains untyped. Once
> you try to put types on it, it will be as "inconvenient" as any type
> system, while keeping all disadvantages of being strictly compile-time.

If something *is* known at compile time, but *could* be different for
a different compilation, then static choice of shape (μορφή, morphi)
facilitated by generic instantiation turns out to be one-time
dispatching without the need for anything at run-time.
Polymorphic things are not needed for monomorphic programs.

Choosing generics can remove the disadvantages of the unneeded "much"
(πολύς, polys). Simple generics can reduce complexity by removing the
overhead of  polymorphic dummy parameters of a single, specific type.

Choice of a single type may in cases be achieved by editing a single
definition in some top level package, too, for example when the type
is a scalar type. But this does not always work well. For example, if
you'd want a callback to be passed somewhere. Then, dismissing generics
might entail the introduction of one level of indirection (subprogram
pointer), or some dummy parameter (polymorphic, type based
choice). These artifacts serve no purpose other than sustaining
geniophobia. ;-) ;-) And they might be inefficient in inner loops.