Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
subprogram must not be deeper than access type
1,448 views
Skip to first unread message
Natasha Kerensikova
Sep 25, 2011, 5:02:50 AM9/25/11
to
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
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
Oliver Kleinke
Sep 25, 2011, 10:04:42 AM9/25/11
to
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
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
Robert A Duff
Sep 25, 2011, 10:23:35 AM9/25/11
to
Natasha Kerensikova <lithi...@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
georg bauhaus
Sep 25, 2011, 11:03:36 AM9/25/11
to
Natasha Kerensikova <lithi...@gmail.com> wrote:
>
:
>
> type String_Accumulator_Linked_List (Builder : Accumulator_Builder)
> is new String_Accumulator_Stack with private;
>
:
>
> 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.
Jeffrey Carter
Sep 25, 2011, 1:16:29 PM9/25/11
to
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.
>
> 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
Robert A Duff
Sep 25, 2011, 5:53:56 PM9/25/11
to
Jeffrey Carter <spam.jrc...@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 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 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.
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
Georg Bauhaus
Sep 26, 2011, 5:25:47 AM9/26/11
to
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
> 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.
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;
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;
Natasha Kerensikova
Sep 26, 2011, 5:35:16 AM9/26/11
to
Hello,
On 2011-09-25, Oliver Kleinke <oliver....@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
On 2011-09-25, Oliver Kleinke <oliver....@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
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
Natasha Kerensikova
Sep 26, 2011, 5:45:53 AM9/26/11
to
Hello,
On 2011-09-25, georg bauhaus <rmhost....@maps.arcor.de> wrote:
> Natasha Kerensikova <lithi...@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
On 2011-09-25, georg bauhaus <rmhost....@maps.arcor.de> wrote:
> Natasha Kerensikova <lithi...@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.
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.
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
Robert A Duff
Sep 26, 2011, 9:43:07 AM9/26/11
to
Natasha Kerensikova <lithi...@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.
> Having read the Rationale 2005, I understand now that naming an access
> type is far from being equivalent to text replacement.
- Bob
Dmitry A. Kazakov
Sep 26, 2011, 10:20:58 AM9/26/11
to
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
Georg Bauhaus
Sep 26, 2011, 10:29:47 AM9/26/11
to
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.
>> 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.
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;
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.
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?
Georg Bauhaus
Sep 26, 2011, 11:31:09 AM9/26/11
to
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.
Robert A Duff
Sep 26, 2011, 12:15:51 PM9/26/11
to
"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:
> On Mon, 26 Sep 2011 09:43:07 -0400, Robert A Duff wrote:
>
>> Natasha Kerensikova <lithi...@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
> On Mon, 26 Sep 2011 09:43:07 -0400, Robert A Duff wrote:
>
>> Natasha Kerensikova <lithi...@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?
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.
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
Jeffrey Carter
Sep 26, 2011, 2:59:55 PM9/26/11
to
--
Jeff Carter
"My brain hurts!"
Monty Python's Flying Circus
21
Dmitry A. Kazakov
Sep 26, 2011, 3:30:35 PM9/26/11
to
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
> 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.)
closures.
> Another flaw is that some types can be anonymous (task, protected,
> array, access) and some can't. It should be all or nothing.
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.
>> 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.
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.
Randy Brukardt
Sep 26, 2011, 7:00:28 PM9/26/11
to
"Robert A Duff" <bob...@shell01.TheWorld.com> wrote in message
news:wccd3eo...@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.
news:wccd3eo...@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.
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.
Robert A Duff
Sep 26, 2011, 8:34:25 PM9/26/11
to
Yes, I know. That's a perfectly reasonable way to do things.
Too bad Ada doesn't allow it.
>...(Strictly speaking, it was
>...Eventually, we had to change it to a
- Bob
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.
> 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.
GNAT has such an option.
> an option to have a package be the main, but we got rid of it at some point
> when it was causing some bugs.
- Bob
Robert A Duff
Sep 26, 2011, 8:35:46 PM9/26/11
to
Jeffrey Carter <spam.jrc...@spam.not.acm.org> writes:
> On 09/26/2011 06:43 AM, Robert A Duff wrote:
>> Natasha Kerensikova<lithi...@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?
> On 09/26/2011 06:43 AM, Robert A Duff wrote:
>> Natasha Kerensikova<lithi...@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.
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
Robert A Duff
Sep 26, 2011, 8:41:05 PM9/26/11
to
> 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
>
>> 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.
"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!
>> 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.
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.
> 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.
- Bob
J-P. Rosen
Sep 27, 2011, 1:50:54 AM9/27/11
to
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
> 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;
>
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 (ro...@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
Dmitry A. Kazakov
Sep 27, 2011, 3:52:09 AM9/27/11
to
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
> 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.
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.
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.
Dmitry A. Kazakov
Sep 27, 2011, 4:58:21 AM9/27/11
to
On Mon, 26 Sep 2011 20:41:05 -0400, Robert A Duff wrote:
> "Dmitry A. Kazakov" <mai...@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.
> "Dmitry A. Kazakov" <mai...@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.
>> 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?
imagine cases where controlled objects could be purposely allocated, but
never freed, e.g. compiler tables of tokens.
Yannick Duchêne (Hibou57)
Oct 3, 2011, 7:30:38 PM10/3/11
to
Le Sun, 25 Sep 2011 16:04:42 +0200, Oliver Kleinke
<oliver....@c-01a.de> a écrit:
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
<oliver....@c-01a.de> a écrit:
> 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
Adam Beneschan
Oct 3, 2011, 7:39:22 PM10/3/11
to
On Oct 3, 4:30 pm, Yannick Duchêne (Hibou57)
> <oliver.klei...@c-01a.de> a écrit:
http://en.wikipedia.org/wiki/Call_stack
-- Adam
> <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...
> > 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)
>
> 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:
> 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 ?
http://en.wikipedia.org/wiki/Call_stack
-- Adam
Yannick Duchêne (Hibou57)
Oct 3, 2011, 8:52:26 PM10/3/11
to
Le Tue, 04 Oct 2011 01:39:22 +0200, Adam Beneschan <ad...@irvine.com> 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. 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.
écrit:
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.
Yannick Duchêne (Hibou57)
Oct 3, 2011, 9:48:52 PM10/3/11
to
Le Tue, 04 Oct 2011 02:52:26 +0200, Yannick Duchêne (Hibou57)
<yannick...@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).
<yannick...@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.
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).
Yannick Duchêne (Hibou57)
Oct 4, 2011, 12:13:41 AM10/4/11
to
Le Mon, 26 Sep 2011 11:45:53 +0200, Natasha Kerensikova
<lithi...@gmail.com> a écrit:
<lithi...@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 ?
> 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.
Yannick Duchêne (Hibou57)
Oct 4, 2011, 12:19:00 AM10/4/11
to
Le Tue, 27 Sep 2011 02:41:05 +0200, Robert A Duff
<bob...@shell01.theworld.com> a écrit:
<bob...@shell01.theworld.com> a écrit:
> Yes, "not null access procedure" is annoying when I really mean
> "procedure".
Then why not a tagged Procedure_Type ?
> "procedure".
Yannick Duchêne (Hibou57)
Oct 4, 2011, 12:26:01 AM10/4/11
to
Le Tue, 27 Sep 2011 09:52:09 +0200, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:
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.
<mai...@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
> no
> identifiable counterpart in the domain, just an implementation detail.
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.
Yannick Duchêne (Hibou57)
Oct 4, 2011, 12:30:45 AM10/4/11
to
Le Mon, 26 Sep 2011 20:59:55 +0200, Jeffrey Carter
<spam.jrc...@spam.not.acm.org> a écrit:
<spam.jrc...@spam.not.acm.org> a écrit:
> On 09/26/2011 06:43 AM, Robert A Duff wrote:
>> Natasha Kerensikova<lithi...@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 ?
Yannick Duchêne (Hibou57)
Oct 4, 2011, 12:35:21 AM10/4/11
to
Le Mon, 26 Sep 2011 16:29:47 +0200, Georg Bauhaus
<rm.dash...@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)
<rm.dash...@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 :-)
;-) (with apologizes to Dmitry)
Dmitry A. Kazakov
Oct 4, 2011, 3:58:21 AM10/4/11
to
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
> <mai...@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;
(:-))
Georg Bauhaus
Oct 4, 2011, 11:10:51 AM10/4/11
to
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
> ------------------------------
> 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;
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
Dmitry A. Kazakov
Oct 4, 2011, 11:34:28 AM10/4/11
to
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.
> 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:
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?
Yannick Duchêne (Hibou57)
Oct 4, 2011, 11:41:24 AM10/4/11
to
Le Tue, 04 Oct 2011 09:58:21 +0200, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:
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.
<mai...@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
> but Ada does not require its explicit declaration, e.g.
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.
Yannick Duchêne (Hibou57)
Oct 4, 2011, 11:44:05 AM10/4/11
to
Le Tue, 04 Oct 2011 17:10:51 +0200, Georg Bauhaus
<rm.dash...@futureapps.de> a écrit:
from more FP (it already has something of FP).
<rm.dash...@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
> return lists of values as objects of a similar anonymous
> record type.
from more FP (it already has something of FP).
Yannick Duchêne (Hibou57)
Oct 4, 2011, 11:49:24 AM10/4/11
to
Le Tue, 04 Oct 2011 17:34:28 +0200, Dmitry A. Kazakov
<mai...@dmitry-kazakov.de> a écrit:
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).
<mai...@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
>
> 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.
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).
Dmitry A. Kazakov
Oct 4, 2011, 12:04:14 PM10/4/11
to
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
> <mai...@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
> Le Tue, 04 Oct 2011 17:34:28 +0200, Dmitry A. Kazakov
> <mai...@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).
lists: F((a,b,c)) <--> F'(a,b,c)
Georg Bauhaus
Oct 4, 2011, 12:05:57 PM10/4/11
to
On 04.10.11 17:44, Yannick Duchêne (Hibou57) wrote:
> Le Tue, 04 Oct 2011 17:10:51 +0200, Georg Bauhaus
> <rm.dash...@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
> Le Tue, 04 Oct 2011 17:10:51 +0200, Georg Bauhaus
> <rm.dash...@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).
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).
Yannick Duchêne (Hibou57)
Oct 4, 2011, 12:47:20 PM10/4/11
to
Le Tue, 04 Oct 2011 18:05:57 +0200, Georg Bauhaus
<rm.dash...@futureapps.de> a écrit:
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).
<rm.dash...@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
>> benefit from
>> more FP (it already has something of FP).
>
> How so?
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).
Jeffrey Carter
Oct 4, 2011, 2:40:06 PM10/4/11
to
On 10/03/2011 09:30 PM, Yannick Duchêne (Hibou57) wrote:
> Le Mon, 26 Sep 2011 20:59:55 +0200, Jeffrey Carter
>>
> 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:
>
> 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.
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
0 new messages