subprogram must not be deeper than access type

subprogram must not be deeper than access type

[Natasha Kerensikova]

Hello,

I'm encountering the error in the subject, "subprogram must not be
deeper than access type", and while I understand what it means in
general and the rationale, I'm lost on why it applies to my code and how
to work around it.

However, instead of just copying code, I will first explain the problem
I'm trying to solve, maybe there is a better a way to deal with it
"upstream" from the error. Still, I would love to understand how the
error applies to this case, for my personal Ada edification.


So the general context is that I'm in the last stages of teaching myself
Ada, and at this point I though it would be a good idea to reimplement
something I wrote in C, with a few improvements on the design coming
from the experience. The rationale was to spend little time on the
"software design" part, so that I can focus on learning to write correct
Ada.

In the C project the performance bottleneck was the time spent to append
relatively short strings to an ever-growing buffer, and I was hoping
that with a design so close, the Ada project would encounter the same
problem. So I decided to create a String_Accumulator interface, which
basically contains Append, To_String, Reset and a few other upkeep
subprograms, and I started writing the project using
String_Accumulator'Class. Another rationale for this approach (although
it came after the fact) is that it makes it easy to enforce bounds on
the amount of intermediate memory used when dealing with untrusted
input.

Then at some point I realized it would make the project clearer if I
also had a String_Accumulator_Stack interface, with Push and Pop extra
procedures, and apply other operations to the topmost element.

Then I wanted to try all this for real, and for that I needed classes
that implement the interfaces. So I wrote something straightforward for
String_Accumulator, based on Unbounded_String. String_Accumulator_Stack
was based on Indefinite_Doubly_Linked_Lists of String_Accumulator'Class
and less straightforward to write (there was a lot of nested subprograms
and Update_Element). I only lacked something to create the
String_Accumulator'Class objects when the stack grows.

To keep the stack flexible (because different stack level might have
different usage pattern) I decided to use a callback:

type Accumulator_Builder is not null
   access function (Depth : Positive) return String_Accumulator'Class;

Then the simplest way I imagined to make it accessible without revealing
the internals was:

type String_Accumulator_Linked_List (Builder : Accumulator_Builder)
   is new String_Accumulator_Stack with private;

Everything compiled, so I thought it was fine.

Things started to go wrong only when I tried to create an object of such
type... It looks like that:

procedure Main is
   function Builder (Depth : Positive)
      return String_Accumulator'Class
   is
      pragma Unrefenced (Depth);
   begin
      return Unbounded_String_Accumulator.Empty_Accumulator;
   end Builder;

   Output : String_Accumulator_Linked_List (Builder'Access);
begin
   null;  --  or actually, real code.
end Main;

And GNAT refused to compile it, because "subprogram must not be deeper
than access type".

So I imagined that since Builder and Output have the same lifetime, it
might not be so well-define which will cease to exist first. So while
not strictly deeper, being as deep can be a problem.

procedure Main is
   function Builder -- exactly the same as before
begin
   declare
      Output : String_Accumulator_Linked_List (Buidler'Access);
   begin
      null;  --  or actually real code
   end;
end Main;

Unless I'm missing something, Output lifetime is not guaranteed to be
longer than that of Builder. But GNAT still refuses it compile it, still
with "subprogram must not be deeper than access type".

So I guessed that the discriminant being part of the type, I'm
effectively creating a type that rely on Builder existence, and maybe
the type has a lifetime unrelated to the lifetime of objects of that
type.

So instead I changed the linked list type:

type SALL_Internal is private;
type String_Accumulator_Linked_List is new String_Accumulator_Stack
   with record
      Builder : Accumulator_Builder;
      Internal : SALL_Internal;
   end record;

along with the following declaration in Main:
   Output : String_Accumulator_Linked_List (Builder => Builder'Access,
                                            others => <>);

I tried both with and without the extra declare block, and GNAT still
rejects both with "subprogram must not be deeper than access type".

So then I tried putting the Builder function in the
Unbounded_String_Accumulator package, but all above 4 possibilities were
still rejected by GNAT the same way.

So then I got so horribly lost and desperate about the error that I
dared post here.


Would you have any idea of what is going there or what I am doing wrong?
Or should I try to craft a smaller test case and post it?


Thanks in advance for your help,
Natasha

Re: subprogram must not be deeper than access type

[Oliver Kleinke]

Hi,

I am unsure but you might want to try it using an anonymous access to
subprogram type, as described here
('05 Rationale, 3.4 - Downward Closures)
http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-3-4.html

Kind regards,

Oliver

Re: subprogram must not be deeper than access type

[Natasha Kerensikova]

Hello,

On 2011-09-25, Oliver Kleinke <oliver.kleinke@c-01a.de> wrote:
> I am unsure but you might want to try it using an anonymous access to
> subprogram type, as described here
> ('05 Rationale, 3.4 - Downward Closures)
> http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-3-4.html

Yes, anonymous access solved my problem, thanks a lot for the pointer.

And also, thanks a lot for making me read the rationale. While I did
know it existed, I thought it was on the same level of understandability
as the Reference Manual, so it didn't occur to me to check it out. But
now that I have discovered it, I have read several chapter and learnt a
great deal about Ada \o/

Natasha

Re: subprogram must not be deeper than access type

[Yannick Duchêne (Hibou57)]

Le Sun, 25 Sep 2011 16:04:42 +0200, Oliver Kleinke  
<oliver.kleinke@c-01a.de> a écrit:

> Hi,
>
> I am unsure but you might want to try it using an anonymous access to
> subprogram type, as described here
> ('05 Rationale, 3.4 - Downward Closures)
> http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-3-4.html

There are things I did not understand.

> Ada 2005 overcomes the problem by introducing anonymous access to
> subprogram types. This was actually considered during the design of
> Ada 95 but it was not done at the time for two main reasons. Firstly,
> the implementation problems for those who were using display vectors
> rather than static links were considered a hurdle.

Display vectors ?

There is another reference below

> that model does not work especially for display based implementations

What is that display ?

May be a matter of taste now

> And secondly, a crafty technique was available using the newly
> introduced tagged types. And of course one could continue to use
> generics. But further thought showed that the implementation burden
> was not so great provided the uses were kept simple — and anyway
> nobody understood the tagged type technique which was reallyincredibly  
> contorted.

I do prefer tagged types over access to subprogram, because I feel it is  
cleaner and more design evolution friendly (you may had anything useful to  
the tagged object, one of the most interesting, is a state). What is  
contorted with tagged types here ? Why did he say nobody understood this  
technique ?


-- 
“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: subprogram must not be deeper than access type

[Adam Beneschan]

On Oct 3, 4:30 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Sun, 25 Sep 2011 16:04:42 +0200, Oliver Kleinke  
> <oliver.klei...@c-01a.de> a écrit:
>
> > Hi,
>
> > I am unsure but you might want to try it using an anonymous access to
> > subprogram type, as described here
> > ('05 Rationale, 3.4 - Downward Closures)
> >http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-3...
>
> There are things I did not understand.
>
> > Ada 2005 overcomes the problem by introducing anonymous access to
> > subprogram types. This was actually considered during the design of
> > Ada 95 but it was not done at the time for two main reasons. Firstly,
> > the implementation problems for those who were using display vectors
> > rather than static links were considered a hurdle.
>
> Display vectors ?

This might help:

http://en.wikipedia.org/wiki/Call_stack

                  -- Adam

Re: subprogram must not be deeper than access type

[Yannick Duchêne (Hibou57)]

Le Tue, 04 Oct 2011 01:39:22 +0200, Adam Beneschan <adam@irvine.com> a  
écrit:
>> Display vectors ?
>
> This might help:
>
> http://en.wikipedia.org/wiki/Call_stack
>
>                   -- Adam
OK, I see, a display, is a list of pointers to the outer frames on a  
stack, just like Borland Pascal compiler did. I've never suspected this  
could be named “a display”. The word “display” may have a wider meaning  
than I use to though.

Thanks Adam, now it's clear.


-- 
“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: subprogram must not be deeper than access type

[Yannick Duchêne (Hibou57)]

Le Tue, 04 Oct 2011 02:52:26 +0200, Yannick Duchêne (Hibou57)  
<yannick_duchene@yahoo.fr> a écrit:
> OK, I see, a display, is a list of pointers to the outer frames on a  
> stack, just like Borland Pascal compiler did.
No, I'm wrong, if I remember well, Borland Pascal only used what the above  
link name static‑link (there was no optimization for access to outer  
frames via a list of frame pointers, and the list had to be walked).


-- 
“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: subprogram must not be deeper than access type

[Robert A Duff]

Natasha Kerensikova <lithiumcat@gmail.com> writes:

> And GNAT refused to compile it, because "subprogram must not be deeper
> than access type".
>
> So I imagined that since Builder and Output have the same lifetime, it
> might not be so well-define which will cease to exist first.

Note that the error message says "access TYPE".  The Output object
has nothing to do with it.  It is complaining because the access
type is at library level, whereas Builder is nested inside Main.

>...So while
> not strictly deeper, being as deep can be a problem.

No, two things at the same level have lifetimes that end at
the same time.

I don't really understand what you're trying to do, so I can't advise
you how to fix it.  It might be better to use dispatching procedures
rather than access-to-procedure.

It's probably best if you avoid putting any significant code inside
your main procedure.  Put everything in library packages or generic
packages, and make the main procedure just one line.

- Bob

Re: subprogram must not be deeper than access type

[georg bauhaus]

Natasha Kerensikova <lithiumcat@gmail.com> wrote:
> 
:
> 
> type String_Accumulator_Linked_List (Builder : Accumulator_Builder)
>    is new String_Accumulator_Stack with private;

As an aside, I'd consider an alternative type
String_Accumulator_Linked_List that
has a stack, rather than being a stack.
From this choice a more flexible design 
might follow.

Also, whenever an anonymous type
seems to solve a design problem,
something might be in bad shape
at a higher level. Note that a pointer
has two ends and a direction:
You could pass work in its direction 
instead of working with pointers at this
end.

Re: subprogram must not be deeper than access type

[Natasha Kerensikova]

Hello,

On 2011-09-25, georg bauhaus <rmhost.bauhaus@maps.arcor.de> wrote:
> Natasha Kerensikova <lithiumcat@gmail.com> wrote:
>> type String_Accumulator_Linked_List (Builder : Accumulator_Builder)
>>    is new String_Accumulator_Stack with private;
>
> As an aside, I'd consider an alternative type
> String_Accumulator_Linked_List that
> has a stack, rather than being a stack.
> From this choice a more flexible design 
> might follow.

That's a great idea, thanks a lot for pointing it out. I still don't
intend to change my String_Accumulator_Linked_List, since it's goal is
really to be the simplest possible implementation of the interface, only
to have some real code to run.

However when things get more mature, I will probably want something more
flexible and easier to integrate with other components, and that's when
your suggestion will certainly be useful.

> Also, whenever an anonymous type
> seems to solve a design problem,
> something might be in bad shape
> at a higher level.

Actually I wonder whether there is a design problem at all.

The thing is, I'm still a beginner in Ada and probably also in real
software engineering. I'm probably tainted by more than a decade of
practising C, following almost a decade of 386 assembly as my first
programming language. I genuinely don't see anything wrong with the
design, but I might very well be missing something, hence my exposing it
to c.l.a. criticism.

Moreover, now that a solution is known, I'm still not convinced about a
problem in the design: the use of named access to subprogram types is
not required by the design, and it is not even required by the
implementation. I named the access type only to make the program text
clearer (for humans).

Having read the Rationale 2005, I understand now that naming an access
type is far from being equivalent to text replacement. A slightly less
readable program text is a small price to pay for the extra safety.


Thanks for your comments,
Natasha

Re: subprogram must not be deeper than access type

[Robert A Duff]

Natasha Kerensikova <lithiumcat@gmail.com> writes:

> Having read the Rationale 2005, I understand now that naming an access
> type is far from being equivalent to text replacement.

Yeah.  That's a language design flaw.

- Bob

Re: subprogram must not be deeper than access type

[Dmitry A. Kazakov]

On Mon, 26 Sep 2011 09:43:07 -0400, Robert A Duff wrote:

> Natasha Kerensikova <lithiumcat@gmail.com> writes:
> 
>> Having read the Rationale 2005, I understand now that naming an access
>> type is far from being equivalent to text replacement.
> 
> Yeah.  That's a language design flaw.

What is the flaw, naming or having it anonymous?

I think that the problem is that access types to automatically collected
objects and access types to the objects allocated and freed dynamically
should be different, if the former could not be eliminated at all.

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

Re: subprogram must not be deeper than access type

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Mon, 26 Sep 2011 09:43:07 -0400, Robert A Duff wrote:
>
>> Natasha Kerensikova <lithiumcat@gmail.com> writes:
>> 
>>> Having read the Rationale 2005, I understand now that naming an access
>>> type is far from being equivalent to text replacement.
>> 
>> Yeah.  That's a language design flaw.
>
> What is the flaw, naming or having it anonymous?

In my opinion, if anonymous types are allowed, they should behave
exactly like named types.  In the case of access types, I mean
"exactly like a named type declared immediately after the designated
[sub?]type".  (There's an obscure issue, in the case where the
designated subtype is more nested than the designated type,
and depends on nested data.  I'm not sure how to solve that;
perhaps just forbid it.)

The flaw I was referring to was that Ada doesn't have that equivalence.
Making an access type anonymous invokes all sorts of magical semantics,
which is confusing.  If such magical semantics are desirable, they
should be invoked by some other syntax.  (And by the way, I don't think
run-time accessibility checks are desirable.  That's another design flaw.)

Another flaw is that some types can be anonymous (task, protected,
array, access) and some can't.  It should be all or nothing.

And it's just weird that if you say "X, Y : array...;"
"X := Y;" and "if X = Y ..." are illegal.  Textual replacement is
a wrong way to define semantics.

> I think that the problem is that access types to automatically collected
> objects and access types to the objects allocated and freed dynamically
> should be different, if the former could not be eliminated at all.

Not sure what you mean by "automatically collected".  Local to a
procedure?  Or are you talking about garbage collection?  What
about library-package-body variables?  What about components
of variables?

Ada 83 required all access values to point to heap-allocated objects.
Ada 95 added "access all", which allows pointing at any aliased object.
That's sort of similar to the distinction you're making, I think.

- Bob

Re: subprogram must not be deeper than access type

[Dmitry A. Kazakov]

On Mon, 26 Sep 2011 12:15:51 -0400, Robert A Duff wrote:

> The flaw I was referring to was that Ada doesn't have that equivalence.
> Making an access type anonymous invokes all sorts of magical semantics,
> which is confusing.  If such magical semantics are desirable, they
> should be invoked by some other syntax.  (And by the way, I don't think
> run-time accessibility checks are desirable.  That's another design flaw.)

Yes, it would be much simpler to have subprogram types for downward
closures.

> Another flaw is that some types can be anonymous (task, protected,
> array, access) and some can't.  It should be all or nothing.

I'd like to have anonymous types in record components. It is annoying not
to be able to write:

   type Foo is record
       Nested : record
          end record;
       List : array (...) of ...;
   end record;

Even C can this!

> And it's just weird that if you say "X, Y : array...;"
> "X := Y;" and "if X = Y ..." are illegal.  Textual replacement is
> a wrong way to define semantics.

But structural type matching is more wrong than that.

>> I think that the problem is that access types to automatically collected
>> objects and access types to the objects allocated and freed dynamically
>> should be different, if the former could not be eliminated at all.
> 
> Not sure what you mean by "automatically collected".  Local to a
> procedure?  Or are you talking about garbage collection?  What
> about library-package-body variables?  What about components
> of variables?

E.g. things on the stack.

> Ada 83 required all access values to point to heap-allocated objects.
> Ada 95 added "access all", which allows pointing at any aliased object.
> That's sort of similar to the distinction you're making, I think.

Yes. There should be:

1. Strictly heap access types, manually allocated/deallocated, no
accessibility checks, no calls to Finalize outside Unchecked_Deallocation.
I would even provide a built-in operation Free for them.

2. References to aliased objects, shaped more like "X renames Y", fully
statically checked.

3. "Access all" for emergency cases.

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

Re: subprogram must not be deeper than access type

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Mon, 26 Sep 2011 12:15:51 -0400, Robert A Duff wrote:
>
>> The flaw I was referring to was that Ada doesn't have that equivalence.
>> Making an access type anonymous invokes all sorts of magical semantics,
>> which is confusing.  If such magical semantics are desirable, they
>> should be invoked by some other syntax.  (And by the way, I don't think
>> run-time accessibility checks are desirable.  That's another design flaw.)
>
> Yes, it would be much simpler to have subprogram types for downward
> closures.

Yes, "not null access procedure" is annoying when I really mean
"procedure".

>> Another flaw is that some types can be anonymous (task, protected,
>> array, access) and some can't.  It should be all or nothing.
>
> I'd like to have anonymous types in record components. It is annoying not
> to be able to write:
>
>    type Foo is record
>        Nested : record
>           end record;
>        List : array (...) of ...;
>    end record;
>
> Even C can this!

Yes.  But it's not a big deal.

>> And it's just weird that if you say "X, Y : array...;"
>> "X := Y;" and "if X = Y ..." are illegal.  Textual replacement is
>> a wrong way to define semantics.
>
> But structural type matching is more wrong than that.

Mostly true.  But if the opposite of "structural typing"
is "by name", then it makes no sense.  There's no name for
that type, here.

>>> I think that the problem is that access types to automatically collected
>>> objects and access types to the objects allocated and freed dynamically
>>> should be different, if the former could not be eliminated at all.
>> 
>> Not sure what you mean by "automatically collected".  Local to a
>> procedure?  Or are you talking about garbage collection?  What
>> about library-package-body variables?  What about components
>> of variables?
>
> E.g. things on the stack.
>
>> Ada 83 required all access values to point to heap-allocated objects.
>> Ada 95 added "access all", which allows pointing at any aliased object.
>> That's sort of similar to the distinction you're making, I think.
>
> Yes. There should be:
>
> 1. Strictly heap access types, manually allocated/deallocated, no
> accessibility checks, no calls to Finalize outside Unchecked_Deallocation.

Not even when the access type is finalized?

> I would even provide a built-in operation Free for them.

Yes, good idea.

> 2. References to aliased objects, shaped more like "X renames Y", fully
> statically checked.

OK.

> 3. "Access all" for emergency cases.

Yeah, we have that one now.

- Bob

Re: subprogram must not be deeper than access type

[Dmitry A. Kazakov]

On Mon, 26 Sep 2011 20:41:05 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Mon, 26 Sep 2011 12:15:51 -0400, Robert A Duff wrote:
>>
>>> And it's just weird that if you say "X, Y : array...;"
>>> "X := Y;" and "if X = Y ..." are illegal.  Textual replacement is
>>> a wrong way to define semantics.
>>
>> But structural type matching is more wrong than that.
> 
> Mostly true.  But if the opposite of "structural typing"
> is "by name", then it makes no sense.  There's no name for
> that type, here.

There is a name, the programmer just didn't reveal it to us.

>> 1. Strictly heap access types, manually allocated/deallocated, no
>> accessibility checks, no calls to Finalize outside Unchecked_Deallocation.
> 
> Not even when the access type is finalized?

Yes, it is the user's responsibility to deallocate objects. I can also
imagine cases where controlled objects could be purposely allocated, but
never freed, e.g. compiler tables of tokens.

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

Re: subprogram must not be deeper than access type

[Yannick Duchêne (Hibou57)]

Le Tue, 27 Sep 2011 02:41:05 +0200, Robert A Duff  
<bobduff@shell01.theworld.com> a écrit:
> Yes, "not null access procedure" is annoying when I really mean
> "procedure".
Then why not a tagged Procedure_Type ?

-- 
“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: subprogram must not be deeper than access type

[J-P. Rosen]

Le 26/09/2011 21:30, Dmitry A. Kazakov a �crit :
> I'd like to have anonymous types in record components. It is annoying not
> to be able to write:
> 
>    type Foo is record
>        Nested : record
>           end record;
>        List : array (...) of ...;
>    end record;
> 
"Annoying to write" was never an issue in Ada, where we favor ease of
reading over ease of writing. If your Nested component represents a
logical entity of your problem domain, it deserves a name (i.e. a type).
And what could you do with this component? Without a type name, no
subprogram could operate on it.

> Even C can this!
There are lots of things you can do in C and not in Ada (shooting
yourself in the foot comes to mind).

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Adalog a d�m�nag� / Adalog has moved:
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00

Re: subprogram must not be deeper than access type

[Dmitry A. Kazakov]

On Tue, 27 Sep 2011 07:50:54 +0200, J-P. Rosen wrote:

> Le 26/09/2011 21:30, Dmitry A. Kazakov a �crit :
>> I'd like to have anonymous types in record components. It is annoying not
>> to be able to write:
>> 
>>    type Foo is record
>>        Nested : record
>>           end record;
>>        List : array (...) of ...;
>>    end record;
>> 
> "Annoying to write" was never an issue in Ada, where we favor ease of
> reading over ease of writing.

Forward type declarations of types used only for components (and BTW, for
generic instances) are very annoying especially for reading.

> If your Nested component represents a
> logical entity of your problem domain, it deserves a name (i.e. a type).
> And what could you do with this component? Without a type name, no
> subprogram could operate on it.

It is meant only to have large record types structured. E.g.

   type Buffer_Implementation (Size : Positive) is record
      Position : record
            In_Index : ...;
            Out_Index : ...;
              ...
         end record;
      Consumer_Notification : record
            ...  
         end record;
      Data : array (1..Size) of Octet;
      ...

No special meaning other than grouping other components.

Compare it with declare-begin-end blocks they too have no names and have no
identifiable counterpart in the domain, just an implementation detail.

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

Re: subprogram must not be deeper than access type

[Yannick Duchêne (Hibou57)]

Le Tue, 27 Sep 2011 09:52:09 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Compare it with declare-begin-end blocks they too have no names and have  
> no
> identifiable counterpart in the domain, just an implementation detail.
Except these are just flowed. If you want a block to be possibly invoked  
independently, then you make it a procedure, … which is named.

If you do not need to access sub‑records of a record, then you just don't  
need sub‑records. If you need to access sub‑records, then you just create  
some named types for these parts, just like with blocks vs procedures.

-- 
“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: subprogram must not be deeper than access type

[Dmitry A. Kazakov]

On Tue, 04 Oct 2011 06:26:01 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Tue, 27 Sep 2011 09:52:09 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
>> Compare it with declare-begin-end blocks they too have no names and have no
>> identifiable counterpart in the domain, just an implementation detail.
> Except these are just flowed. If you want a block to be possibly invoked  
> independently, then you make it a procedure, … which is named.

There is no clear margin, but the name of a procedure may refer to its name
and/or its singleton type. They are not separated properly, because Ada has
no procedural types.

BTW, blocks can be named in Ada:

A : begin
      null;
   end A;

Here A is the proper name, and you don't need the type of A. This type is
anonymous.

> If you do not need to access sub‑records of a record,

Access to the subrecord is needed, but only though its components not as a
whole. These components would be named but have anonymous types.

------------------------------
BTW, the list of parameters of a subprogram is an anonymous record type,
but Ada does not require its explicit declaration, e.g.

   type Integer_Tuple is record
      Left : Integer;
      Right : Integer;
   end record;
   function "+" : Integer_Tuple return Integer;

If it could, you would have so much longed variant arguments:

   type Printf_Arguments (Some_Discriminant : ...) is record
      case Some_Discriminant is
          when ... =>
          when ... =>
          ...
      end case;
   end record;
   pragma Unchecked_Union (Printf_Arguments);
   procedure Printf : Printf_Arguments;

(:-))

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

Re: subprogram must not be deeper than access type

[Georg Bauhaus]

On 04.10.11 09:58, Dmitry A. Kazakov wrote:

> ------------------------------
> BTW, the list of parameters of a subprogram is an anonymous record type,
> but Ada does not require its explicit declaration, e.g.
> 
>    type Integer_Tuple is record
>       Left : Integer;
>       Right : Integer;
>    end record;
>    function "+" : Integer_Tuple return Integer;

To better meet programmer expectations, functions could then
return lists of values as objects of a similar anonymous
record type.

  (Left, Right) := Explode (Argument);

With accessors, this is more interesting. Let F2
return a pair of accessorable (?) objects:

  (F2 (A), F2 (B)) :=  -- 4-tuple
    Explode (Argument) & Explode (Argument);

"&" would then become a suitably overridden operation
of some anonymous type.  Perhaps also

  (F2 (A), F2 (B)) :=
    Explode_3 (Argument) & Explode (Argument)(2);

assuming that indexing starts at 1.

SCNR

Re: subprogram must not be deeper than access type

[Dmitry A. Kazakov]

On Tue, 04 Oct 2011 17:10:51 +0200, Georg Bauhaus wrote:

> On 04.10.11 09:58, Dmitry A. Kazakov wrote:
> 
>> ------------------------------
>> BTW, the list of parameters of a subprogram is an anonymous record type,
>> but Ada does not require its explicit declaration, e.g.
>> 
>>    type Integer_Tuple is record
>>       Left : Integer;
>>       Right : Integer;
>>    end record;
>>    function "+" : Integer_Tuple return Integer;
> 
> To better meet programmer expectations, functions could then
> return lists of values as objects of a similar anonymous
> record type.

Sure, the result(s) belongs there.

>   (Left, Right) := Explode (Argument);
> 
> With accessors, this is more interesting. Let F2
> return a pair of accessorable (?) objects:

Down with accessors. The language should simply support sugars like:

   F (X) := G (Y)  -->  F[Index] (X, G (Y))

After prefix notation was introduced, there is no reason why other
shortcuts should not be allowed.

Specifically to accessors they are mess already. Would you try to figure
out how two accessors in a tuple of would interact?

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

Re: subprogram must not be deeper than access type

[Yannick Duchêne (Hibou57)]

Le Tue, 04 Oct 2011 17:34:28 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Down with accessors. The language should simply support sugars like:
>
>    F (X) := G (Y)  -->  F[Index] (X, G (Y))
>
> After prefix notation was introduced, there is no reason why other
> shortcuts should not be allowed.

This is not a matter of sugar of shortcuts, that's a matter of being  
explicit and clean. Formally speaking, parameters of a function is a  
tuple, the same for function result. No need for more (but not for the  
actual Ada any way).


-- 
“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: subprogram must not be deeper than access type

[Dmitry A. Kazakov]

On Tue, 04 Oct 2011 17:49:24 +0200, Yannick Duch�ne (Hibou57) wrote:

> Le Tue, 04 Oct 2011 17:34:28 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
>> Down with accessors. The language should simply support sugars like:
>>
>>    F (X) := G (Y)  -->  F[Index] (X, G (Y))
>>
>> After prefix notation was introduced, there is no reason why other
>> shortcuts should not be allowed.
> 
> This is not a matter of sugar of shortcuts, that's a matter of being  
> explicit and clean. Formally speaking, parameters of a function is a  
> tuple, the same for function result. No need for more (but not for the  
> actual Ada any way).

It is not that simple. Sugar is always needed, for example for flattening
lists: F((a,b,c)) <--> F'(a,b,c)

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

Re: subprogram must not be deeper than access type

[Yannick Duchêne (Hibou57)]

Le Tue, 04 Oct 2011 17:10:51 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> To better meet programmer expectations, functions could then
> return lists of values as objects of a similar anonymous
> record type.
Yes, and that's what Functional Languages do. I believe Ada could benefit  
 from more FP (it already has something of FP).

-- 
“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: subprogram must not be deeper than access type

[Georg Bauhaus]

On 04.10.11 17:44, Yannick Duchêne (Hibou57) wrote:
> Le Tue, 04 Oct 2011 17:10:51 +0200, Georg Bauhaus
> <rm.dash-bauhaus@futureapps.de> a écrit:
>> To better meet programmer expectations, functions could then
>> return lists of values as objects of a similar anonymous
>> record type.
> Yes, and that's what Functional Languages do. I believe Ada could benefit from
> more FP (it already has something of FP).

How so?  If Haskell is representative, the return type
of a function can be named in FP languages.

The type of values passed to a function is polymorphic,
sometimes syntactically polymorphic, sometimes polymorphic
at an explanatory level (value vs. n-tuple).

Re: subprogram must not be deeper than access type

[Yannick Duchêne (Hibou57)]

Le Tue, 04 Oct 2011 18:05:57 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
>> Yes, and that's what Functional Languages do. I believe Ada could  
>> benefit from
>> more FP (it already has something of FP).
>
> How so?
What I miss is currying (thinking in term of currying, help the design  
too), tail recursion optimization (not part of language this one, but  
could be advised), and package interface working more like structure  
signature.

But there are already some great parts of FP in Ada. Value semantic is  
often enforced, we now have conditional expressions (Ada 2012) and Ada  
constants are really constants at the level of scope execution (same kind  
of constants as in FP, not the same as in C/C++).

There was Agol60 and Pascal, FP was a missing influence of Ada.

But FP is neither an Holy Grail. Example: Design By Contract (™), is not  
FP. Other example: in real life, references are really required for  
performances, even if hidden inside package implementation (no one enjoy  
copying a whole structure to update that structure, it's a waste of  
performance).


-- 
“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: subprogram must not be deeper than access type

[Yannick Duchêne (Hibou57)]

Le Tue, 04 Oct 2011 09:58:21 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> BTW, the list of parameters of a subprogram is an anonymous record type,
> but Ada does not require its explicit declaration, e.g.
I use to think the same too. Agree this would be more clean. The same  
could be with result returned from functions too. I also guess if Ada did  
such a different thing, people would run away from Ada even faster than  
they actually do.

I don't believe such points, although clever, should be expected to be  
part of future Ada revision, but preferably part of a potential Ada  
successor.

What a pity there is no repository for this kind of ideas. It's all lost  
scattered every where in this Usenet.


-- 
“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: subprogram must not be deeper than access type

[Jeffrey Carter]

On 09/26/2011 06:43 AM, Robert A Duff wrote:
> Natasha Kerensikova<lithiumcat@gmail.com>  writes:
>
>> Having read the Rationale 2005, I understand now that naming an access
>> type is far from being equivalent to text replacement.
>
> Yeah.  That's a language design flaw.

I think anonymous types are the language design flaw.

-- 
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus
21

Re: subprogram must not be deeper than access type

[Robert A Duff]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> On 09/26/2011 06:43 AM, Robert A Duff wrote:
>> Natasha Kerensikova<lithiumcat@gmail.com>  writes:
>>
>>> Having read the Rationale 2005, I understand now that naming an access
>>> type is far from being equivalent to text replacement.
>>
>> Yeah.  That's a language design flaw.
>
> I think anonymous types are the language design flaw.

Why?

I don't agree on that point, but surely you would agree that IF a
language allows anonymous types, they ought to behave like similar named
types.  Right?

And surely you would agree that IF a language allows (say) anonymous
array types, it should also allow anonymous record types.
All or nothing.

- Bob

Re: subprogram must not be deeper than access type

[Yannick Duchêne (Hibou57)]

Le Mon, 26 Sep 2011 20:59:55 +0200, Jeffrey Carter  
<spam.jrcarter.not@spam.not.acm.org> a écrit:

> On 09/26/2011 06:43 AM, Robert A Duff wrote:
>> Natasha Kerensikova<lithiumcat@gmail.com>  writes:
>>
>>> Having read the Rationale 2005, I understand now that naming an access
>>> type is far from being equivalent to text replacement.
>>
>> Yeah.  That's a language design flaw.
>
> I think anonymous types are the language design flaw.

There were introduced for the need of anonymous access type to  
subprograms, but 1) were applied to objects in the while 2) there were  
probably alternatives (as the mentioned rational recognized). So, may be  
you are right. I confess I don't really enjoy anonymous access type too.

Except that if I'm not wrong, anonymous access type were also introduced  
for the need of some parts of I/O packages. Someone can tell more ?


-- 
“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: subprogram must not be deeper than access type

[Jeffrey Carter]

On 10/03/2011 09:30 PM, Yannick Duchêne (Hibou57) wrote:
> Le Mon, 26 Sep 2011 20:59:55 +0200, Jeffrey Carter
>>
>> I think anonymous types are the language design flaw.
>
> There were introduced for the need of anonymous access type to subprograms, but
> 1) were applied to objects in the while 2) there were probably alternatives (as
> the mentioned rational recognized). So, may be you are right. I confess I don't
> really enjoy anonymous access type too.

Ada always had anonymous array types:

V : array (1 .. 10) of Duration;

Anonymous access types in the form of access parameters were introduced in Ada 
95, to make passing a pointer to an imported function from C (or similar 
languages) easier. Never mind that a named convention-C access type did the job 
just fine. More recently, we've been treated to a whole slew of kinds of 
anonymous access types, apparently to make C-in-Ada easier to write.

-- 
Jeff Carter
"I was hobbling along, minding my own business, all of a
sudden, up he comes, cures me! One minute I'm a leper with
a trade, next minute my livelihood's gone! Not so much as a
'by your leave!' You're cured, mate. Bloody do-gooder!"
Monty Python's Life of Brian
76

Re: subprogram must not be deeper than access type

[Georg Bauhaus]

On 26.09.11 11:45, Natasha Kerensikova wrote:

>> Also, whenever an anonymous type
>> seems to solve a design problem,
>> something might be in bad shape
>> at a higher level.
> 
> Actually I wonder whether there is a design problem at all.

Just a design choice.

In general, I should think that if an author too quickly arrives
at pointers, some C heritage shows. I can really picture the
structs and function pointers, I think :-)

If you have an object of

  type String_Accumulator_Linked_List (Builder : Accumulator_Builder)
     is new String_Accumulator_Stack with private;

then the Builder component is fixed. Fine. Presumably, the operations
of String_Accumulator_Linked_List call Builder as necessary.
So Builder has to be in scope where they do that.

For making Builder visible, an access discriminant pointing
to a function is a possible choice;
there are more ways of making a function visible, not necessarily worse
or better, but they may save some trouble or be of different efficiency,
or clarity.
One is scoping.  Another is instantiation of a suitable generic,
one that declares a simpler String_Accumulator_Linked_List.

At the other end, a factory like Accumulator_Builder might (or might not)
deserve a type of its own. The implementation of the operations of
String_Accumulator_Linked_List would again be able to request
new accumulators from the factory, but this time through operations
of this factory type, adjusted, modified, varied, as needed.  For example,
a task could supply the list with new accumulators from some
foreign pool, and could shape the accumulators as requested.
(The shapes being configured when setting up the factory, or
while it is operating already.)

I'd make a factory object a by-reference type if copying is
a concern, and try to avoid indirection without need.
One way to do away with a pointer to the factory is to
have the core algorithm subprogram take a factory parameter:


   procedure Do_Stuff
     (Factory : Accumulator_Builder; ...)

The invisible difference here is that Accumulator_Builder
would not have to be a pointer.


> Having read the Rationale 2005, I understand now that naming an access
> type is far from being equivalent to text replacement. A slightly less
> readable program text is a small price to pay for the extra safety.

As I understand it, anonymous pointers (a) enable references to nested
subprograms in ways just not possible before their introduction,
and (b) circumvent problems with conversions-to-named and with
implementation techniques. So there wouldn't be an argument about safety,
or is there?

Re: subprogram must not be deeper than access type

[Georg Bauhaus]

On 26.09.11 16:29, Georg Bauhaus wrote:

> At the other end, a factory like Accumulator_Builder might (or might not)
> deserve a type of its own.

I should have said type other than pointer.

Re: subprogram must not be deeper than access type

[Yannick Duchêne (Hibou57)]

Le Mon, 26 Sep 2011 16:29:47 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:

> On 26.09.11 11:45, Natasha Kerensikova wrote:
>
>>> Also, whenever an anonymous type
>>> seems to solve a design problem,
>>> something might be in bad shape
>>> at a higher level.
>>
>> Actually I wonder whether there is a design problem at all.
>
> Just a design choice.
>
> In general, I should think that if an author too quickly arrives
> at pointers, some C heritage shows. I can really picture the
> structs and function pointers, I think :-)
That's where some functional programing background can make a difference  
;-) (with apologizes to Dmitry)

-- 
“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: subprogram must not be deeper than access type

[Yannick Duchêne (Hibou57)]

Le Mon, 26 Sep 2011 11:45:53 +0200, Natasha Kerensikova  
<lithiumcat@gmail.com> a écrit:
> Having read the Rationale 2005, I understand now that naming an access
> type is far from being equivalent to text replacement. A slightly less
> readable program text is a small price to pay for the extra safety.
You mean you feel anonymous access type is safer than named access type ?

-- 
“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: subprogram must not be deeper than access type

[Jeffrey Carter]

On 09/25/2011 02:02 AM, Natasha Kerensikova wrote:
>
> I'm encountering the error in the subject, "subprogram must not be
> deeper than access type", and while I understand what it means in
> general and the rationale, I'm lost on why it applies to my code and how
> to work around it.

The problem is that there is nothing special about the main-program procedure. 
Specifically, it could be withed and called from something else, or call itself 
recursively. In either case, its declarative region, with its declaration of the 
function, would be nested deeper than the declaration of the access type. Since 
this is a compile-time check, it rejects anything that might be deeper, even 
when it never is.

The basic rule with named access-to-subprogram types is that the actual 
subprogram must be declared in a library-level package.

-- 
Jeff Carter
"Every sperm is sacred."
Monty Python's the Meaning of Life
55

Re: subprogram must not be deeper than access type

[Robert A Duff]

Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:

> The problem is that there is nothing special about the main-program
> procedure. Specifically, it could be withed and called from something
> else, or call itself recursively. In either case, its declarative
> region, with its declaration of the function, would be nested deeper
> than the declaration of the access type. Since this is a compile-time
> check, it rejects anything that might be deeper, even when it never is.

Right.  Also, when the main procedure returns, that's not the end of
the program.  Library-level tasks can keep running for a long time
after that.

It's really annoying that in Ada you can't write a small example program
(with a single compilation unit in a single file) that has multiple
library-level things.  If I ran the circus, there would be no library
subprograms.  The main procedure would be declared inside a library
PACKAGE.

> The basic rule with named access-to-subprogram types is that the actual
> subprogram must be declared in a library-level package.

Right.

Just to clarify: library-level means not nested in any procedures,
functions, or tasks.  If the (named) access type is declared at library
level, then for P'Access, P must be declared at library level.  Nesting
within any number of packages doesn't count, for accessibility levels.

Anonymous access types work differently.

GNAT has P'Unrestricted_Access, which allows you to violate the
accessibility rules, but that's not portable.

- Bob

Re: subprogram must not be deeper than access type

[Georg Bauhaus]

On 25.09.11 23:53, Robert A Duff wrote:

> It's really annoying that in Ada you can't write a small example program
> (with a single compilation unit in a single file) that has multiple
> library-level things.  If I ran the circus, there would be no library
> subprograms.  The main procedure would be declared inside a library
> PACKAGE.

It's worth mentioning, I think, that one source text for a single
compilation in a single file can be submitted to GNAT, such that
at the same time it also removes the specific accessibility problem
that Natasha's example exhibits.  To translate with GNAT, switch -z
is required.  Do other compilers support "main packages", too?

with String_Builder_Types;

package Main is
    use String_Builder_Types;

    function Builder (Depth : Positive) return Typ'Class;

    Output : String_Builder_Types.Non_Generic (Builder'Access);
end Main;

package body Main is

    function Builder (Depth : Positive) return Typ'Class is
       pragma Unreferenced (Depth);
    begin
       return String_Builder_Types.Empty_Typ;
    end Builder;

begin
    null;  --  or actually, real code.
end Main;

package String_Builder_Types is

    type Typ is tagged private;
    Empty_Typ : constant Typ;

    type Func is
        access function (Depth : Positive) return Typ'Class;

    type Non_Generic (Builder : Func) is tagged null record;
private
    type Typ is tagged null record;
    Empty_Typ : constant Typ := Typ'(null record);
end String_Builder_Types;

Re: subprogram must not be deeper than access type

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccd3eothjf.fsf@shell01.TheWorld.com...
...

> It's really annoying that in Ada you can't write a small example program
> (with a single compilation unit in a single file) that has multiple
> library-level things.  If I ran the circus, there would be no library
> subprograms.  The main procedure would be declared inside a library
> PACKAGE.

That's how Janus/Ada worked for its early life. (Strictly speaking, it was 
the elaboration of a package body that was the main subprogram, typically 
that would have just been a call.) Eventually, we had to change it to a 
subprogram in order to run the ACVC (now ACATS). For a long time, there was 
an option to have a package be the main, but we got rid of it at some point 
when it was causing some bugs.

                                  Randy.

Re: subprogram must not be deeper than access type

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> That's how Janus/Ada worked for its early life.

Yes, I know.  That's a perfectly reasonable way to do things.
Too bad Ada doesn't allow it.

>...(Strictly speaking, it was 
> the elaboration of a package body that was the main subprogram, typically 
> that would have just been a call.)

That's just a detail.

>...Eventually, we had to change it to a 
> subprogram in order to run the ACVC (now ACATS). For a long time, there was 
> an option to have a package be the main, but we got rid of it at some point 
> when it was causing some bugs.

GNAT has such an option.

- Bob