Re: Limited with too restrictive?

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

"Blady" <p.p11@orange.fr> wrote in message 
news:unucno$89u$1@dont-email.me...
> Hello,
>
> I want to break some unit circularity definitions with access types as for 
> instance with record:
>
>    type R1;
>    type AR1 is access R1;
>    type R1 is record
>       Data : Natural;
>       Next : AR1;
>    end record;
>
> In my case, I have a unit:
>
> package test_20240113_modr is
>    type R2 is record
>       Data : Natural;
>    end record;
>    type AR2 is access R2;
> end test_20240113_modr;
>
> "limited withed" in:
>
> limited with test_20240113_modr;
> package test_20240113_mods is
> procedure PS1 (V : test_20240113_modr.R2);
> procedure PS2 (V : test_20240113_modr.AR2);
> end;
>
> Let's imagine the circularity, thus PS1 and PS2 definition are legal.
>
> Of course the following isn't legal:
>
> type AS1 is array (1..2) of test_20240113_modr.R2; -- illegal
>
> However why not with access type:
>
> type AS2 is array (1..2) of test_20240113_modr.AR2; -- illegal

For a limited with, one only knows the syntactic declarations (we cannot 
assume any analysis). Therefore, we cannot know the representation of any 
type, including access types.

Specifically, compilers may support multiple representations for access 
types, for a variety of reasons (the underlying machine has different 
representations, as on the 8086 and U2200 that we did compilers for; because 
additional data needs to be carried along to implement Ada semantics - GNAT 
did that for access to unconstrained arrays, and so on). The representation 
can depend upon aspect specifications, the designated subtype, and more, 
none of which is known at the point of a limited with.

We couldn't restrict implementations to a single representation for access 
types, and thus limited with has to treat them the same as other types.

It's necessary to declare local access types for entities that are accessed 
from a limited view. The reason that anonymous access types were expanded 
was to make that less clunky -- but I don't think it succeeded.

...
> Well, I could make some code transferts from unit to another or access 
> conversions, that's I actually do but at heavy cost.

Yup, but the alternative is worse - requiring all access types to be the 
most general representation (which can have a heavy performance cost).

                 Randy.