Limited with too restrictive?

[Blady]

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

Likewise, why not:

type AS3 is record
Data : Natural;
Next : test_20240113_modr.AR2; -- illegal
end record;

Isn't "limited with" too restrictive, is it?

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

Thanks, Pascal.

[Randy Brukardt]

"Blady" <p....@orange.fr> wrote in message
news:unucno$89u$1...@dont-email.me...

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.