Re: Intervention needed?

["Randy Brukardt" <randy@rrsoftware.com>]

The classic (and rare) example of a limited type is one containing a task. 
For those, you do need to control initialization. You also need to do so if 
the type has any discriminants.

I suppose it would be possible to do in a sense by defining *exactly* what 
every operation must do (essentially by providing the body) -- but then 
there is no reason to standardize it, because there is no value to be added 
by an implementer. (Anyone can download a library from github or whatever 
and compile with with whatever compiler you want.)

This is the same sort of reason it doesn't make much sense to allow 
user-defined storage pools in a container -- you would have to precisely 
define what allocators are going to do (in terms of allocation sizes, 
ordering,  and the like) so that a pool could take advantage of that. But 
then there's really nothing for the implementation to do - the package is so 
heavily specified that there is no freedom to improve the implementation.

                   Randy.

"Jere" <jhb.chat@gmail.com> wrote in message 
news:0e27ab0a-5daa-45b0-ae5c-a2441fb1ad40@googlegroups.com...
> On Thursday, March 21, 2019 at 10:00:41 PM UTC-4, Randy Brukardt wrote:
>> "Jere" wrote in message
>> ...
>> > You would think that a container of limited types would be very
>> > restrictive,
>> > but with the advent of Implicit_Dereference and reference types, there
>> > is definitely some meat there.  I would say maps and lists are the two
>> > areas I find the most need.
>>
>> A container of a limited type would be very restrictive. ;-)
>>
>> Several of us (including me) have tried to imagine how a container of
>> limited objects would work, but it just doesn't make much sense. The 
>> primary
>> problem is that one cannot control the lifetime of objects in a 
>> container,
>> which includes the problem that one can't control the initialization of
>> objects in a container. Whereas for non-limited objects, one just 
>> replaces
>> them with the right data, you can't do that for a limited object. And 
>> since
>> the initialization needs are type-dependent, there's no good way to deal
>> with it in a type-safe manner. (A constructor with an unknown set of
>> parameters isn't going to be type-safe, and with any particular set of
>> parameters is too limiting.
>>
>
> Yes constructors pose a problem.  The way I work around it is similar to
> how Generic_Dispatching_Constructors does.  I let them define a parameter
> which could be a record of parameters.
>
> That said, it usually doesn't matter for limited types. When I have had to
> make and use containers of limited types, I am in one of two places:
>
> 1.  The limited type was only made limited because of a component or two
> so the designer created a copy procedure.  This lets me mostly treat
> limited types the same as non limited types.  I've literally taken a GNAT
> container, added a copy procedure formal to the generic, and integrated
> it into the business logic whereever the compiler told me it couldn't
> copy a limited type.  So far that has worked flawlessly, but I don't
> know if the customer has tried all of the various functions in the
> containers.  This is the less likely case however.
>
> 2.  I don't worry about integrating initialization.  I just have the
> container create a default object, and then I can use the combination
> of cursors and references (or simply a "for of" loop) and initialize
> them after adding them.  So yes, definitely more restrictive than
> a non limited type container.  I just meant the restrictions were
> not as insurmountable as I have seen in discussions before.  This
> is the more often case.  This doesn't 100% cover all remaining cases
> (like ones where you have to initialize the object at creation),
> but it has been the remaining 95% solution and very effective.  In
> one case I created a package with the same operations as the customer's
> but implemented the logic as an Ordered_Map of limited types instead
> of the array logic they were using, and it increased their through
> put by 3x (they did a lot of manual searching).  It also happened
> to get a couple of their own programmers to rethink on how they
> perceived Ada to be an "old" language (very pervasive thought
> where I work).  They had no idea that you could even make iterators
> in Ada.  A couple didn't even know you could do dynamic dispatching
> as they started in Ada83 and never grew past that.