Defaults for formal subprogram

Defaults for formal subprogram

[Maxim Reznik]

Hi all

What clause of ARM does this code violate?

procedure Aaa is

   type Proc_Ptr is access procedure;

   X : Proc_Ptr;

   generic
      with procedure Bbb is X.all;
      -- aaa.adb:8:31: expect valid subprogram name as default
   package Pkg is
   end Pkg;

begin
   null;
end;

Re: Defaults for formal subprogram

[AdaMagica]

> procedure Aaa is
>
>    type Proc_Ptr is access procedure;
>
>    X : Proc_Ptr;
>
>    generic
>       with procedure Bbb is X.all;
>       -- aaa.adb:8:31: expect valid subprogram name as default
>    package Pkg is
>    end Pkg;

AARM 12.6(5.b) The evaluation of the default_name takes place during
the elaboration of each instantiation that uses the default, as
defined in 12.3, “Generic Instantiation”.

So I don't see a problem.

Re: Defaults for formal subprogram

[Ludovic Brenta]

Christoph Grein wrote on comp.lang.ada:
> > procedure Aaa is
>
> >    type Proc_Ptr is access procedure;
>
> >    X : Proc_Ptr;
>
> >    generic
> >       with procedure Bbb is X.all;
> >       -- aaa.adb:8:31: expect valid subprogram name as default
> >    package Pkg is
> >    end Pkg;
>
> AARM 12.6(5.b) The evaluation of the default_name takes place during
> the elaboration of each instantiation that uses the default, as
> defined in 12.3, “Generic Instantiation”.
>
> So I don't see a problem.

I think this violates 12.6(3/2) and 12.6(4):

3/2 subprogram_default ::= default_name | <> | null
4    default_name ::= name

Here, you are trying to use an expression as opposed to a name.

--
Ludovic Brenta.

Re: Defaults for formal subprogram

[Ludovic Brenta]

On Apr 28, 12:53 pm, Ludovic Brenta <ludo...@ludovic-brenta.org>
wrote:
> Christoph Grein wrote on comp.lang.ada:
>
>
>
> > > procedure Aaa is
>
> > >    type Proc_Ptr is access procedure;
>
> > >    X : Proc_Ptr;
>
> > >    generic
> > >       with procedure Bbb is X.all;
> > >       -- aaa.adb:8:31: expect valid subprogram name as default
> > >    package Pkg is
> > >    end Pkg;
>
> > AARM 12.6(5.b) The evaluation of the default_name takes place during
> > the elaboration of each instantiation that uses the default, as
> > defined in 12.3, “Generic Instantiation”.
>
> > So I don't see a problem.
>
> I think this violates 12.6(3/2) and 12.6(4):
>
> 3/2 subprogram_default ::= default_name | <> | null
> 4    default_name ::= name
>
> Here, you are trying to use an expression as opposed to a name.

Ah but looking further I see 4.1(2):

name ::=
     direct_name | explicit_dereference
   | indexed_component | slice
   | selected_component | attribute_reference
   | type_conversion | function_call
   | character_literal

and 4.1(5): explicit_dereference ::= name.all

so your code now seems legal to me. So this is probably a compiler
bug.

--
Ludovic Brenta.

Re: Defaults for formal subprogram

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

"AdaMagica" <christoph.grein@eurocopter.com> wrote in message 
news:9ac3f3db-819c-4232-b580-30a67411dd70@c21g2000yqk.googlegroups.com...
>> procedure Aaa is
>>
>> type Proc_Ptr is access procedure;
>>
>> X : Proc_Ptr;
>>
>> generic
>> with procedure Bbb is X.all;
>> -- aaa.adb:8:31: expect valid subprogram name as default
>> package Pkg is
>> end Pkg;
>
>AARM 12.6(5.b) The evaluation of the default_name takes place during
>the elaboration of each instantiation that uses the default, as
>defined in 12.3, �Generic Instantiation�.
>
>So I don't see a problem.

I agree, I think this is legal as the language is written. I know from 
experience that most compilers have problems with dynamic subprogram names 
showing up in unusual contexts. For instance, the ARG decided to make such 
names illegal for the specification of stream attributes because of the near 
impossibility of writing anything useful with a dynamic name (most compilers 
didn't support it anyway).

But in this case, it seems as if it could be useful, so presumably it is 
just a compiler bug.

                          Randy.