anonymous access type

anonymous access type

[Maciej Sobczak]

Hi,

Consider a simple callback protocol:

   procedure Call (Process : not null access procedure);

This is widely used for example in the containers library (Iterate
operation).

Now, being a good citizen, I would like to explicitly stress that the
parameter is passed 'in' instead of relying on implicit mode, so let's
add the 'in' keyword where it belongs:

   procedure Call (Process : in not null access procedure);

GNAT says: "anonymous access type definition not allowed here".

I cannot find anything in the standard that would explain this. Any
references are welcome.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: anonymous access type

[christoph.grein]

This is definitely a compiler bug. GNAT Pro 6.2.1 accepts this.

Re: anonymous access type

[christoph.grein]

On Mar 3, 1:40 pm, christoph.gr...@eurocopter.com wrote:
> This is definitely a compiler bug. GNAT Pro 6.2.1 accepts this.

Ehem, I wrote nonsense. See RM 6.1(15/2) - the syntax does not allow a
mode.

Re: anonymous access type

[Maciej Sobczak]

On 3 Mar, 13:44, christoph.gr...@eurocopter.com wrote:
> On Mar 3, 1:40 pm, christoph.gr...@eurocopter.com wrote:
>
> > This is definitely a compiler bug. GNAT Pro 6.2.1 accepts this.
>
> Ehem, I wrote nonsense.

No, you have written that this is definitely a compiler bug.

> See RM 6.1(15/2) - the syntax does not allow a
> mode.

Then it really must be a compiler bug that GNAT Pro 6.2.1 accepts
this. ;-)

Thank you for the reference, now I see where this comes from.
BTW - the mode is not needed there, because it cannot be any different
(for example it cannot be 'out', because it would not be possible to
assign anything to it).

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: anonymous access type

[Jean-Pierre Rosen]

Maciej Sobczak a �crit :
> Now, being a good citizen, I would like to explicitly stress that the
> parameter is passed 'in' instead of relying on implicit mode, so let's
> add the 'in' keyword where it belongs:
> 
>    procedure Call (Process : in not null access procedure);
> 
> GNAT says: "anonymous access type definition not allowed here".
> 
> I cannot find anything in the standard that would explain this. Any
> references are welcome.
> 
6.1(15/2): if you have an access definition, you can't specify a mode.

Although it is not syntactically specified this way in the RM, you
should see "access" as a kind of mode in itself. Therefore, it replaces
the "in".

The idea (at least in Ada95) was that you did not pass a pointer, you
passed an object (of the designated type) by reference. Thus, "access"
was really the mode. It is a bit less true in 2005, since null values
are now allowed.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: anonymous access type

[Robert A Duff]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Although it is not syntactically specified this way in the RM, you
> should see "access" as a kind of mode in itself. Therefore, it replaces
> the "in".
>
> The idea (at least in Ada95) was that you did not pass a pointer, you
> passed an object (of the designated type) by reference. Thus, "access"
> was really the mode. It is a bit less true in 2005, since null values
> are now allowed.

FWIW, when Tucker invented access parameters, his first thought was that
this should be a new "mode" -- so a mode could be 'in', 'in out', 'out',
or 'access'.

It didn't turn out that way, but it's not so wrong to think of 'access'
as a parameter passing mode.

- Bob

Re: anonymous access type

[sjw]

On Mar 3, 12:25 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:

> Now, being a good citizen, I would like to explicitly stress that the
> parameter is passed 'in' instead of relying on implicit mode, so let's
> add the 'in' keyword where it belongs:

Personally I find the 'in' keyword annoying and a waste of 3
characters! Rather like initialising an object of an access type with
":= null". Your mileage obviously varies ...

Re: anonymous access type

[Adam Beneschan]

On Mar 3, 1:03 pm, sjw <simon.j.wri...@mac.com> wrote:

> Personally I find the 'in' keyword annoying and a waste of 3
> characters! Rather like initialising an object of an access type with
> ":= null". Your mileage obviously varies ...

My practice has generally been to use the "in" keyword for procedure
parameters (to keep the look consistent with other parameters), but
not for function parameters, since that's the only allowed mode
anyway.  At least, it's the only allowed mode this
month................

                                    -- Adam

Re: anonymous access type

[christoph.grein]

On Mar 3, 11:35 pm, Adam Beneschan <a...@irvine.com> wrote:
> My practice has generally been to use the "in" keyword for procedure
> parameters (to keep the look consistent with other parameters), but
> not for function parameters, since that's the only allowed mode
> anyway.  At least, it's the only allowed mode this
> month................

It has been the only one since 1980 and will probably stay so for the
next 30 or so years if not some earthquake overturns the ARG.

Re: anonymous access type

[Robert A Duff]

christoph.grein@eurocopter.com writes:

> On Mar 3, 11:35�pm, Adam Beneschan <a...@irvine.com> wrote:
>> My practice has generally been to use the "in" keyword for procedure
>> parameters (to keep the look consistent with other parameters), but
>> not for function parameters, since that's the only allowed mode
>> anyway. �At least, it's the only allowed mode this
>> month................
>
> It has been the only one since 1980 and will probably stay so for the
> next 30 or so years if not some earthquake overturns the ARG.

There is an AI about allowing 'in out' and 'out' parameters on
functions.  I think it actually has a good chance of being approved some
time in the next few years.  I am in favor of it, in part because it
allows one to avoid various kludgery involving anonymous access types.

It's AI05-0134.

- Bob

Re: anonymous access type

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcctz69z38a.fsf@shell01.TheWorld.com...
> christoph.grein@eurocopter.com writes:
...
>> It has been the only one since 1980 and will probably stay so for the
>> next 30 or so years if not some earthquake overturns the ARG.
>
> There is an AI about allowing 'in out' and 'out' parameters on
> functions.  I think it actually has a good chance of being approved some
> time in the next few years.  I am in favor of it, in part because it
> allows one to avoid various kludgery involving anonymous access types.
>
> It's AI05-0134.

You mean AI05-0143-1. People will otherwise be confused.

And I agree about the chances of being approved. We have the opposition down 
to a single issue...

                          Randy.

Re: anonymous access type

[christoph.grein]

Out coding standard requires always "in".

I personally (when not obliged otherwise by the coding standard) use
"in" only for procedures. If "[in] out" will be allowed for functions,
I'll perhaps change my attitude.

Re: anonymous access type

[Hibou57 (Yannick Duchêne)]

On 5 mar, 09:52, christoph.gr...@eurocopter.com wrote:
> Out coding standard requires always "in".
Yes.

> If "[in] out" will be allowed for functions,
> I'll perhaps change my attitude.

Don't wake up the devil please (LOL)

Re: anonymous access type

[Maciej Sobczak]

On 3 Mar, 22:03, sjw <simon.j.wri...@mac.com> wrote:

> Personally I find the 'in' keyword annoying and a waste of 3
> characters!

Then you might find the C language to be a perfect time-saver!

;-) ;-) ;-)

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: anonymous access type

[Robert A Duff]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> Consider a simple callback protocol:
>
>    procedure Call (Process : not null access procedure);
>
> This is widely used for example in the containers library (Iterate
> operation).

Yes, but I don't call that a callback.  To me, a "callback" is when you
pass a global subprogram, and it's saved in a global data structure,
to be "called back" later.  For example, when you say "Please call
so-and-so procedure when in the future somebody clicks the mouse on the 
"OK" button".  For this, you need a named access type.

I call your example a "downward closure", where Call calls Process some
number of times, and then Call exits, and then Process is never heard
from again.  For this, you need an anonymous access type.

> Now, being a good citizen, I would like to explicitly stress that the
> parameter is passed 'in' instead of relying on implicit mode, so let's
> add the 'in' keyword where it belongs:
>
>    procedure Call (Process : in not null access procedure);

I disagree that "being a good citizen" means "making things explicit".
You should make dangerous or unusual things explicit (like "out"
params).  "in" params are usual and safe, so should be implicit.

It's really a (minor) language design flaw that "in" is allowed but
not required.  It should be either required or forbidden.  (I would
prefer forbidden.)  As it is, the Ada language has split into three
dialects: always say 'in', never say 'in', and say 'in' only for
procedures.  That's unfortunate.

> GNAT says: "anonymous access type definition not allowed here".

GNAT is obeying the syntax rules, here.

> I cannot find anything in the standard that would explain this. Any
> references are welcome.

It's in the syntax rules in RM-6.1:

15/2  {AI95-00231-01} parameter_specification ::= 
          defining_identifier_list : mode [null_exclusion] subtype_mark
       [:= default_expression]
        | defining_identifier_list : access_definition
       [:= default_expression]

16    mode ::= [in] | in out | out

The "access_definition" case doesn't allow a mode (because it's always
'in').  I'd actually like to change that, by the way, but it's not
easy.

- Bob

Re: anonymous access type

[Ludovic Brenta]

Robert A Duff wrote on comp.lang.ada:
> As it is, the Ada language has split into three
> dialects: always say 'in', never say 'in', and say 'in' only for
> procedures.  That's unfortunate.

I'm one of the Knights Who Say "in" :)

sorry, couldn't resist

--
Ludovic Brenta.

Re: anonymous access type

[Rob Norris]

On Thu, 5 Mar 2009 00:14:53 -0800 (PST), Ludovic Brenta <ludovic@ludovic-brenta.org> wrote:

>Robert A Duff wrote on comp.lang.ada:
>> As it is, the Ada language has split into three
>> dialects: always say 'in', never say 'in', and say 'in' only for
>> procedures. �That's unfortunate.
>
>I'm one of the Knights Who Say "in" :)
>
>sorry, couldn't resist

Me 2.

However the only reason I normally put them in is due to the colour highlighting mode of whatever
(old) version of Ada-Mode we use with Emacs, which doesn't colour the parameter type correctly if
the 'in' is not in.

Re: anonymous access type

[Hibou57 (Yannick Duchêne)]

On 5 mar, 17:27, Rob Norris <firstname.lastn...@baesystems.com> wrote:
> Me 2.
>
> However the only reason I normally put them in is due to the colour highlighting mode of whatever
> (old) version of Ada-Mode we use with Emacs, which doesn't colour the parameter type correctly if
> the 'in' is not in.

Who is “we” ? (hope I did not seem too much intrutive with this
question)

Re: anonymous access type

[Rob Norris]

On Thu, 5 Mar 2009 09:51:53 -0800 (PST), Hibou57 (Yannick Duch�ne) <yannick_duchene@yahoo.fr> wrote:

>On 5 mar, 17:27, Rob Norris <firstname.lastn...@baesystems.com> wrote:
>> Me 2.
>>
>> However the only reason I normally put them in is due to the colour highlighting mode of whatever
>> (old) version of Ada-Mode we use with Emacs, which doesn't colour the parameter type correctly if
>> the 'in' is not in.
>
>Who is �we� ? (hope I did not seem too much intrutive with this
>question)

Just an small internal subset of BAE SYTEMS software engineering - but not representive of the
company as a whole.

Re: anonymous access type

[sjw]

On Mar 5, 4:27 pm, Rob Norris <firstname.lastn...@baesystems.com>
wrote:

> However the only reason I normally put them in is
> due to the colour highlighting mode of whatever (old)
> version of Ada-Mode we use with Emacs, which doesn't
> colour the parameter type correctly if the 'in' is not
> in.

Hmm, I'd noticed an inconsistency, but not traced it to that
particular aspect.

The latest ada-mode does this still.

Re: anonymous access type

[Stephen Leake]

sjw <simon.j.wright@mac.com> writes:

> On Mar 5, 4:27 pm, Rob Norris <firstname.lastn...@baesystems.com>
> wrote:
>
>> However the only reason I normally put them in is
>> due to the colour highlighting mode of whatever (old)
>> version of Ada-Mode we use with Emacs, which doesn't
>> colour the parameter type correctly if the 'in' is not
>> in.
>
> Hmm, I'd noticed an inconsistency, but not traced it to that
> particular aspect.
>
> The latest ada-mode does this still.

Obviously, we (the ada-mode implementers) were anticipating (eagerly)
the day when functions would have 'in out' :)

-- 
-- Stephe

Re: anonymous access type

[Hibou57 (Yannick Duchêne)]

On 5 mar, 00:54, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
> It's really a (minor) language design flaw that "in" is allowed but
> not required.  It should be either required or forbidden.  (I would
> prefer forbidden.)  As it is, the Ada language has split into three
> dialects: always say 'in', never say 'in', and say 'in' only for
> procedures.  That's unfortunate.
>
> - Bob
If it ever becomes forbidden, this would brake too much application
sources around the world. There is no chancge it would occurs.

Then, as long as "in out" makes sens beside of "out", then "in" do as
well (would seems strange if there was "in out", "out" and no "in").

As the latter one, I'm of the ones who prefer to always write "in".

Re: anonymous access type

[Robert A Duff]

"Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes:

> On 5 mar, 00:54, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>>
>> It's really a (minor) language design flaw that "in" is allowed but
>> not required. �It should be either required or forbidden. �(I would
>> prefer forbidden.) �As it is, the Ada language has split into three
>> dialects: always say 'in', never say 'in', and say 'in' only for
>> procedures. �That's unfortunate.
>>
>> - Bob
> If it ever becomes forbidden, this would brake too much application
> sources around the world. There is no chancge it would occurs.

Right.  It should have been either required or forbidden in 1983,
but it's way too late to fix that now.

> Then, as long as "in out" makes sens beside of "out", then "in" do as
> well (would seems strange if there was "in out", "out" and no "in").

Do you find it strange that we don't have:

    X : constant Integer := 123;
    Y : variable Integer := 456; -- Not Ada!

?

> As the latter one, I'm of the ones who prefer to always write "in".

- Bob

Re: anonymous access type

[Dmitry A. Kazakov]

On Thu, 05 Mar 2009 10:05:01 -0500, Robert A Duff wrote:

> "Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes:
> 
>> Then, as long as "in out" makes sens beside of "out", then "in" do as
>> well (would seems strange if there was "in out", "out" and no "in").
> 
> Do you find it strange that we don't have:
> 
>     X : constant Integer := 123;
>     Y : variable Integer := 456; -- Not Ada!
> 
Strange is that it is not

                   --  Everything is not Ada!
   X : in Integer := 123;
   Y : in out Integer := 456;
   Z : out Integer; -- I can leave it uninitialized for a while

in = immutable, requires explicit initialization [unless controlled?]
in out = mutable, requires explicit initialization ...
out = mutable, no explicit initialization required

BTW, it is not to late to introduce this, since it would be compatible to
the present stuff:

   A : T ... <=>  A : out T  + warning
   B : constant T ...  <=>  B : in T ...  + warning

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: anonymous access type

[Hibou57 (Yannick Duchêne)]

On 5 mar, 16:05, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> Do you find it strange that we don't have:
>
>     X : constant Integer := 123;
>     Y : variable Integer := 456; -- Not Ada!
>
> ?
> - Bob

Well done, you've got a clever point indeed.

Perhaps the reason why I did not miss is beceause it does not belong
to the same side. When I see in/out on parameters, I see it from the
external user point of view (e.g. I'm looking at it as a user who
would like make a reference to it), while when I see your exemple, I
see it from the inner point of view (e.g. I'm inside a procedure/
function).

You know what ? I oftenly miss something else : beside of the
formal_parameter_selector_name [ARM2005 6.4/5], I would enjoy in/out
hints at the call statement, just to make invokation instances more
clear when a procedure can modifiy its parameters. It it not always
easy to state it in the procedure's name or in the parameter's name.

But perhaps I'm a bit mad (may be the "explicit" concept is becoming a
kind of hard drug)

Re: anonymous access type

[Adam Beneschan]

On Mar 5, 9:50 am, Hibou57 (Yannick Duchêne)
<yannick_duch...@yahoo.fr> wrote:
> On 5 mar, 16:05, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
> > Do you find it strange that we don't have:
>
> >     X : constant Integer := 123;
> >     Y : variable Integer := 456; -- Not Ada!
>
> > ?
> > - Bob
>
> Well done, you've got a clever point indeed.
>
> Perhaps the reason why I did not miss is beceause it does not belong
> to the same side. When I see in/out on parameters, I see it from the
> external user point of view (e.g. I'm looking at it as a user who
> would like make a reference to it), while when I see your exemple, I
> see it from the inner point of view (e.g. I'm inside a procedure/
> function).
>
> You know what ? I oftenly miss something else : beside of the
> formal_parameter_selector_name [ARM2005 6.4/5], I would enjoy in/out
> hints at the call statement, just to make invokation instances more
> clear when a procedure can modifiy its parameters. It it not always
> easy to state it in the procedure's name or in the parameter's name.
>
> But perhaps I'm a bit mad (may be the "explicit" concept is becoming a
> kind of hard drug)

I think Ada 79 or some earlier proposal had that.  For named parameter
associations, instead of the => syntax we've gotten used to:

   Proc (Param => Expression);

the syntax was

   Proc (Param := Expression);

for IN parameters;

   Proc (Param =: Variable);

for OUT parameters, and

   Proc (Param :=: Variable);

for IN OUT parameters.  At least that's what I recall from way back
when.  I suppose the language could still allow

   Proc (Param <=> Variable)

for IN OUT, but of course <= has another use now so we couldn't use
that...

And I think that in Ada 79, this was only possible for named
associations, not positional ones.

I don't think your idea is a bad one, though, to allow (but not
require) IN|OUT|IN OUT keywords in front of actual parameters (named
or positional).  The implementation effort for compiler maintainers
would be small, I believe.

                              -- Adam

Re: anonymous access type

[Hibou57 (Yannick Duchêne)]

On 5 mar, 19:35, Adam Beneschan <a...@irvine.com> wrote:
> I think Ada 79 or some earlier proposal had that.  For named parameter
> associations, instead of the => syntax we've gotten used to:
>
>    Proc (Param => Expression);
>
> the syntax was
>
>    Proc (Param := Expression);
>
> for IN parameters;
>
>    Proc (Param =: Variable);
>
> for OUT parameters, and
>
>    Proc (Param :=: Variable);
>
> for IN OUT parameters.  At least that's what I recall from way back
> when.  I suppose the language could still allow
>
>    Proc (Param <=> Variable)
>
> for IN OUT, but of course <= has another use now so we couldn't use
> that...
>
> And I think that in Ada 79, this was only possible for named
> associations, not positional ones.
>
> I don't think your idea is a bad one, though, to allow (but not
> require) IN|OUT|IN OUT keywords in front of actual parameters (named
> or positional).  The implementation effort for compiler maintainers
> would be small, I believe.
>
>                               -- Adam

I think I would prefer the in/out rather than the :/=/:, while this
latter is clever as well
Is it possible to transmit it as a proposal ?
Where can I do it ?

Have a nice night

Re: anonymous access type

[Adam Beneschan]

On Mar 5, 4:52 pm, Hibou57 (Yannick Duchêne)
<yannick_duch...@yahoo.fr> wrote:
> On 5 mar, 19:35, Adam Beneschan <a...@irvine.com> wrote:
>
>
>
> > I think Ada 79 or some earlier proposal had that.  For named parameter
> > associations, instead of the => syntax we've gotten used to:
>
> >    Proc (Param => Expression);
>
> > the syntax was
>
> >    Proc (Param := Expression);
>
> > for IN parameters;
>
> >    Proc (Param =: Variable);
>
> > for OUT parameters, and
>
> >    Proc (Param :=: Variable);
>
> > for IN OUT parameters.  At least that's what I recall from way back
> > when.  I suppose the language could still allow
>
> >    Proc (Param <=> Variable)
>
> > for IN OUT, but of course <= has another use now so we couldn't use
> > that...
>
> > And I think that in Ada 79, this was only possible for named
> > associations, not positional ones.
>
> > I don't think your idea is a bad one, though, to allow (but not
> > require) IN|OUT|IN OUT keywords in front of actual parameters (named
> > or positional).  The implementation effort for compiler maintainers
> > would be small, I believe.
>
> >                               -- Adam
>
> I think I would prefer the in/out rather than the :/=/:, while this
> latter is clever as well
> Is it possible to transmit it as a proposal ?
> Where can I do it ?

Actually, I sent a proposal to Ada-Comment after I posted, and there's
been some discussion.  I didn't realize that Randy had already brought
up the idea recently in the context of a different issue (AI05-0144),
which arose because OUT and IN OUT parameters for functions are being
seriously discussed; that proposed feature means there's even more
need for a syntax like you mentioned, at least in my opinion (not
everybody agrees).  For future reference, look at
http://www.adaic.com/standards/articles/comment.html

                                -- Adam