Parameterless generic instance in place of opaque type instance

Parameterless generic instance in place of opaque type instance

[Yannick Duchêne (Hibou57)]

Hi Ada designers,

An idea comes to me from time to time, and it came back to me as a  
seducing option for a package, just today.

Opaque types are nice, when simple. There are however which requires to  
pull a lot into the private part of a package. Some type may perfectly be  
singleton, so that a package may just hold all of its state instead of a  
record. Bad practice though, that's a too much sever limitation, when the  
type is not to be by nature, a singleton.

There are types, although they are not singleton by nature, whose instance  
may by nature, typically be created sparingly, and not to be stored in  
aggregates, I mean, instances of these type are typically not to be hold  
by a record or an array (just to cite these), nor have access (as in  
access type) to it.

For these types, a parameterless generic instance may be enough. I hope  
most compilers are clever enough to not duplicate machine code for each of  
these instances, and just duplicate their data (valid or invalid  
assumption?).

Just that I've not seen that pattern too much (to be honest, never), so I  
would like to know if there are people here who already did this and what  
can be reported about this pattern on the long run.

Good or bad pattern in your opinion?

My personal opinion, is that I don't see any issue with it, but to not  
have ever seen this done by any one else, make me wonder and wrinkle a  
bit, thus this thread here.


-- 
“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: Parameterless generic instance in place of opaque type instance

[Yannick Duchêne (Hibou57)]

Le Sun, 28 Jul 2013 07:49:36 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> Just that I've not seen that pattern too much (to be honest, never), so  
> I would like to know if there are people here who already did this and  
> what can be reported about this pattern on the long run.

The Ada 95 Q&S Guide mention this pattern, and seems to have no more to  
say about it, not more than what is obvious:
http://www.adaic.org/resources/add_content/docs/95style/html/sec_8/8-3-5.html
They call this pattern, “Generic Abstract Data Object”.

If this Q&S Guide mention it, it must have been used by some people  
sometimes, so may be I'm just not wrong if I opt for this. The only issue  
then could be: do compilers handle this well? (without unnecessary  
duplication).

I still welcome any comments, if there are some worth to be reported.

-- 
“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: Parameterless generic instance in place of opaque type instance

[Yannick Duchêne (Hibou57)]

Le Sun, 28 Jul 2013 08:36:36 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> The Ada 95 Q&S Guide mention this pattern, and seems to have no more to  
> say about it, not more than what is obvious:
> http://www.adaic.org/resources/add_content/docs/95style/html/sec_8/8-3-5.html
> They call this pattern, “Generic Abstract Data Object”.

An idea, and there may have missed another interesting variation,  
something with mixed properties from a GADO and an ADT.

Say a GADO still defines an ADT, with an unknown discriminant, so that it  
cannot be instantiated without initialization. What the private declares,  
is just an access type to a deferred type (defined in the body). The body  
defines an instance of the type it fully defines. The package offers a  
single function returning an (opaque) access to this unique and  
per‑paquage instance, instance. The function could be named  
`Instance_Reference`, to clearly show it's always the same behind, however  
a new distinct one per generic instance (not strictly a singleton, a  
per‑package singleton).

This would provide some of the benefit of an ADT and some of a GADO,  
together. The same as an ADT regarding the ability to pass it to a  
sub‑program, while avoiding the heap allocation (which I surely don't  
want) otherwise required with an access to a deferred type (or else an  
allocation in a static pool, … not so nice for many reasons) and avoiding  
to pollute the private part of the package (I don't enjoy when the private  
part monopolizes 85% of a package's text).

This could be named, say “Generic Abstract Singleton Data Type”, or  
something like that :-D

What's you feeling on that variation?

-- 
“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: Parameterless generic instance in place of opaque type instance

[Yannick Duchêne (Hibou57)]

Le Sun, 28 Jul 2013 09:02:22 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> Say a GADO still defines an ADT, with an unknown discriminant, so that  
> it cannot be instantiated without initialization. What the private  
> declares, is just an access type to a deferred type (defined in the  
> body). The body defines an instance of the type it fully defines. The  
> package offers a single function returning an (opaque) access to this  
> unique and per‑paquage instance, instance. The function could be named  
> `Instance_Reference`, to clearly show it's always the same behind,  
> however a new distinct one per generic instance (not strictly a  
> singleton, a per‑package singleton).

I should have posted an Ada sample, to be more meaningful. Here is:


     generic
     package Samples is
        type Reference_Type (<>)
           is private;
        function Reference
           return Reference_Type;
        procedure Operation
          (Reference : Reference_Type);
     private
        type Data_Type;
        type Reference_Type
           is not null access all Data_Type;
     end;

     package body Samples is
        type Data_Type
           is record
              null;
           end record;
        Data : aliased Data_Type;
        function Reference
           return Reference_Type
           is (Data'Access);
        procedure Operation
          (Reference : Reference_Type)
        is begin
           null;
        end;
     end;

     procedure Use_A_Sample
     is
        package Sample
           is new Samples;
        Reference :
           Sample.Reference_Type :=
             (Sample.Reference);
        procedure Receive_A_Parameter
          (Reference : Sample.Reference_Type)
        is begin
           Sample.Operation (Reference);
        end;
     begin
        Receive_A_Parameter (Reference);
     end;


-- 
“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: Parameterless generic instance in place of opaque type instance

[J-P. Rosen]

Le 28/07/2013 07:49, Yannick Duchêne (Hibou57) a écrit :
> For these types, a parameterless generic instance may be enough. I hope
> most compilers are clever enough to not duplicate machine code for each
> of these instances, and just duplicate their data (valid or invalid
> assumption?).
This is a basic design pattern of HOOD (and the main one in early
versions). Since HOOD is based on abstract state machines, it
represented each machine with a package, and the package was made
generic if you wanted several identical ASM.

In early versions of HOOD, such generics were called "classes", since
they defined a model for several instances. Due to the confusion with
OOP classes, the name was changed to "generic" later.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Parameterless generic instance in place of opaque type instance

[Yannick Duchêne (Hibou57)]

Le Sun, 28 Jul 2013 09:30:18 +0200, J-P. Rosen <rosen@adalog.fr> a écrit:

> Le 28/07/2013 07:49, Yannick Duchêne (Hibou57) a écrit :
>> For these types, a parameterless generic instance may be enough. I hope
>> most compilers are clever enough to not duplicate machine code for each
>> of these instances, and just duplicate their data (valid or invalid
>> assumption?).
> This is a basic design pattern of HOOD (and the main one in early
> versions). Since HOOD is based on abstract state machines, it
> represented each machine with a package, and the package was made
> generic if you wanted several identical ASM.

Thanks for the notice Jean‑Pierre! (also reminds me I should have a deep  
and serious look a future day, at that PDF I have about HOOD)

-- 
“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: Parameterless generic instance in place of opaque type instance

[Robert A Duff]

"Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr> writes:

> For these types, a parameterless generic instance may be enough. I hope
> most compilers are clever enough to not duplicate machine code for each
> of  these instances, and just duplicate their data (valid or invalid
> assumption?).

Randy's compiler is clever enough to do that.  In fact it shares
generic code always.  There's a run-time cost to that, though.
GNAT never shares code.  Most Ada compilers I'm aware of do
not share.

- Bob

Re: Parameterless generic instance in place of opaque type instance

[Shark8]

On Sunday, July 28, 2013 2:24:32 AM UTC-6, Hibou57 (Yannick Duchêne) wrote:
> 
> Thanks for the notice Jean-Pierre! (also reminds me I should have a deep  
> and serious look a future day, at that PDF I have about HOOD)


Do you have a URL to that PDF? It sounds like it might be interesting to read.

Re: Parameterless generic instance in place of opaque type instance

[Yannick Duchêne (Hibou57)]

Le Sun, 28 Jul 2013 20:08:45 +0200, Shark8 <onewingedshark@gmail.com> a  
écrit:

> On Sunday, July 28, 2013 2:24:32 AM UTC-6, Hibou57 (Yannick Duchêne)  
> wrote:
>>
>> Thanks for the notice Jean-Pierre! (also reminds me I should have a deep
>> and serious look a future day, at that PDF I have about HOOD)
>
>
> Do you have a URL to that PDF? It sounds like it might be interesting to  
> read.

No, I don't. IIRC, its on‑line redistribution is not allowed, and I'm not  
allowed to send you a copy. You may ask the author though (J‑P. him‑self),  
if he agree.


-- 
“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: Parameterless generic instance in place of opaque type instance

[Shark8]

Oh, of possible interest to you is this paper on Ada generics:
   http://www.cs.dartmouth.edu/reports/TR86-104.pdf

It draws comparisons between records and [generic] packages, though touches on forcing certain parameter-passing or evaluation-order.

Re: Parameterless generic instance in place of opaque type instance

[J-P. Rosen]

Le 28/07/2013 21:47, Yannick Duchêne (Hibou57) a écrit :
> No, I don't. IIRC, its on‑line redistribution is not allowed, and I'm
> not allowed to send you a copy. You may ask the author though (J‑P.
> him‑self), if he agree.
More precisely, the copyright status is unclear, which is why I don't
post it, but send it privately to anyone who asks me.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Parameterless generic instance in place of opaque type instance

[Shark8]

On Sunday, July 28, 2013 3:15:24 PM UTC-6, J-P. Rosen wrote:
> 
> 
> More precisely, the copyright status is unclear, which is why I don't
> post it, but send it privately to anyone who asks me.

Ah, I'd like a copy please. [At gmail, 1wingedshark, with the numeral spelled out.]

Re: Parameterless generic instance in place of opaque type instance

[Yannick Duchêne (Hibou57)]

Le Sun, 28 Jul 2013 22:58:54 +0200, Shark8 <onewingedshark@gmail.com> a  
écrit:

> Oh, of possible interest to you is this paper on Ada generics:
>    http://www.cs.dartmouth.edu/reports/TR86-104.pdf
>
> It draws comparisons between records and [generic] packages, though  
> touches on forcing certain parameter-passing or evaluation-order.

Indeed, looks promising.

Short excerpt from the introduction:

> […] Ada text books reveals a rather limited view of Ada's
> generic facilities: a mean of adding type parameters to
> abstract data types and procedure [Barnes, Habermann].
> In this paper, I claim that there are more uses for generic
> than stack packages, swap procedures and numerical integration
> functions.
>The sections of the paper are organized around two strategiesfor using  
> Ada's generic features: generalized records andparameter control. The  
> next section outlines how genericpackages can be viewed and used as  
> record. […]

I guess I will love this one :-) (I really have to get an e‑book reader  
some day… more comfortable for long time reading).

P.S. As you just rather get an invitation to not be afraid to ask for the  
HOOD book, I can only recommend you to acknowledge this invitation. HOOD  
is an interesting topic, far from being yet‑another‑kind‑of UML. It's a  
notation and a complete method, and as a notation, it balance well  
graphical and textual representations. It's an up to date version, dated  
1997, while the final stable revision was achieved on 1995 (so edited  
after, and thus, up to date). It's about 220 pages.

HOOD was an initiative of the ESA, which stands for European Space Agency.  
However, I don't know anything about the current status of HOOD at the  
ESA. I can just notice the ESA page [1] which very briefly introduce HOOD  
history, was last updated on 2006.

[1]:  
http://www.esa.int/TEC/Software_engineering_and_standardisation/TECKLAUXBQE_0.html


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