comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Indefinite Containers of Indefinite Private Types
Date: Fri, 7 Aug 2015 14:49:03 -0500
Date: 2015-08-07T14:49:03-05:00	[thread overview]
Message-ID: <mq323g$jq7$1@loke.gir.dk> (raw)
In-Reply-To: mq0f0g$7im$1@dont-email.me

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:mq0f0g$7im$1@dont-email.me...
> On 08/06/2015 11:49 AM, Randy Brukardt wrote:
>>
>> That's one possibility. We could call it a generic private type. Oops --
>> that name is taken, and alternative names are annoying. (The idea of 
>> course
>> would be similar to the generic incomplete type; the restrictions on the 
>> use
>> of a private type would be enforced on the uses of the generic formal 
>> type.)
>>
>> We've also looked at declarations (maybe an aspect) for the generic as a
>> whole, there was a proposal for a "forward" declaration for the generic
>> (that is, you'd be able to separate the visible part of the generic from 
>> the
>> actual instance, just like in other kinds of packages), and a proposal to
>> change the freezing to be exactly like a macro (meaning a break in the
>> contract model, and a horror to implement on top of that). We also found
>> that there is a workaround of sorts using a child package to hold the
>> instantiation, which works so long as the private type doesn't use 
>> something
>> from the instantiation (usually a cursor for a container) in its full
>> declaration. The existence of the workaround lowers the priority of 
>> finding
>> a fix, and given the difficulty of doing so, we pretty much gave up. I'm
>> sure we'll revisit it someday.
>
> I looked at some of the AIs you mentioned and saw there were a number of 
> ideas.
> The child-pkg workaround involves using an access type, so it doesn't seem 
> to
> gain anything over using access types directly, and is less attractive 
> than
> access-free noise, which seems to me to be another work around not 
> considered in
> the discussion I looked at.
>
> The problem seems to be that there is a single instantiation for both the 
> spec
> and body, and the body occurs and is elaborated immediately at the point 
> of the
> instantiation. Another language might instantiate the spec and body 
> separately,
> allowing the body to be instantiated after the full type. There were some
> suggestions in the AIs along that line, but couched in terms of delaying
> freezing rather than separation of spec and body.
>
> Maybe something like
>
> package P is
>   type T (<>) is private;
> private
>   package Lists is new Indefinite_Vectors
>      (Index_Type => Positive, Element_Type => T)
>   with not body;
>
>   type T is record
>      List : Lists.Vector;
>   end record;
> end P;
>
> package body P is
>   package body Lists is new Indefinite_Vectors;
>   ...

I had suggested something along this line (not exactly this, though), but at 
least some people were trying to do this without making any work for the 
client. But of course that causes incompatibilties; which led to arguments 
about how important the incompatibilities are, and that tends to lead 
nowhere.

> I guess I'm beating a dead hippopotamus here.

Yup.

                             Randy.


  reply	other threads:[~2015-08-07 19:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-04  2:23 Indefinite Containers of Indefinite Private Types Jeffrey R. Carter
2015-08-04  5:40 ` Niklas Holsti
2015-08-04 18:56   ` Jeffrey R. Carter
2015-08-04 20:47     ` Randy Brukardt
2015-08-04 20:56       ` Jeffrey R. Carter
2015-08-06 18:49         ` Randy Brukardt
2015-08-06 20:12           ` Jeffrey R. Carter
2015-08-07 19:49             ` Randy Brukardt [this message]
2015-08-07 20:13     ` Bob Duff
2015-08-07 20:45       ` Jeffrey R. Carter
replies disabled

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