Generics vs. O-O?

Generics vs. O-O?

[Eryndlia Mavourneen]

I need to write a template package to be used by several different mechanisms (units).  The question is, "What are the trade-offs between using a generic package as the template and using a package-as-class containing O-O code?"  I am aware that generics can take more time to compile; however, I am more interested in run-time effects.

Can anyone provide a short summary?

-- Eryndlia (KK1T)

Re: Generics vs. O-O?

[Dmitry A. Kazakov]

On Thu, 1 Aug 2013 07:45:13 -0700 (PDT), Eryndlia Mavourneen wrote:

> I need to write a template package to be used by several different
> mechanisms (units).  The question is, "What are the trade-offs between
> using a generic package as the template and using a package-as-class
> containing O-O code?"  I am aware that generics can take more time to
> compile; however, I am more interested in run-time effects.

I don't really understand the question.
 
> Can anyone provide a short summary?

1. Both generics and OO (tagged types) represent polymorphism.

2. Generics is so-called parametric or static polymorphism.

3. Tagged types is dynamic polymorphism.

4. Beyond "generic programming" generics are not restricted to only types.
In Ada one can have generic objects, operations, anything that can be put
into a generic unit.

5. Considering run-time effects generics obviously have none because it is
static polymorphism.

6. Generic classes are implicit and have no objects. Tagged classes are
explicit and may have class-wide objects.

7. Formal generic types of Ada are weakly typed. Matching is by structure.
User-defined generic types (ADTs) are not supported. User-defined
operations on formal types are not supported. The language of formal
generic parameters is somewhere between FORTRAN-IV and K&R C.

8. Tagged types are fully integrated into Ada's type system. Still some
classes of Ada types are not proper tagged classes, e,g, numbers, tasks
etc.

9. Generic units are basically non-testable. Substitutability issues are
difficult to verify because of 7.

10. For tagged types substitutability is a problem as well.

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

Re: Generics vs. O-O?

[Eryndlia Mavourneen]

On Thursday, August 1, 2013 2:24:57 PM UTC-5, Dmitry A. Kazakov wrote:
> On Thu, 1 Aug 2013 07:45:13 -0700 (PDT), Eryndlia Mavourneen wrote:
> 
> > I need to write a template package to be used by several different
> > mechanisms (units).  The question is, "What are the trade-offs between
> > using a generic package as the template and using a package-as-class
> > containing O-O code?"  I am aware that generics can take more time to
> > compile; however, I am more interested in run-time effects.
> 
> I don't really understand the question.
> > Can anyone provide a short summary?
> 
> 1. Both generics and OO (tagged types) represent polymorphism.
> 
> 2. Generics is so-called parametric or static polymorphism.
> 
> 3. Tagged types is dynamic polymorphism.
> 
> 4. Beyond "generic programming" generics are not restricted to only types.
> In Ada one can have generic objects, operations, anything that can be put
> into a generic unit.
> 
> 5. Considering run-time effects generics obviously have none because it is
> static polymorphism.
> 
> 6. Generic classes are implicit and have no objects. Tagged classes are
> explicit and may have class-wide object
> 
> 7. Formal generic types of Ada are weakly typed. Matching is by structure.
> User-defined generic types (ADTs) are not supported. User-defined
> operations on formal types are not supported. The language of formal
> generic parameters is somewhere between FORTRAN-IV and K&R C.
> 
> 8. Tagged types are fully integrated into Ada's type system. Still some
> classes of Ada types are not proper tagged classes, e,g, numbers, tasks
> etc.
> 
> 9. Generic units are basically non-testable. Substitutability issues are
> difficult to verify because of 7.
> 
> 10. For tagged types substitutability is a problem as well.
> 
> -- 
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

Thank you, Dmitry.  This is pretty much my understanding.  I have run into problems several times with the "weakly typed" issue with generics.  It usually means adding additional formal parameters or making the parameter in question less general.

The run-time overhead would appear to be in favor of generics cpu-wise; however, the memory overhead for non-shared generic code could be substantial.  I believe you have some experience with this.

I think that I actually will use a combination of generic code and O-O, using generic parameters to bring in one or two external data types and using the O-O to introduce the subprograms as well as the type that maintains state.

-- Eryndlia (KK1T)

Re: Generics vs. O-O?

[sbelmont700]

On Thursday, August 1, 2013 3:52:42 PM UTC-4, Eryndlia Mavourneen wrote:
> 
> ...the memory overhead for non-shared generic code could be substantial...
>

I have occasion to deal with a lot of "clever" code that fakes OOP using generic packages, i.e. where each instantiation is an object and generic object parameters serve as initializers, and the executable sizes are *tremendous* (presumably the compiler duplicates the code for every subprogram for every instantiation).  As a general rule, I stick to type parameters.

-sb

Re: Generics vs. O-O?

[Yannick Duchêne (Hibou57)]

Le Thu, 01 Aug 2013 22:14:48 +0200, <sbelmont700@gmail.com> a écrit:

> On Thursday, August 1, 2013 3:52:42 PM UTC-4, Eryndlia Mavourneen wrote:
>>
>> ...the memory overhead for non-shared generic code could be  
>> substantial...
>>
>
> I have occasion to deal with a lot of "clever" code that fakes OOP using  
> generic packages, i.e. where each instantiation is an object and generic  
> object parameters serve as initializers, and the executable sizes are  
> *tremendous* (presumably the compiler duplicates the code for every  
> subprogram for every instantiation).  As a general rule, I stick to type  
> parameters.
>
> -sb

May this is GNAT? And may she's not using GNAT.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Generics vs. O-O?

[optikos]

On Thursday, August 1, 2013 2:24:57 PM UTC-5, Dmitry A. Kazakov wrote:
> [... snip ...]
> 5. Considering run-time effects generics obviously have none because it is
> static polymorphism.
> [... snip ...]

Not so fast.  Your statement on your #5 is true for C++ templates, but not true for Ada generics.  The difference is that instantiations by different combinations of template-parameters of a C++ template result in a combinatorial explosion of the quantity of instances of that template's machine code & static data.

Conversely, Ada utilizes a single instance of machine code & static data for an Ada generic, regardless of the type parameters passed at compile-time.  This single instance of machine-code accommodates different type parameters by either branching (around different per-type-parameter treatment) or table look-up (of the size & structure of entities).  No such branching or table-lookup is present in the corresponding combinatorial explosion of C++ template instantiation.  This conflation by branching or table look-up in Ada is precisely why the combinatorial explosion does not occur in Ada generics, as it does in C++ templates.

Hence, Ada's branching and table-lookups will in fact incur some execution-time overhead when compared to analogous C++ templates and when compared to nongeneric equivalent functionality.  Conversely, when looking at code bloat, Ada's generics will incur some executable-size space overhead when compared to nongeneric equivalent functionality, but both the Ada generic and the nongeneric equivalent functionality will result in drastically smaller executables than a (naïvely-designed) C++ template that is instantiated with a vast quantity of combinations of parameters to that C++ template.  Hence, in C++, the best-practice is to manually design a C++ template whose nontemplated guts accomplishes the conflation that the Ada compiler performs for an Ada generic.  In C++ this often means that a type-safe C++ template thinly ricochets off to a nontemplate/nongeneric functionality that utilizes void* & corresponding sizeof to defeat all type-safety of objects or scalars.

Re: Generics vs. O-O?

[Dmitry A. Kazakov]

On Thu, 1 Aug 2013 13:10:39 -0700 (PDT), optikos@verizon.net wrote:

> On Thursday, August 1, 2013 2:24:57 PM UTC-5, Dmitry A. Kazakov wrote:
>> [... snip ...]
>> 5. Considering run-time effects generics obviously have none because it is
>> static polymorphism.
>> [... snip ...]

[...]
> Hence, Ada's branching and table-lookups will in fact incur some
> execution-time overhead when compared to analogous C++ templates and when
> compared to nongeneric equivalent functionality.

This effect is *logically* void. Furthermore, any program that might
exploit it is erroneous.

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

Re: Generics vs. O-O?

[Jeffrey Carter]

On 08/01/2013 01:10 PM, optikos@verizon.net wrote:
>
> Conversely, Ada utilizes a single instance of machine code & static data for
> an Ada generic, regardless of the type parameters passed at compile-time.
> This single instance of machine-code accommodates different type parameters
> by either branching (around different per-type-parameter treatment) or table
> look-up (of the size & structure of entities).  No such branching or
> table-lookup is present in the corresponding combinatorial explosion of C++
> template instantiation.  This conflation by branching or table look-up in Ada
> is precisely why the combinatorial explosion does not occur in Ada generics,
> as it does in C++ templates.

While Ada generics /can/ be implemented this way (see Janus/Ada for an instance 
proof), most Ada compilers do not implement generics this way, but do macro 
expansion (see GNAT for an example).

-- 
Jeff Carter
"I feel as though somebody stepped on my tongue
with muddy feet."
Never Give a Sucker an Even Break
112

Re: Generics vs. O-O?

[Bill Findlay]

On 01/08/2013 21:10, in article
fdf94891-3258-480d-a203-c157559e928f@googlegroups.com, "optikos@verizon.net"
<optikos@verizon.net> wrote:

> On Thursday, August 1, 2013 2:24:57 PM UTC-5, Dmitry A. Kazakov wrote:
>> [... snip ...]
>> 5. Considering run-time effects generics obviously have none because it is
>> static polymorphism.
>> [... snip ...]
> 
> Not so fast.
...
> Conversely, Ada utilizes a single instance of machine code & static data for
> an Ada generic, regardless of the type parameters passed at compile-time.
 
Thare is nothing like a well founded, penetrating analysis of language
semantics.   And this is, indeed, nothing like one.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Generics vs. O-O?

[Yannick Duchêne (Hibou57)]

Le Thu, 01 Aug 2013 22:10:39 +0200, <optikos@verizon.net> a écrit:

> On Thursday, August 1, 2013 2:24:57 PM UTC-5, Dmitry A. Kazakov wrote:
>> [... snip ...]
>> 5. Considering run-time effects generics obviously have none because it  
>> is
>> static polymorphism.
>> [... snip ...]
>
> Not so fast.  Your statement on your #5 is true for C++ templates, but  
> not true for Ada generics.  The difference is that instantiations by  
> different combinations of template-parameters of a C++ template result  
> in a combinatorial explosion of the quantity of instances of that  
> template's machine code & static data.
>
> Conversely, Ada utilizes a single instance of machine code & static data  
> for an Ada generic, regardless of the type parameters passed at  
> compile-time.  […]

Not sure “Ada utilizes” is correct, and rather “This/that compiler  
utilizes” is. What compiler do you use?


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Generics vs. O-O?

[Georg Bauhaus]

On 01.08.13 21:24, Dmitry A. Kazakov wrote:

> 7. Formal generic types of Ada are weakly typed. Matching is by structure.
> User-defined generic types (ADTs) are not supported. User-defined
> operations on formal types are not supported. The language of formal
> generic parameters is somewhere between FORTRAN-IV and K&R C.

Not quite far from a misrepresentation of Ada generics.
Nothing in the languages mentioned can require type equivalence
by name in whatever generic formals, as in

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.

> 9. Generic units are basically non-testable. Substitutability issues are
> difficult to verify because of 7.

With generics, substitutability issues arise as soon as one wishes to subsume
the mechanism of generic units under a formally extraneous type systems.
So, judicious use of this language features for things other than typing
might be the better choice.


In general, attributing "weakly typed" to languages will profit
from being done in a more detailed, more informative, and therefore
more convincing  way. The C example

struct A {};
struct B {};

int f(struct A x) {}
int g(struct B y) {}

void test()
{
   f((struct B){});  /* compile time type error */
}

shows that C is not entirely weakly typed!

Re: Generics vs. O-O?

[Dmitry A. Kazakov]

On Fri, 02 Aug 2013 00:20:47 +0200, Georg Bauhaus wrote:

> On 01.08.13 21:24, Dmitry A. Kazakov wrote:
> 
>> 7. Formal generic types of Ada are weakly typed. Matching is by structure.
>> User-defined generic types (ADTs) are not supported. User-defined
>> operations on formal types are not supported. The language of formal
>> generic parameters is somewhere between FORTRAN-IV and K&R C.
> 
> Not quite far from a misrepresentation of Ada generics.
> Nothing in the languages mentioned can require type equivalence
> by name in whatever generic formals, as in
> 
> 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.

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.

>> 9. Generic units are basically non-testable. Substitutability issues are
>> difficult to verify because of 7.
> 
> With generics, substitutability issues arise as soon as one wishes to subsume
> the mechanism of generic units under a formally extraneous type systems.
> So, judicious use of this language features for things other than typing
> might be the better choice.

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.

One of the motivations beyond types engaging in complex relationship was to
limit the framework where substitution is considered.

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.

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

Re: Generics vs. O-O?

[Georg Bauhaus]

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.

Re: Generics vs. O-O?

[Dmitry A. Kazakov]

On Fri, 02 Aug 2013 11:50:15 +0200, Georg Bauhaus wrote:

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

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

I don't understand what you are trying to say here.

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

If this is a proper class already there is no need to introduce a formal
generic class for it. Generic classes are useful when they cannot be spelt
by regular means. Generics are all about patching deficiencies of the type
system. With the type system brought in order, you will need no generics.

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

There is only one compilation of the program. Each compilation produces
another program.

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

Removing parameter in which sense? Compare removing parameter of sine as an
example (in order to reduce complexity of course). The result is a
different object, a number. Function is not number. If you can reduce
generics to non-generics it is no generics. Good riddance.

> 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),

There is no need in using pointers in order to achieve downward closures.
It was a kludge of Ada 95 design. Generics is a kludge of Ada 83 design. I
always prefer proper objects with a dispatching operation over closures
(callbacks), because an object explicitly encapsulates state while the
closure gather everything visible in the context. It is for sloppy
programming style barely reconcilable with Ada. Yet another language design
problem that there is no simple way to declare such singleton types in Ada.

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

Re: Generics vs. O-O?

[Shark8]

On Friday, August 2, 2013 8:09:46 AM UTC-6, Dmitry A. Kazakov wrote:
> 
> 
> > 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),
> 
> There is no need in using pointers in order to achieve downward closures.
> It was a kludge of Ada 95 design. Generics is a kludge of Ada 83 design.

No, it was a well thought-out and justified feature; see the Ada83 rationale:

12.1 Introduction
Generic units are a general form of parameterized program units. As with other parameterization mechanisms, the primary purpose is factorization, resulting in a reduction in the size of the program text while also improving maintainability, readability, and efficiency.

Parameterization by generic units is a natural extension of subprogram parameterization. When otherwise identical actions differ by a particular value or variable, these actions may be encapsulated in a subprogram where the value or variable appears as a parameter. Having thereby factored out the common part, the text becomes smaller and easier to read; and clerical errors, resulting from accidental lack of identity among the copies, are eliminated. Moreover, compilers can take advantage of this commonality to produce more compact code.

Traditional parameterization mechanisms are usually in terms of values and variables. But the same factorization arguments apply when two otherwise identical program units differ by some other property, such as a type. 

> Yet another language design
> problem that there is no simple way to declare such singleton types in Ada.

Really?
In Ada 2012 I can say the following:

    package Test is

	Type K is Private;
	
	J : Integer := 12;
	
    private
	use type System.address;
	
	type K is new integer with TYPE_INVARIANT => K'Address = J'Address;
    end test;

Type K sure looks like a singleton to me.

Re: Generics vs. O-O?

[Alan Jump]

On Friday, August 2, 2013 8:08:38 AM UTC-7, Shark8 wrote:
> > Yet another language design
> > problem that there is no simple way to declare such singleton types in Ada.

> Really?
> In Ada 2012 I can say the following:
>     package Test is
> 	Type K is Private;
> 	J : Integer := 12;
>     private
> 	use type System.address;
> 	type K is new integer with TYPE_INVARIANT => K'Address = J'Address;
>     end test;
>
> Type K sure looks like a singleton to me.

This is going off on a bit of a tangent, but as a new student of the language, I  think a case could be made that many stand-alone packages or procedures in Ada are singletons, simply because of Ada's inherent strong typing. After all, what's a singleton? By definition, to be a singleton pattern, two criteria must be met: one and only one instance with a global point of access, and initialization on first use. (Source: http://sourcemaking.com/design_patterns/singleton)

With that said, and again being a new student of the language, I find myself in favor of generic use, simply from a standpoint of code reuse. A well-designed algorithm that finds itself applied several times within a given procedure, which varies only in parameter types, should only have to be coded once.

Just my 2p worth...save up the change for a pack of monitor wipes or something.

 - -
73 de N5ILN
Alan

Re: Generics vs. O-O?

[Jeffrey Carter]

On 08/02/2013 08:36 AM, Alan Jump wrote:
>
> This is going off on a bit of a tangent, but as a new student of the
> language, I  think a case could be made that many stand-alone packages or
> procedures in Ada are singletons, simply because of Ada's inherent strong
> typing. After all, what's a singleton? By definition, to be a singleton
> pattern, two criteria must be met: one and only one instance with a global
> point of access, and initialization on first use. (Source:
> http://sourcemaking.com/design_patterns/singleton)

Right. The "singleton type" is a kludge from languages that confuse the concepts 
of type and module. In Ada, which properly separates these concepts, a singleton 
is simply a package.

-- 
Jeff Carter
"You me on the head hitted."
Never Give a Sucker an Even Break
108

Re: Generics vs. O-O?

[Dmitry A. Kazakov]

On Fri, 2 Aug 2013 08:36:14 -0700 (PDT), Alan Jump wrote:

> After all, what's a singleton?

Singleton is a type of which only one instance exists.

> By definition, to be a singleton
> pattern, two criteria must be met: one and only one instance with a global
> point of access, and initialization on first use.

Singleton pattern is a method to enforce a type to be singleton in a
language that does not provide this capacity.

Reasons to deploy this pattern in Ada are questionable at best.

Ada offers support of singletons where appropriate. Here is the list, maybe
incomplete:

1. Anonymous arrays are singletons
2. Procedures and functions are singletons
3. Protected objects are singletons
4. Tasks objects are singletons

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

Re: Generics vs. O-O?

[Alan Jump]

On Friday, August 2, 2013 10:51:03 AM UTC-7, Dmitry A. Kazakov wrote:
> Reasons to deploy this pattern in Ada are questionable at best.
> Ada offers support of singletons where appropriate. Here is the list, maybe
> incomplete:
> 1. Anonymous arrays are singletons
> 2. Procedures and functions are singletons
> 3. Protected objects are singletons
> 4. Tasks objects are singletons

You are stipulating that procedures, functions, protected objects and task objects are singletons, but at the same time, stating there are only questionable reasons to make use of them? Semantically, you have just eliminated the core raison d'etre for the existence of Ada as a language...specifically, strong typing.

Back on the topic of generics, even Barnes has made a strong case for their use, both in his "Programming in Ada 2005" text and, more recently, in his paper "Safe and Secure Software - An Invitation to Ada 2012".

 - -
73 de N5ILN
Alan

Re: Generics vs. O-O?

[Dmitry A. Kazakov]

On Fri, 2 Aug 2013 11:06:33 -0700 (PDT), Alan Jump wrote:

> On Friday, August 2, 2013 10:51:03 AM UTC-7, Dmitry A. Kazakov wrote:
>> Reasons to deploy this pattern in Ada are questionable at best.
>> Ada offers support of singletons where appropriate. Here is the list, maybe
>> incomplete:
>> 1. Anonymous arrays are singletons
>> 2. Procedures and functions are singletons
>> 3. Protected objects are singletons
>> 4. Tasks objects are singletons
> 
> You are stipulating that procedures, functions, protected objects and task
> objects are singletons, but at the same time, stating there are only
> questionable reasons to make use of them?

Not them, but the singleton pattern. You don't need any pattern to make a
procedure singleton. You just define it and here you are, it is a
singleton. Let me elaborate a bit:

1. Anonymous arrays are declared as:

   A : array (1..10) of Character; -- This is a singleton

Compare:

   type Multitude is array (1..10) of Character; -- Not a singleton
   A : Multitude; -- One instance
   B : Multitude; -- Another instance

2. Procedures and functions:

   procedure Foo (I : Integer); -- This a singleton

Ada does not have named procedural types. Thus subroutines are always
singletons.

3. protected Singleton is ...; -- This is a singleton

Compare

   protected type Multitude is ..;
   A : Multitude;
   B : Multitude;

4. task Singleton is ...; -- This is a singleton

Compare;

   task type Multitude is ...;
   A : Multitude;
   B : Multitude;

> Semantically, you have just
> eliminated the core raison d'etre for the existence of Ada as a
> language...specifically, strong typing.

Why? The type of a procedure is not weak. Strong typing is about relation
between objects and types, such that an object has a type (plus some other
requirements). It does not imply that a type has an object (singleton).
Normally the latter is considered a design artifact. Unless trivial cases
like I listed above, more elaborated abstract types are better designed not
to be singletons. Relying on single instance is fragile design.
Notwithstanding that sometimes it is what you need.

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

Re: Generics vs. O-O?

[Dmitry A. Kazakov]

On Fri, 2 Aug 2013 08:08:38 -0700 (PDT), Shark8 wrote:

> On Friday, August 2, 2013 8:09:46 AM UTC-6, Dmitry A. Kazakov wrote:
>> 
>>> 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),
>> 
>> There is no need in using pointers in order to achieve downward closures.
>> It was a kludge of Ada 95 design. Generics is a kludge of Ada 83 design.
> 
> No, it was a well thought-out and justified feature; see the Ada83 rationale:

Generics were fashionable back in 80's. We are 30 years older and hopefully
wiser.

>> Yet another language design
>> problem that there is no simple way to declare such singleton types in Ada.
> 
> Really?
[...]
> Type K sure looks like a singleton to me.

I mean singleton types vs. closures. It is

   type Visitor_Interface is limited interface;
   procedure Meet (State : in out Visitor_Interface; Item : Element'Class)
      is abstract;
   procedure Enumerate
       (  Collection : Container;
         Visitor : in out Visitor_Interface'Class);

vs.

  procedure Enumerate
      (  Collection : Container;
         Action : not null access procedure (Item : Element'Class);

There is no need to be it really a singleton either for the object or for
the closure. Just it is the most common case in practice. 

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

Re: Generics vs. O-O?

[Yannick Duchêne (Hibou57)]

Le Fri, 02 Aug 2013 10:11:32 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> 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 agree with this. Ability to require constraints on type parameters is  
missing. As an example, I wish I could state it must have some  
representation set on some value, or require some preconditions and  
postconditions.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Generics vs. O-O?

[Georg Bauhaus]

On 03.08.13 02:04, Yannick Duchêne (Hibou57) wrote:
> Le Fri, 02 Aug 2013 10:11:32 +0200, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> a écrit:
>> 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 agree with this. Ability to require constraints on type parameters is missing. As an example, I wish I could state it must have some representation set on some value, or require some preconditions and postconditions.
>

Maybe we should coin terms such as "weakly subtyped",
or "weakly constrained" so as to better understand
the foundation of Dmitry's arguments in an Ada context?

Re: Generics vs. O-O?

[Dmitry A. Kazakov]

On Sat, 03 Aug 2013 09:35:53 +0200, Georg Bauhaus wrote:

> Maybe we should coin terms such as "weakly subtyped",

Weak subtyping is exactly what weak typing is. Namely implicit conversions
of the type which changes the semantics of the corresponding value.

(And subtype is a type anyway)

P.S. Note that Ada subtypes are strongly typed when constraint violation is
covered by the contract (Ada 83) and weak if a precondition is used instead
(Ada 2012). Dynamic preconditions constitute weak typing.

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