type access Parent'Class

type access Parent'Class

[Yukicanis]

Dear Group,

I'm new to Ada and currently playing around with its OOP features.
Now, I have the following source:

procedure Test is
  type Parent is tagged limited null record;
  type Parent_Access is access Parent'Class;
  A : access Parent'Class;
  B : Parent_Access;
  procedure Dyn_Disp(X : access Parent'Class) is
  begin
    A := X;
    B := X;
  end Dyn_Disp;
begin
  null;
end Test;

When I try to complie that with GNAT 4.6.1 I get the following error
message:

test.adb:9:10: expected type "Parent_Access" defined at line 3
test.adb:9:10: found type access to "Parent'Class" defined at line 6

which I don't really understand since type "Parent_Access" is type
access to Parent'Class, isn't it?

Thanks in advance.

Re: type access Parent'Class

[Adam Beneschan]

On Nov 21, 11:03 am, Yukicanis <yukica...@googlemail.com> wrote:
> Dear Group,
>
> I'm new to Ada and currently playing around with its OOP features.
> Now, I have the following source:
>
> procedure Test is
>   type Parent is tagged limited null record;
>   type Parent_Access is access Parent'Class;
>   A : access Parent'Class;
>   B : Parent_Access;
>   procedure Dyn_Disp(X : access Parent'Class) is
>   begin
>     A := X;
>     B := X;
>   end Dyn_Disp;
> begin
>   null;
> end Test;
>
> When I try to complie that with GNAT 4.6.1 I get the following error
> message:
>
> test.adb:9:10: expected type "Parent_Access" defined at line 3
> test.adb:9:10: found type access to "Parent'Class" defined at line 6
>
> which I don't really understand since type "Parent_Access" is type
> access to Parent'Class, isn't it?
>
> Thanks in advance.

Ada is a strongly typed language.  That means that you can have two
types that look exactly the same but are still different types,
because you've declared them as different types, and you can't just
use them interchangeably.  Example:

  type Acc_Type_1 is access all Integer;
  type Acc_Type_2 is access all Integer;
  V1 : Acc_Type_1;
  V2 : Acc_Type_2;

  V1 := V2;     -- ILLEGAL!

This is illegal because V1 and V2 have different types, even though
the types look the same.  You have to use a type conversion:

  V1 := Acc_Type_1(V2);  -- LEGAL

This doesn't have anything to do with access types, by the way.  All
types in Ada are like that.

In your original example, "access Parent'Class" is an anonymous type,
and every time an anonymous type occurs, it's a new type.  So that's
why

  B := X;

is illegal.  You have to use a type conversion:

  B := Parent_Access(X);

That still won't quite work, because anonymous access types are
"general" access types and their values can point to any aliased
Parent'Class object.  However, Parent_Access is called a "pool-
specific" access type because it can only point to objects that are
allocated with "new".  To make Parent_Access a general access type,
add an "all":

  type Parent_Access is access all Parent'Class;

and now your example will compile.  In my view, there isn't much
reason *not* to use "all" in an access type declaration, and I've
gotten in the habit of including it routinely.  (But you can't use
"all" like this if it's not in a TYPE declaration.)

The language allows

  A := X;

even though A and X have different types, because there's no way to
write a type conversion.  This is an exception to the strong-typing
rules.

Hope this helps,

                         -- Adam

Re: type access Parent'Class

[Robert A Duff]

Yukicanis <yukicanis@googlemail.com> writes:

> Dear Group,
>
> I'm new to Ada and currently playing around with its OOP features.
> Now, I have the following source:
>
> procedure Test is
>   type Parent is tagged limited null record;
>   type Parent_Access is access Parent'Class;
>   A : access Parent'Class;
>   B : Parent_Access;
>   procedure Dyn_Disp(X : access Parent'Class) is
>   begin
>     A := X;
>     B := X;
>   end Dyn_Disp;
> begin
>   null;
> end Test;
>
> When I try to complie that with GNAT 4.6.1 I get the following error
> message:
>
> test.adb:9:10: expected type "Parent_Access" defined at line 3
> test.adb:9:10: found type access to "Parent'Class" defined at line 6
>
> which I don't really understand since type "Parent_Access" is type
> access to Parent'Class, isn't it?

No, there are three different access types -- Parent_Access,
the anonymous type of A, and the anonymous type of X.  They're all
"access to Parent'Class", but they are distinct.

There are some implicit conversion rules that make "A := X;" legal.
But there is no implicit conversion to Parent_Access, so "B := X;"
is illegal.

You normally want access-to-class-wide types (and many other access
types) to be "general", which is specified by adding "all":

    type Parent_Access is access all Parent'Class;

If you do that, then you could say "B := Parent_Access(X);"
or "B := A.all'Access;".

But I suggest you avoid anonymous access types, except in certain
special cases.  They are confusing.

I also suggest you put most of your code in packages, rather than
in the main procedure.  That will also help avoid confusion, because
things behave differently when inside procedures.  For example,
you can't have any dispatching procedures unless you put the type
in a package spec.

- Bob

Re: type access Parent'Class

[Yukicanis]

On Nov 21, 8:25 pm, Adam Beneschan <a...@irvine.com> wrote:
> On Nov 21, 11:03 am, Yukicanis <yukica...@googlemail.com> wrote:
>
>
>
>
>
>
>
>
>
> > Dear Group,
>
> > I'm new to Ada and currently playing around with its OOP features.
> > Now, I have the following source:
>
> > procedure Test is
> >   type Parent is tagged limited null record;
> >   type Parent_Access is access Parent'Class;
> >   A : access Parent'Class;
> >   B : Parent_Access;
> >   procedure Dyn_Disp(X : access Parent'Class) is
> >   begin
> >     A := X;
> >     B := X;
> >   end Dyn_Disp;
> > begin
> >   null;
> > end Test;
>
> > When I try to complie that with GNAT 4.6.1 I get the following error
> > message:
>
> > test.adb:9:10: expected type "Parent_Access" defined at line 3
> > test.adb:9:10: found type access to "Parent'Class" defined at line 6
>
> > which I don't really understand since type "Parent_Access" is type
> > access to Parent'Class, isn't it?
>
> > Thanks in advance.
>
> Ada is a strongly typed language.  That means that you can have two
> types that look exactly the same but are still different types,
> because you've declared them as different types, and you can't just
> use them interchangeably.  Example:
>
>   type Acc_Type_1 is access all Integer;
>   type Acc_Type_2 is access all Integer;
>   V1 : Acc_Type_1;
>   V2 : Acc_Type_2;
>
>   V1 := V2;     -- ILLEGAL!
>
> This is illegal because V1 and V2 have different types, even though
> the types look the same.  You have to use a type conversion:
>
>   V1 := Acc_Type_1(V2);  -- LEGAL
>
> This doesn't have anything to do with access types, by the way.  All
> types in Ada are like that.
>
> In your original example, "access Parent'Class" is an anonymous type,
> and every time an anonymous type occurs, it's a new type.  So that's
> why
>
>   B := X;
>
> is illegal.  You have to use a type conversion:
>
>   B := Parent_Access(X);
>
> That still won't quite work, because anonymous access types are
> "general" access types and their values can point to any aliased
> Parent'Class object.  However, Parent_Access is called a "pool-
> specific" access type because it can only point to objects that are
> allocated with "new".  To make Parent_Access a general access type,
> add an "all":
>
>   type Parent_Access is access all Parent'Class;
>
> and now your example will compile.  In my view, there isn't much
> reason *not* to use "all" in an access type declaration, and I've
> gotten in the habit of including it routinely.  (But you can't use
> "all" like this if it's not in a TYPE declaration.)
>
> The language allows
>
>   A := X;
>
> even though A and X have different types, because there's no way to
> write a type conversion.  This is an exception to the strong-typing
> rules.
>
> Hope this helps,
>
>                          -- Adam

Yes, that helps me a lot! That you very much!

BTW, I just discovered that

    B := A.all'Access;

also seems to work (with access all). But won't the rigth hand side
result in an anonymous type again?

Thanks in advance.

Re: type access Parent'Class

[Yukicanis]

On Nov 21, 8:33 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Yukicanis <yukica...@googlemail.com> writes:
> > Dear Group,
>
> > I'm new to Ada and currently playing around with its OOP features.
> > Now, I have the following source:
>
> > procedure Test is
> >   type Parent is tagged limited null record;
> >   type Parent_Access is access Parent'Class;
> >   A : access Parent'Class;
> >   B : Parent_Access;
> >   procedure Dyn_Disp(X : access Parent'Class) is
> >   begin
> >     A := X;
> >     B := X;
> >   end Dyn_Disp;
> > begin
> >   null;
> > end Test;
>
> > When I try to complie that with GNAT 4.6.1 I get the following error
> > message:
>
> > test.adb:9:10: expected type "Parent_Access" defined at line 3
> > test.adb:9:10: found type access to "Parent'Class" defined at line 6
>
> > which I don't really understand since type "Parent_Access" is type
> > access to Parent'Class, isn't it?
>
> No, there are three different access types -- Parent_Access,
> the anonymous type of A, and the anonymous type of X.  They're all
> "access to Parent'Class", but they are distinct.
>
> There are some implicit conversion rules that make "A := X;" legal.
> But there is no implicit conversion to Parent_Access, so "B := X;"
> is illegal.
>
> You normally want access-to-class-wide types (and many other access
> types) to be "general", which is specified by adding "all":
>
>     type Parent_Access is access all Parent'Class;
>
> If you do that, then you could say "B := Parent_Access(X);"
> or "B := A.all'Access;".
>
> But I suggest you avoid anonymous access types, except in certain
> special cases.  They are confusing.
>
> I also suggest you put most of your code in packages, rather than
> in the main procedure.  That will also help avoid confusion, because
> things behave differently when inside procedures.  For example,
> you can't have any dispatching procedures unless you put the type
> in a package spec.
>
> - Bob

Thanks for your replay. I know that things behave differnetly in
packages. I just wanted the minimal example to be as short es possible
to avoid spamming.

Re: type access Parent'Class

[Robert A Duff]

Yukicanis <yukicanis@googlemail.com> writes:

> BTW, I just discovered that
>
>     B := A.all'Access;
>
> also seems to work (with access all). But won't the rigth hand side
> result in an anonymous type again?

No, the type of Blah'Access is always taken from the context
(the expected type, which is the (named) type of B in this case).

- Bob

Re: type access Parent'Class

[Yukicanis]

On Nov 21, 8:45 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Yukicanis <yukica...@googlemail.com> writes:
> > BTW, I just discovered that
>
> >     B := A.all'Access;
>
> > also seems to work (with access all). But won't the rigth hand side
> > result in an anonymous type again?
>
> No, the type of Blah'Access is always taken from the context
> (the expected type, which is the (named) type of B in this case).
>
> - Bob

Thank you very much! Everything seems to be clean now. :)

Re: type access Parent'Class

[Jeffrey Carter]

On 11/21/2011 12:03 PM, Yukicanis wrote:
>
> procedure Test is
>    type Parent is tagged limited null record;
>    type Parent_Access is access Parent'Class;
>    A : access Parent'Class;
>    B : Parent_Access;
>    procedure Dyn_Disp(X : access Parent'Class) is
>    begin
>      A := X;
>      B := X;
>    end Dyn_Disp;
> begin
>    null;
> end Test;
>
> When I try to complie that with GNAT 4.6.1 I get the following error
> message:
>
> test.adb:9:10: expected type "Parent_Access" defined at line 3
> test.adb:9:10: found type access to "Parent'Class" defined at line 6
>
> which I don't really understand since type "Parent_Access" is type
> access to Parent'Class, isn't it?

The message should really say "found anonymous type access to ...", which points 
to the solution: don't use anonymous types.

-- 
Jeff Carter
"My mind is aglow with whirling, transient nodes of
thought, careening through a cosmic vapor of invention."
Blazing Saddles
85

Re: type access Parent'Class

[Gene]

On Nov 21, 8:25 pm, Adam Beneschan <a...@irvine.com> wrote:
> On Nov 21, 11:03 am, Yukicanis <yukica...@googlemail.com> wrote:
>
>
>
>
>
> > Dear Group,
>
> > I'm new to Ada and currently playing around with its OOP features.
> > Now, I have the following source:
>
> > procedure Test is
> >   type Parent is tagged limited null record;
> >   type Parent_Access is access Parent'Class;
> >   A : access Parent'Class;
> >   B : Parent_Access;
> >   procedure Dyn_Disp(X : access Parent'Class) is
> >   begin
> >     A := X;
> >     B := X;
> >   end Dyn_Disp;
> > begin
> >   null;
> > end Test;
>
> > When I try to complie that with GNAT 4.6.1 I get the following error
> > message:
>
> > test.adb:9:10: expected type "Parent_Access" defined at line 3
> > test.adb:9:10: found type access to "Parent'Class" defined at line 6
>
> > which I don't really understand since type "Parent_Access" is type
> > access to Parent'Class, isn't it?
>
> > Thanks in advance.
>
> Ada is a strongly typed language.  That means that you can have two
> types that look exactly the same but are still different types,
> because you've declared them as different types, and you can't just
> use them interchangeably.  Example:

Strong typing doesn't isn't quite the right explanation.  Rather I
think you want to say that Ada type equality and compatibility are
defined in terms of static type names. There is also the rule that
anonymous types are inequivalent to any other type.

However, there exist languages that are strongly typed that don't rely
(at least entirely) on name equivalence. Rather they use some
variation of structural equivalence. ML is in this category.

Re: type access Parent'Class

[Dmitry A. Kazakov]

On Mon, 21 Nov 2011 15:45:24 -0800 (PST), Gene wrote:

> However, there exist languages that are strongly typed that don't rely
> (at least entirely) on name equivalence. Rather they use some
> variation of structural equivalence. ML is in this category.

Now, if the type behavior is indeterminable from the type's structure, then
structured equivalence imply weak typing = the behavior varies with the
interpretation. Otherwise (the behavior is exhaustively determined by
type's structure) the type system is weak. I don't really know ML, so I can
only suggest that it falls into the first category.

P.S. Strong typing became a kind of fashion. In these days almost any
language claims to be strongly typed.

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

Re: type access Parent'Class

[Georg Bauhaus]

On 22.11.11 09:42, Dmitry A. Kazakov wrote:
> On Mon, 21 Nov 2011 15:45:24 -0800 (PST), Gene wrote:
>
>> However, there exist languages that are strongly typed that don't rely
>> (at least entirely) on name equivalence. Rather they use some
>> variation of structural equivalence. ML is in this category.
>
> Now, if the type behavior is indeterminable from the type's structure, then
> structured equivalence imply weak typing = the behavior varies with the
> interpretation. Otherwise (the behavior is exhaustively determined by
> type's structure) the type system is weak. I don't really know ML, so I can
> only suggest that it falls into the first category.
>
> P.S. Strong typing became a kind of fashion. In these days almost any
> language claims to be strongly typed.

Nice to see people discuss variations of type systems; the following
quote is from notes on reading Haskell programs, for Python programmers,
http://blog.ezyang.com/2011/11/how-to-read-haskell/ .


"Types. Ignore everything you see after :: (similarly, you can ignore type,
  class, instance and newtype. Some people claim that types help them
  understand code; if you're a complete beginner, things like Int and String
  will probably help, and things like LayoutClass and MonadError won't.
  Don't worry too much about it.)"

I am not sure whether or not this is good advice, since indeed beginners
might see types as yet another hurdle that gets in the way of understanding
how things work. But this advice addresses Python programmers, not
people new to programming.  Right now I am seeing, again, what it
means to rewrite portions of a program when there is no static type
system (and no parameter naming). Think of subprograms that have
defaulted parameters, now drop one parameter, permute their order,
... and no compiler (sometimes not even pylint) telling you that this
*will* *cause* a type error at run time---as is the case with Python.
__
Did the author (intentionally) miss the fact that monads, TTBOMK, add
a formal framework for reasoning (somewhat) about I/O in purely
functional programs? If not in terms of time and space, then
surely in terms of data flowing into, flowing through, and flowing
out of functions-whose-profile-includes-world? Ada's I/O related types
kind of allows this, I'd think, to the extent that one can answer
questions: "Which units call operations on types having to
do with I/O"?

Re: type access Parent'Class

[Simon Wright]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> Right now I am seeing, again, what it means to rewrite portions of a
> program when there is no static type system (and no parameter naming).

I can see your point if you mean no parameter _typing_ ...

Re: type access Parent'Class

[Georg Bauhaus]

On 22.11.11 14:27, Simon Wright wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
> 
>> Right now I am seeing, again, what it means to rewrite portions of a
>> program when there is no static type system (and no parameter naming).
> 
> I can see your point if you mean no parameter _typing_ ...

Yes, though both static typing and naming of parameters will have an
effect, insofar as the Python interpreter will report a type error
in case I mistype a parameter name.  Pylint will catch the error
at "compile time":

$ cat catch.py

def newline(times=1):
    for run in range(times):
        print

newline()
newline(count=2)



$ pylint --errors-only catch.py
No config file found, using default configuration
************* Module catch
E:  7: Passing unexpected keyword argument 'count' in function call


$ python catch.py

Traceback (most recent call last):
  File "catch.py", line 7, in <module>
    newline(count=2)
TypeError: newline() got an unexpected keyword argument 'count'

Re: type access Parent'Class

[Yannick Duchêne (Hibou57)]

Le Mon, 21 Nov 2011 20:33:22 +0100, Robert A Duff  
<bobduff@shell01.theworld.com> a écrit:
> I also suggest you put most of your code in packages, rather than
> in the main procedure.  That will also help avoid confusion, because
> things behave differently when inside procedures.  For example,
> you can't have any dispatching procedures unless you put the type
> in a package spec.
And also because Access to stuffs at library level is often more handy and  
more general.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: [Epigrams on Programming — Alan J. — P. Yale University]

Re: type access Parent'Class

[Yukicanis]

On 24 Nov., 11:33, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> Le Mon, 21 Nov 2011 20:33:22 +0100, Robert A Duff
> <bobd...@shell01.theworld.com> a écrit:> I also suggest you put most of your code in packages, rather than
> > in the main procedure.  That will also help avoid confusion, because
> > things behave differently when inside procedures.  For example,
> > you can't have any dispatching procedures unless you put the type
> > in a package spec.
>
> And also because Access to stuffs at library level is often more handy and
> more general.
>
> --
> “Syntactic sugar causes cancer of the semi-colons.” [1]
> “Structured Programming supports the law of the excluded muddle.” [1]
> [1]: [Epigrams on Programming — Alan J. — P. Yale University]

Indeed. When I use C++, I also put every class in its own file. So I
do with Ada.

Thanks to everyone. It's nice to have this group. :)