grassroots thoughts on access types

grassroots thoughts on access types

[Mehdi Saada]

In my corrected exercices, I can read:

package P_Token.F is
   type T_Ptr_Token is access all T_Token'Class;
end P_Token.F;

package body  P_Token.Operateur.F is

   type T_Ptr_Token_Operateur is access all T_Token_Operateur;

   function Set_Ptr (Elem : in T_Operateur) return T_Ptr_Token is
      Ptr_Token : T_Ptr_Token_Operateur;
   begin
      Ptr_Token := new T_Token_Operateur;
      Initialisation(Ptr_Token.all,Elem);
      return Ptr_Token.all'access; -- @@@ HERE
   end Set_Ptr;

end P_Token.Operateur.F;

and

I understand the line marked (took me several minutes though ;-) ) but not the logic. Instead of
function Set_Ptr (Elem : in T_Operateur) return T_Ptr_Token is
      Ptr_Token : T_Ptr_Token_Operateur;
can we write:
 function Set_Ptr (Elem : in T_Operateur) return T_Ptr_Token is
      Ptr_Token : T_Ptr_Token;
? What's the difference regards to implementation, memory usage or anything ?
T_TOKEN is a null tagged record type, T_TOKEN_OPERATEUR has one more enumerative component.

Re: grassroots thoughts on access types

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:5d9134c9-a7d4-468e-8685-ebbb393eabea@googlegroups.com...
> In my corrected exercices, I can read:
>
> package P_Token.F is
>   type T_Ptr_Token is access all T_Token'Class;
> end P_Token.F;
>
> package body  P_Token.Operateur.F is
>
>   type T_Ptr_Token_Operateur is access all T_Token_Operateur;
>
>   function Set_Ptr (Elem : in T_Operateur) return T_Ptr_Token is
>      Ptr_Token : T_Ptr_Token_Operateur;
>   begin
>      Ptr_Token := new T_Token_Operateur;
>      Initialisation(Ptr_Token.all,Elem);
>      return Ptr_Token.all'access; -- @@@ HERE

You could also have written:
      return T_Ptr_Token(Ptr_Token);

Generally, type conversions for general access types are equivalent to 
".all'Access".

>   end Set_Ptr;
>
> end P_Token.Operateur.F;
>
> and
>
> I understand the line marked (took me several minutes though ;-) ) but not 
> the logic. Instead of
> function Set_Ptr (Elem : in T_Operateur) return T_Ptr_Token is
>      Ptr_Token : T_Ptr_Token_Operateur;
> can we write:
> function Set_Ptr (Elem : in T_Operateur) return T_Ptr_Token is
>      Ptr_Token : T_Ptr_Token;
> ? What's the difference regards to implementation, memory usage or 
> anything ?
> T_TOKEN is a null tagged record type, T_TOKEN_OPERATEUR has one more 
> enumerative component.

No difference that I can see. T_Ptr_Token_Operateur seems like a totally 
unnecessary type to me, since the allocator would work just as well with 
T_Ptr_Token. (But I haven't tried this in an actual compiler, so I might 
have forgotten something subtle.)

                                       Randy.

Re: grassroots thoughts on access types

[Simon Wright]

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

> Generally, type conversions for general access types are equivalent to
> ".all'Access".

.all'Access leaves it up to the compiler to figure out the conversion.

A colleague (one of the distinguished reviewers for Ada95) said (~2000)
he'd got into the habit of writing .all'Access, when usually (? - maybe
compiler issues) some thought would lead to the actual required
conversion.

>>         Instead of
>> function Set_Ptr (Elem : in T_Operateur) return T_Ptr_Token is
>>      Ptr_Token : T_Ptr_Token_Operateur;
>> can we write:
>> function Set_Ptr (Elem : in T_Operateur) return T_Ptr_Token is
>>      Ptr_Token : T_Ptr_Token;
>> ? What's the difference regards to implementation, memory usage or 
>> anything ?
>> T_TOKEN is a null tagged record type, T_TOKEN_OPERATEUR has one more 
>> enumerative component.
>
> No difference that I can see. T_Ptr_Token_Operateur seems like a
> totally unnecessary type to me, since the allocator would work just as
> well with T_Ptr_Token. (But I haven't tried this in an actual
> compiler, so I might have forgotten something subtle.)

We don't know the spec of Initialisation, but you might have to write

      Initialisation(T_Token_Operateur(Ptr_Token.all),Elem);

Re: grassroots thoughts on access types

[Dmitry A. Kazakov]

On 09/02/2018 10:13, Simon Wright wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
>> Generally, type conversions for general access types are equivalent to
>> ".all'Access".
> 
> .all'Access leaves it up to the compiler to figure out the conversion.
> 
> A colleague (one of the distinguished reviewers for Ada95) said (~2000)
> he'd got into the habit of writing .all'Access, when usually (? - maybe
> compiler issues) some thought would lead to the actual required
> conversion.

I prefer .all'Unchecked_Access, no run-time surprises.

I stopped feeling guilty for not trying to figure out the effect of 
accessibility rules in each case, when I realized that it would change 
nothing for the design. It is pure wasting time if the only difference 
would be having .all'Access instead (with some residual uncertainty 
whether it could blow up at run-time nevertheless).

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

Re: grassroots thoughts on access types

[Mehdi Saada]

Thanks Randy, I thought the same. Nice confirmation.

Re: grassroots thoughts on access types

[Mehdi Saada]

Thanks Randy, I thought the same. Nice confirmation.
Since I like the idea of proving and SPARK, and intend on learning it later, I'm not gonna use Uncheck_Access without really good reason... Or I would start learning, say, C++ I guess. But thanks too, that was hilarious. I wonder if it was a joke or not, though !

Re: grassroots thoughts on access types

[Simon Wright]

Mehdi Saada <00120260a@gmail.com> writes:

> Since I like the idea of proving and SPARK, and intend on learning it
> later, I'm not gonna use Uncheck_Access without really good reason

It may be that upcoming versions of SPARK will allow you to use the
keyword "access" - but probably in very restricted ways

Re: grassroots thoughts on access types

[Mehdi Saada]

I can see why, I read the SPARK manual on access types.
But I guess some algorithm becomes quite obfuscated then. Ah, actually, I long for having those kinds of problems, it would show how much I'll have progressed.

Re: grassroots thoughts on access types

[Jeffrey R. Carter]

Others have responded to your questions. I'd like to mention my thoughts on 
using access-to-object types (which I'll call "access types") in general. (By 
"use", I'm referring to designing code with access types, not to using them when 
required to in order to reuse existing code. Gnoga, for example, requires you to 
supply some access values to use it.)

It's very rare to actually need to use access types in Ada. Other than while 
learning the language, it's quite likely that you'll never encounter a situation 
in which you'll need them. So while it's important to learn how they work, you 
shouldn't be designing in terms of them.

My personal rules for designing with access types:

1. Don't use access types
2. If you think you need access types, see rule 1.
3. If you still think you need access types, don't use visible or anonymous 
access types
4. If you think you need visible or anonymous access types, see rule 3.
5. If you still think you need visible or anonymous access types, then you 
shouldn't design software.

-- 
Jeff Carter
"Gentlemen, you can't fight in here. This is the War Room!"
Dr. Strangelove
30

Re: grassroots thoughts on access types

[Dmitry A. Kazakov]

On 2018-02-09 18:01, Jeffrey R. Carter wrote:
> Others have responded to your questions. I'd like to mention my thoughts 
> on using access-to-object types (which I'll call "access types") in 
> general. (By "use", I'm referring to designing code with access types, 
> not to using them when required to in order to reuse existing code. 
> Gnoga, for example, requires you to supply some access values to use it.)
> 
> It's very rare to actually need to use access types in Ada. Other than 
> while learning the language, it's quite likely that you'll never 
> encounter a situation in which you'll need them. So while it's important 
> to learn how they work, you shouldn't be designing in terms of them.
> 
> My personal rules for designing with access types:
> 
> 1. Don't use access types
> 2. If you think you need access types, see rule 1.
> 3. If you still think you need access types, don't use visible or 
> anonymous access types
> 4. If you think you need visible or anonymous access types, see rule 3.
> 5. If you still think you need visible or anonymous access types, then 
> you shouldn't design software.

I mostly agree with that, yet there are some notable exceptions from 
these rules.

a. Dispatching operation. It cannot have a named access type. The 
conflicting design rule here is that *all* operations must be 
dispatching and any type must have a class.

b. Anonymous access type accepts arguments without explicit type 
conversion. Type conversions are always bad, ones exposing run-time 
hazard are more than bad.

c. Mix-in discriminant, anonymous access type is the only way in many 
cases. Mix-in itself is a horrid design pattern, but there is no 
multiple inheritance here to replace mix-in and no proper classes of 
protected and task types either.

In general, anonymous access type is the only way to enforce referential 
semantics. It would be great if Ada had it decoupled that from pointers. 
Unfortunately it did not.

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

Re: grassroots thoughts on access types

[Jeffrey R. Carter]

On 02/09/2018 06:19 PM, Dmitry A. Kazakov wrote:
> 
> a. Dispatching operation. It cannot have a named access type. The conflicting 
> design rule here is that *all* operations must be dispatching and any type must 
> have a class.

Anything that requires the use of anonymous access types is bad and should not 
be used.

-- 
Jeff Carter
"Gentlemen, you can't fight in here. This is the War Room!"
Dr. Strangelove
30

Re: grassroots thoughts on access types

[Robert A Duff]

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

> Anything that requires the use of anonymous access types is bad and
> should not be used.

So you won't use things like "A(X) := A(X) + 1;",
where A is a Vector?

Or "for X of A loop..."?

- Bob

Re: grassroots thoughts on access types

[Jeffrey R. Carter]

On 02/09/2018 09:17 PM, Robert A Duff wrote:
> 
> So you won't use things like "A(X) := A(X) + 1;",
> where A is a Vector?
> 
> Or "for X of A loop..."?

The language would be better if it didn't have anonymous access types. It 
follows that it would be better if it didn't have features that rely on 
anonymous access types.

-- 
Jeff Carter
"Gentlemen, you can't fight in here. This is the War Room!"
Dr. Strangelove
30

Re: grassroots thoughts on access types

[Dmitry A. Kazakov]

On 2018-02-09 22:44, Jeffrey R. Carter wrote:
> On 02/09/2018 09:17 PM, Robert A Duff wrote:
>>
>> So you won't use things like "A(X) := A(X) + 1;",
>> where A is a Vector?
>>
>> Or "for X of A loop..."?
> 
> The language would be better if it didn't have anonymous access types. 
> It follows that it would be better if it didn't have features that rely 
> on anonymous access types.

It does not follow. Usefulness of X is unrelated to whether X rely on Y.

Having said that, nether iteration interface nor indexing interface 
should rely on access types, anonymous or not. It is a language design 
flaw that they do. Nevertheless both interfaces are clearly useful and 
desirable.

Anonymous access type is an ugly hack to work around real language 
problems. It should have never been introduced. The problems should have 
been properly addressed instead.

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

Re: grassroots thoughts on access types

[Mehdi Saada]

For iteration, do you prefer the lighter alternative of GNAT's Iterable aspect ?
type List is private with
    Iterable => (First        => First_Cursor,
                 Next         => Advance,
                 Has_Element  => Cursor_Has_Element,
                [Element      => Get_Element]);

Though I haven't used it yet (but will as soon as I have to write an ADT), if I read well, "Cursor" can be anything, be it simple a mere integer: "a type declared in the container package or visible from it". It doesn't seem to need reference types with access discriminant.

Re: grassroots thoughts on access types

[Mehdi Saada]

To Simon Wright:
I think I can see what form will be allowed: dynamic allocaton in used-defined pools, using allocation mecanisms are proved whose delay is constant or at least predictible... on specific achitectures. That's what it would take for dynamic allocation to be provable and determinist, I suppose. Is that what you had in mind ?
Sorry if the choice of words wasn't perfect.

Re: grassroots thoughts on access types

[Jeffrey R. Carter]

On 02/10/2018 02:51 AM, Mehdi Saada wrote:
> To Simon Wright:
> I think I can see what form will be allowed: dynamic allocaton in used-defined pools, using allocation mecanisms are proved whose delay is constant or at least predictible... on specific achitectures. That's what it would take for dynamic allocation to be provable and determinist, I suppose. Is that what you had in mind ?

 From what I've seen, the proposed SPARK pointers are based on something like 
Rust's ownership concept.

-- 
Jeff Carter
"What lazy lout left these wires all over the lawn?"
Poppy
98

Re: grassroots thoughts on access types

[Mehdi Saada]

while we're at it, how would I write in SPARK
type Cell is
   record
      Next: access Cell;
      Value: Integer;
   end record;

Re: grassroots thoughts on access types

[Simon Wright]

Mehdi Saada <00120260a@gmail.com> writes:

> while we're at it, how would I write in SPARK
> type Cell is
>    record
>       Next: access Cell;
>       Value: Integer;
>    end record;

You might implement the container as an array, and the Next field would
be an index into the array (or some 'end of list' marker).

   type Base is range 0 .. N;
   subtype Index is Base range 1 .. Base'Last;
   End_Of_List : constant Base := 0;

   type Cell is record
      Next : Base := End_Of_List;
      Value : Integer;
   end record;

   type List is record
      Head : Base := End_Of_List;
      Contents : array (Index) of Cell;
   end record;

Re: grassroots thoughts on access types

[Jeffrey R. Carter]

On 02/10/2018 12:57 PM, Mehdi Saada wrote:
> while we're at it, how would I write in SPARK
> type Cell is
>     record
>        Next: access Cell;
>        Value: Integer;
>     end record;

You can't. SPARK doesn't have access types.

You could build a bounded list instead, or put a SPARK wrapper around 
Ada.Containers.Doubly_Linked_Lists (if you accept that it's correct).

-- 
Jeff Carter
"What lazy lout left these wires all over the lawn?"
Poppy
98

Re: grassroots thoughts on access types

[Mehdi Saada]

>It is semantically a pointer, an object that directly references another
object.

Well, you have a point, but aren't you a bit nitpicking ?
I think one can write:

type CONTAINER_TYPE is private
      with Iterable =>  (First        => First,
                         Next         => Next
                         Has_Element  => Has_Element,
                         Element      => Get);
type CURSOR is limited private;
type ELEMENT is new WHO_CARES;
function GET(LIST: COINTAINER_TYPE, CURSOR_OBJECT: CURSOR) return ELEMENT,
function FIRST(LIST: CONTAINER_TYPE) return CURSOR;
function NEXT(LIST: CONTAINER_TYPE, CURSOR_OBJECT: CURSOR) return CURSOR;
function HAS_ELEMENT(LIST: CONTAINER_TYPE, CURSOR_OBJECT: CURSOR) return BOOLEAN;

private

type CURSOR is POSITIVE;
type CONTAINER_TYPE is ...

there isn't much difference in my understanding between this numeric CURSOR and a regular array index type. None of the usual problem of dynamic allocation, dangling pointers, unchecked this-or-that here.
So I don't really see why it should be forbidden in secure, deterministic Ada subset.

Re: grassroots thoughts on access types

[Dmitry A. Kazakov]

On 2018-02-10 01:43, Mehdi Saada wrote:
> For iteration, do you prefer the lighter alternative of GNAT's Iterable aspect ?

Iteration is a construct/operation of an interface (ordered set). All 
you need is ordered set interface implemented by the corresponding type.

(Aspects are no less hacks than anonymous access type is)

> type List is private with
>      Iterable => (First        => First_Cursor,
>                   Next         => Advance,
>                   Has_Element  => Cursor_Has_Element,
>                  [Element      => Get_Element]);
> 
> Though I haven't used it yet (but will as soon as I have to write an ADT), if I read well, "Cursor" can be anything,

There should be no cursors, at least none when dealing with sets.

Cursors (= pointers) should be used only for low-level linked data 
structures, when ordered set interface implementation is too expensive. 
For example in the case of linked list or graph.

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

Re: grassroots thoughts on access types

[Mehdi Saada]

> Cursors (= pointers)
Based on GNAT RM, "a Cursor, which must a be a type declared in the container package or visible from it". That's all there is mentioned about the cursor type. Hence, it doesn't have to involve access types.
Either I'm right, either I'm wrong, but the RM is unclear.

Re: grassroots thoughts on access types

[Dmitry A. Kazakov]

On 2018-02-10 12:55, Mehdi Saada wrote:
>> Cursors (= pointers)
> Based on GNAT RM, "a Cursor, which must a be a type declared in the container package or visible from it". That's all there is mentioned about the cursor type. Hence, it doesn't have to involve access types.
> Either I'm right, either I'm wrong, but the RM is unclear.

It is semantically a pointer, an object that directly references another 
object.

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

Re: grassroots thoughts on access types

[Simon Wright]

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

> On 2018-02-10 12:55, Mehdi Saada wrote:
>>> Cursors (= pointers)
>> Based on GNAT RM, "a Cursor, which must a be a type declared in the
>> container package or visible from it". That's all there is mentioned
>> about the cursor type. Hence, it doesn't have to involve access
>> types.
>> Either I'm right, either I'm wrong, but the RM is unclear.
>
> It is semantically a pointer, an object that directly references
> another object.

And it contains a reference to the container it's a cursor for.

Re: grassroots thoughts on access types

[Dmitry A. Kazakov]

On 2018-02-10 17:51, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 2018-02-10 12:55, Mehdi Saada wrote:
>>>> Cursors (= pointers)
>>> Based on GNAT RM, "a Cursor, which must a be a type declared in the
>>> container package or visible from it". That's all there is mentioned
>>> about the cursor type. Hence, it doesn't have to involve access
>>> types.
>>> Either I'm right, either I'm wrong, but the RM is unclear.
>>
>> It is semantically a pointer, an object that directly references
>> another object.
> 
> And it contains a reference to the container it's a cursor for.

It could if there is a container object. In general case there is none 
or it is too expensive to get at the container from its element.

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

Re: grassroots thoughts on access types

[Jeffrey R. Carter]

On 02/09/2018 11:06 PM, Dmitry A. Kazakov wrote:
> 
> It does not follow. Usefulness of X is unrelated to whether X rely on Y.

I don't recall mentioning usefulness. But what I meant to say is that, since the 
language would be better without anonymous access types, that better language 
could not have features that rely on anonymous access types.

-- 
Jeff Carter
"What lazy lout left these wires all over the lawn?"
Poppy
98

Re: grassroots thoughts on access types

[Dmitry A. Kazakov]

On 2018-02-10 11:03, Jeffrey R. Carter wrote:
> On 02/09/2018 11:06 PM, Dmitry A. Kazakov wrote:
>>
>> It does not follow. Usefulness of X is unrelated to whether X rely on Y.
> 
> I don't recall mentioning usefulness. But what I meant to say is that, 
> since the language would be better without anonymous access types, that 
> better language could not have features that rely on anonymous access 
> types.

Which is a logical fallacy. In order to be true you must show that either:

1. These feature are bad as they are regardless what they rely on

2. They cannot be implemented otherwise *and* their usefulness does not 
outweigh the damage of access types.

Both are evidently untrue.

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

Re: grassroots thoughts on access types

[Jeffrey R. Carter]

On 02/10/2018 11:36 AM, Dmitry A. Kazakov wrote:
> 
> Which is a logical fallacy. In order to be true you must show that either:
> 
> 1. These feature are bad as they are regardless what they rely on
> 
> 2. They cannot be implemented otherwise *and* their usefulness does not outweigh 
> the damage of access types.
> 
> Both are evidently untrue.

I don't understand. I said a language that doesn't have anonymous access types 
cannot have features that rely on anonymous access types. By that I mean such a 
language cannot provide a feature that requires the user to write an anonymous 
access type.

I did not say that such a language cannot have any specific feature; only that 
such a language cannot have an implementation that relies on anonymous access 
types of any feature.

This seems to be a tautology to me.

Can you show me how a language that doesn't have anonymous access types can have 
features that rely on anonymous access types?

-- 
Jeff Carter
"What lazy lout left these wires all over the lawn?"
Poppy
98

Re: grassroots thoughts on access types

[Dmitry A. Kazakov]

On 2018-02-10 12:12, Jeffrey R. Carter wrote:
> On 02/10/2018 11:36 AM, Dmitry A. Kazakov wrote:
>>
>> Which is a logical fallacy. In order to be true you must show that 
>> either:
>>
>> 1. These feature are bad as they are regardless what they rely on
>>
>> 2. They cannot be implemented otherwise *and* their usefulness does 
>> not outweigh the damage of access types.
>>
>> Both are evidently untrue.
> 
> I don't understand. I said a language that doesn't have anonymous access 
> types cannot have features that rely on anonymous access types. By that 
> I mean such a language cannot provide a feature that requires the user 
> to write an anonymous access type.
> 
> I did not say that such a language cannot have any specific feature; 
> only that such a language cannot have an implementation that relies on 
> anonymous access types of any feature.
> 
> This seems to be a tautology to me.
> 
> Can you show me how a language that doesn't have anonymous access types 
> can have features that rely on anonymous access types?

Ada 83 has String type implemented without pointers. Ada 83 has

   A(X) := A(X) + 1

working with arrays, again, no pointers.

Why must Ada 2005 use access types for having this with containers? It 
must not. Should it have this feature still. Certainly.

Pointers is a easy way to work around most of language problems at the 
cost of software design.

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

Re: grassroots thoughts on access types

[Robert A Duff]

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

> On 02/09/2018 09:17 PM, Robert A Duff wrote:
>>
>> So you won't use things like "A(X) := A(X) + 1;",
>> where A is a Vector?
>>
>> Or "for X of A loop..."?
>
> The language would be better if it didn't have anonymous access
> types. It follows that it would be better if it didn't have features
> that rely on anonymous access types.

Perhaps, but I don't think you answered my question.
Earlier, you said:

    Anything that requires the use of anonymous access types is bad and
    should not be used.

and I am curious what you meant by that.
Vectors allow syntactic sugar like "A(X) := A(X) + 1;",
and this syntactic sugar relies on access discriminants,
which are of anonymous access types.  Do you avoid using
that syntactic sugar?

I understand that you would prefer a different language
design in this area.  (So would I!)  But given the
language as it is, I use the syntactic sugar.  Do you?

- Bob

Re: grassroots thoughts on access types

[Jeffrey R. Carter]

On 02/10/2018 10:16 PM, Robert A Duff wrote:
> 
> Vectors allow syntactic sugar like "A(X) := A(X) + 1;",
> and this syntactic sugar relies on access discriminants,
> which are of anonymous access types.  Do you avoid using
> that syntactic sugar?

I don't use Ada 12 because it's only supported by one compiler, so I don't use 
these forms. But that doesn't answer your question, either.

There are no anonymous access types in your examples of using these forms 
because using them doesn't require writing any. So if I used Ada 12 I wouldn't 
have any real problem with using such forms for constructs that already provide 
them. However, since I won't write any anonymous access types, I would not 
provide the ability to use such forms with anything I wrote. As it might be 
confusing to use these forms with some constructs and not with others, my code 
would probably be easier to read if I eschewed such forms.

-- 
Jeff Carter
"When Bell Labs were invited to evaluate C against the DoD requirements
[for Ada], they said that there was no chance of C meeting the
requirements of readability, safety, etc. for which we were striving,
and that it should not even be on the list of evaluated languages."
William Whitaker
116

Re: grassroots thoughts on access types

[Robert A Duff]

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

> I don't use Ada 12 because it's only supported by one compiler, so I
> don't use these forms. But that doesn't answer your question, either.
>
> There are no anonymous access types in your examples of using these
> forms because using them doesn't require writing any. So if I used Ada
> 12 I wouldn't have any real problem with using such forms for constructs
> that already provide them. However, since I won't write any anonymous
> access types, I would not provide the ability to use such forms with
> anything I wrote. As it might be confusing to use these forms with some
> constructs and not with others, my code would probably be easier to read
> if I eschewed such forms.

Understood.  Thanks.

For what it's worth, I found the containers packages to
be almost intolerable to use until the syntactic sugar was
added.  I don't particularly like how one defines types
with such syntactic sugar, but using it is easy.

- Bob

Re: grassroots thoughts on access types

[Shark8]

On Friday, February 9, 2018 at 12:12:05 PM UTC-7, Jeffrey R. Carter wrote:
> On 02/09/2018 06:19 PM, Dmitry A. Kazakov wrote:
> > 
> > a. Dispatching operation. It cannot have a named access type. The conflicting 
> > design rule here is that *all* operations must be dispatching and any type must 
> > have a class.
> 
> Anything that requires the use of anonymous access types is bad and should not be used.

Streams & Generic_Dispatching_Constructor, unfortunately, both rely on access types. :(

Re: grassroots thoughts on access types

[G. B.]

Mehdi Saada <00120260a@gmail.com> wrote:
> In my corrected exercices, I can read:
> 
> package P_Token.F is
>    type T_Ptr_Token is access all T_Token'Class;
> end P_Token.F;

As a matter of style this makes me think that
someone seems well versed in using Turbo Pascal and C++.
Trying to transform idioms from said languages into Ada 
won’t help when trying to put the language to good use.
As seen, there will be all kinds of pointer stuff.

To mimic constructors using functions is one such attempt, I think.

Re: grassroots thoughts on access types

[Mehdi Saada]

> As a matter of style this makes me think that
> someone seems well versed in using Turbo Pascal and C++.
> Trying to transform idioms from said languages into Ada 
> won’t help when trying to put the language to good use.
> As seen, there will be all kinds of pointer stuff.
> 
> To mimic constructors using functions is one such attempt, I think.

Interesting, so I can't trust the one person that made my course, to provide me with good habits and programming mindset. I was surprised to see pointers being used like this, while the course says Ada is made to provide OOP without explicit (nor implicit) access types. I hope there are good books online about good practices ? Perhaps do you have a website yourself, G.B. ?