Basic questions about wordings in “Interfacing Pragmas”

Basic questions about wordings in “Interfacing Pragmas”

[Yannick Duchêne (Hibou57)]

Hi people there,

Some basic questions about some part of annexe B.1, Interfacing Pragmas.

> 9.1/1 For pragmas Import and Export, the argument for Link_Name shallnot  
> be given without the pragma_argument_identifier unlessthe argument for  
> External_Name is given.
What is that pragma_argument_identifier ? The Convention ?

In legality rules
> 18 T is an access-to-subprogram type, and its designated profile's
> parameter and result types are all L-compatible.
Why no similar wording for imported subprograms ? Was just forget or is  
this missing on purpose ? (or I missed it?)

In notes at the bottom
> 46 5  The local_name in an interfacing pragma can denote more
> than one entity in the case of overloading. Such a pragma
> applies to all of the denoted entities.
Why not the same with types derived from a type with an interfacing pragma  
?

Finally, what I was checking the RM for (related to the above), Static  
Semantics
> 30 An interfacing pragma defines the convention of the entity denoted by 
> the local_name.
So except if the type is tagged (as stated above), the convention is lost  
for any derived type of subtypes (as all are not anymore denoted by the  
same name the pragma was referring to) ?.

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]

Re: Basic questions about wordings in “Interfacing Pragmas”

[Yannick Duchêne (Hibou57)]

Le Tue, 22 Nov 2011 19:15:19 +0100, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> lost for any derived type of subtypes
Please, read “for any derived type *or* subtypes”.


-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit

Re: Basic questions about wordings in “Interfacing Pragmas”

[AdaMagica]

On 22 Nov., 19:15, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> > 9.1/1 For pragmas Import and Export, the argument for Link_Name shallnot
> > be given without the pragma_argument_identifier unlessthe argument for
> > External_Name is given.
>
> What is that pragma_argument_identifier ? The Convention ?

pragma Pragma_Name (pragma_argument_identifier => Value, ...);

The pragma_argument_identifier is the formal name of the argument. It
cannot be
omitted for Link_Name when External_Name is omitted because this is
the last argument.

> In legality rules> 18 T is an access-to-subprogram type, and its designated profile's
> > parameter and result types are all L-compatible.
>
> Why no similar wording for imported subprograms ? Was just forget or is
> this missing on purpose ? (or I missed it?)

Don't understand. This is a rule for a type T and not for subprograms.

Re: Basic questions about wordings in “Interfacing Pragmas”

[Adam Beneschan]

On Nov 22, 10:15 am, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Hi people there,
>
> Some basic questions about some part of annexe B.1, Interfacing Pragmas.
>
> > 9.1/1 For pragmas Import and Export, the argument for Link_Name shallnot
> > be given without the pragma_argument_identifier unlessthe argument for
> > External_Name is given.
>
> What is that pragma_argument_identifier ? The Convention ?

As Christoph explained, the pragma_argument_identifier is either
External_Name or Link_Name.  The reason for this rule is simply that
the rule in B.1(5) (to be moved to Annex J) makes both the
External_Name and the Link_Name optional, the way the syntax rule is
written.  But if you said

   pragma Import (C, My_Proc, "your_proc");

Without any rule, there wouldn't be any way for the compiler to tell
whether "your_proc" is an External_Name or a Link_Name just from the
syntax rule.  So the rule was added that the string in the above is
always an External_Name, and if you want a Link_Name without an
External_Name you have to say

   pragma Import (C, My_Proc, Link_Name => "your_proc");

It's a lot simpler than the rule seems to make it appear.


> In legality rules> 18 T is an access-to-subprogram type, and its designated profile's
> > parameter and result types are all L-compatible.
>
> Why no similar wording for imported subprograms ? Was just forget or is
> this missing on purpose ? (or I missed it?)

This is part of the definition that starts at B.1(12): "If L is a
convention_identifier for a language, then a type T is said to be
compatible with convention L ... if ..."  Since this is talking about
a property of a type T, it wouldn't make sense to talk about imported
subprograms here.  B.1(26) gives the relevant rule about imported
subprograms.

>
> In notes at the bottom> 46 5  The local_name in an interfacing pragma can denote more
> > than one entity in the case of overloading. Such a pragma
> > applies to all of the denoted entities.
>
> Why not the same with types derived from a type with an interfacing pragma
> ?

Types can't be overloaded.  Since you can declare more than one
subprogram with the same name, the purpose of this note is to describe
what happens if you use that name in one of these pragmas, in that
case.  There's no need for a similar rule about types.


> Finally, what I was checking the RM for (related to the above), Static
> Semantics> 30 An interfacing pragma defines the convention of the entity denoted by
> > the local_name.
>
> So except if the type is tagged (as stated above), the convention is lost
> for any derived type [or] subtypes (as all are not anymore denoted by the
> same name the pragma was referring to) ?.

You may be confused about how subtypes and types work.  A "subtype" is
not a new type.  If you have a type T and a subtype S, and you declare
a variable "V : S", then V has subtype S *and* type T.  Similarly, if
you use S as a parameter

    procedure Proc (Param : in S);

then the parameter has *type* T as well has having *subtype* S.  So
when a rule like B.1(26) is applied to this procedure, and B.1(26)
speaks of parameter types, the type of this parameter is T, not S.

As for derived types: 13.1(15.3) says that representation information
is inherited for derived types, and these pragmas are representation
pragmas.  So no, the convention is not lost (as long as the pragma
comes before the derived type declaration).

                       -- Adam

Re: Basic questions about wordings in “Interfacing Pragmas”

[Yannick Duchêne (Hibou57)]

Le Tue, 22 Nov 2011 20:10:01 +0100, AdaMagica  
<christ-usch.grein@t-online.de> a écrit:

> On 22 Nov., 19:15, Yannick Duchêne (Hibou57)
> <yannick_duch...@yahoo.fr> wrote:
>> > 9.1/1 For pragmas Import and Export, the argument for Link_Name  
>> shallnot
>> > be given without the pragma_argument_identifier unlessthe argument for
>> > External_Name is given.
>>
>> What is that pragma_argument_identifier ? The Convention ?
>
> pragma Pragma_Name (pragma_argument_identifier => Value, ...);
OK, it refers to 2.8. Still feel the wording could be more readable here.

>> Why no similar wording for imported subprograms ? Was just forget or is
>> this missing on purpose ? (or I missed it?)
>
> Don't understand. This is a rule for a type T and not for subprograms.
It's not about type, its about signature: imported subprogram has a  
convention too, and it should have the same legality requirement as access  
to subprogram has on the signature.

Later after a silly error in a text, I get a compiler warning about an  
imported C function returning… a whole tagged type record (oops). I wish I  
did not get a warning, but an error instead. It seems access to subprogram  
with a Convention have this requirement, I would expect the same for a  
imported subprogram with the same Convention too.

That's why I had a feeling something is missing.

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]

Re: Basic questions about wordings in “Interfacing Pragmas”

[Yannick Duchêne (Hibou57)]

Le Tue, 22 Nov 2011 21:07:53 +0100, Adam Beneschan <adam@irvine.com> a  
écrit:
>> In notes at the bottom> 46 5  The local_name in an interfacing pragma  
>> can denote more
>> > than one entity in the case of overloading. Such a pragma
>> > applies to all of the denoted entities.
>>
>> Why not the same with types derived from a type with an interfacing  
>> pragma
>> ?
>
> Types can't be overloaded.  Since you can declare more than one
> subprogram with the same name, the purpose of this note is to describe
> what happens if you use that name in one of these pragmas, in that
> case.  There's no need for a similar rule about types.

Oops, I was misunderstood here.

Say T11 is tagged type. A pragma specify some convention for T11.  
According to this RM page, then a type T12 extending (or not) T11, will  
hold the same convention too.

Say T21 is a “classic” scalar type. A pragma specify some convention for  
T21. According to this RM page, then a `type T22 is new T21;` will not  
hold the same convention, because it is not denoted by the same same any  
more, and it is not tagged.

I am not feeling fine with this: T12 will keep the convention, while T22  
won't. T22 should too.

Similarly: formally (no compiler specific answer please), what about  
`subtype T23 is T21;`. Not denoted by the same name too, so too not  
warranted to still hold the convention specified for T21 ? If so, this is  
another reason for me to not feeling OK.

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]

Re: Basic questions about wordings in “Interfacing Pragmas”

[Adam Beneschan]

On Nov 22, 8:39 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Tue, 22 Nov 2011 21:07:53 +0100, Adam Beneschan <a...@irvine.com> a
> écrit:
>
> >> In notes at the bottom> 46 5  The local_name in an interfacing pragma
> >> can denote more
> >> > than one entity in the case of overloading. Such a pragma
> >> > applies to all of the denoted entities.
>
> >> Why not the same with types derived from a type with an interfacing
> >> pragma
> >> ?
>
> > Types can't be overloaded.  Since you can declare more than one
> > subprogram with the same name, the purpose of this note is to describe
> > what happens if you use that name in one of these pragmas, in that
> > case.  There's no need for a similar rule about types.
>
> Oops, I was misunderstood here.
>
> Say T11 is tagged type. A pragma specify some convention for T11.
> According to this RM page, then a type T12 extending (or not) T11, will
> hold the same convention too.
>
> Say T21 is a “classic” scalar type. A pragma specify some convention for
> T21. According to this RM page, then a `type T22 is new T21;` will not
> hold the same convention, because it is not denoted by the same same any
> more, and it is not tagged.
>
> I am not feeling fine with this: T12 will keep the convention, while T22
> won't. T22 should too.

Now I'm really confused.  First of all, I already pointed you to the
section that says that T22 *will* keep the convention applied to T21.
Second, I've looked through B.1 twice and can't find any language in
there that applies to tagged types differently from untagged types.
What part of this section made you think that there was a difference?


> Similarly: formally (no compiler specific answer please), what about
> `subtype T23 is T21;`. Not denoted by the same name too, so too not
> warranted to still hold the convention specified for T21 ? If so, this is
> another reason for me to not feeling OK.

Please go back and reread what I wrote about subtypes.  T23 and T21
are the same ***type***.  Whatever Convention pragma applies to T21
also applies to T23 because it's the same type.

                        -- Adam