Re: *\\~record depth~//*

Re: *\\~record depth~//*

[Nick Roberts]

G wrote:
> ...
> I would have thought (my grasp of symbolic logic being as admittedly
> limited as it is) that placing a Simple_Problem within the Complex_
> Problem type would fluff with the compiler. Would there be any 
> programming situations where this sort of thing would apply or is it 
> toally irrelevant ?  

Absolutely not. It's very important to many programming situations to be
able to do this sort of thing.

For example, supposing we have a type:

   type Graphical_Object is abstract tagged null record;

which comes with an operation to draw it on (say) a computer screen:

   procedure Draw (Object: in Graphical_Object) is abstract;

we may derive some obvious types from this:

   type Circle is new Graphical_Object with
      record
         Centre: Raster_Point;
         Radius: Distance;
      end record;

   type Point_Array is array (Positive range <>) of Raster_Point;

   type Polygon (Order: Natural) is new Graphical_Object with
      record
         Corners: Point_Array(1..Order);
      end record;

and so on. However, we might then want ot derive a type which is simply
a collection of other objects:

   type Graphical_Object_Access is access all Graphical_Object'Class;

   type Graphical_Object_Array is 
                array (Positive range <>) of Graphical_Object_Access;

   type Compound_Object (Order: Natural) is new Graphical_Object with
      record
         Cmpts: Graphical_Object_Array(1..Order);
      end record;

Here we have the classic scenario of a widget containing a
wotchamacallit, a wotchamacallit containing an oojamagazzit, and an
oojamagazzit containing more widgets. This sort of thing crops up in
programming all the time.

> If records are included within abstractions of themselves would that
> make it unneccessarily complex to assign properties to instances of
> the records/objects ?

Not at all. Consider my example above. If we had an object Warning_Sign
of type Compound_Object, we could (declare and) initialise it as
follows:

   Warning_Sign: constant Compound_Object :=
   (2, (new Circle'((250,150),50.0), 
        new Polygon'(4, ((100,200),(100,100),(200,100),(200,200)))));

No problem! Furthermore, we can define how to draw compound objects
easily:

   procedure Draw (Object: in Compound_Object) is
   begin
      for i in 1..Object.Order loop
         Draw(Object.Cmpts(i));
      end loop;
   end;

Note how it's possible to have compound objects containing other
compound objects, nested to any depth, and also how this simple
algorithm will nevertheless draw any such compound object correctly (by
automatically recursing as necessary).

-- 
Nick Roberts
Computer Consultant (UK)
http://www.callnetuk.com/home/nickroberts
http://www.adapower.com/lab/adaos

*\\~record depth~//*

[G]

  I am still learning (autodidactically) what is probably painfully
silly and simple to many of you.
However - I use the Gnat compiler to learn what is possible (though
not necessarily sensible) in Ada.

  Some time ago Matt Heaney explained to me here that a record
declaration
must only contain elements which are delimited (perhaps not in those
exact words)
   I was playing with types tonight and I found that I could extend one
tagged record such that I may
include the record from which it was extended in its element list.

----------------------------------------------------------------------------------------

package Problem is

              -- a PROBLEM is defined by its COMPONENTs and their
ACTIONs.

  type Component is (Single, Dependent, Group);           -- for e.g.
  type Component_List is array (Component'First..Component'Last) of
Component;

            -- type Action is (Direct, Indirect); --

  type Simple_Problem is tagged
  record
    Unit : Component;          --  a Unit
  end record;

  type Complex_Problem is new Simple_Problem with
  record
    Simple_Structure : Component_List;          -- deeper STRUCTURE
    Simple_Recursive_Reference : Simple_Problem;
  end record;

  type Compound_Problem is new Complex_Problem with
  record
    Complex_Structure : Component_List;           -- even deeper
STRUCTURE
    Complex_Recursive_Reference : Complex_Problem;
  end record;

end Problem;
------------------------------------------------------------------------------

I would have thought (my grasp of symbolic logic being as admittedly
limited
as it is) that placing a Simple_Problem within the Complex_Problem type
would fluff with the compiler, but it didn't.  So, obviously one may do
this sort of thing 'legally' in Ada.

Would there be any programming situations where this sort of thing would
apply
or is it toally irrelevant ?  If records are included within
abstractions of themselves
would that make it unneccessarily complex to assign properties to
instances
of the records/objects ?

possibility 1) - you will tell me it is totally silly

possibility 2) - you will tell me some horrendously complex tale of
syntax and simpler ways of doing
                      precisely the same things.

I am just wondering out loud and as I have this wonderful facility of
communication with the
boffins I thought I would ask.


-Graeme
-Australia

oops - same with neater formatting

[G]

> ---------------------------
>
> package Problem is
>
>
>   type Component is (Single, Dependent, Group);
>   type Component_List is array (Component'First..Component'Last) of
> Component;
>
>
>
>   type Simple_Problem is tagged
>   record
>     Unit : Component;
>   end record;
>
>   type Complex_Problem is new Simple_Problem with
>   record
>     Simple_Structure : Component_List;
>     Simple_Recursive_Reference : Simple_Problem;
>   end record;
>
>   type Compound_Problem is new Complex_Problem with
>   record
>     Complex_Structure : Component_List;
>
>     Complex_Recursive_Reference : Complex_Problem;
>   end record;
>
> end Problem;
> ------------------------------------------------------------------------------

Re: *\\~record depth~//*

[Robert Dewar]

In article <3827113A.DCFE454A@callnetuk.com>,
  Nick Roberts <nickroberts@callnetuk.com> wrote:

<<very nice discussion of why this might be useful snipped>>

Note that even if it were not useful, it is obviously well
defined, and the semantics are trouble free. The Ada design
is not in the business of forbidding things for no good reason,
and "we can't think of a useful use" is NOT a good reason
for forbidding things.

There are things that are forbidden arbitrarily, but there is
a good reason for the rule. For example, it is an angularity
in the language that out parameters are not allowed in
procedures, but this restriction is there very deliberately,
because lots of people think it is an important methodological
restriction (as everyone knows, I strongly disagree with this
particular viewpoint, and this point continues to be argued).

But if anyone tried to argue for introducing an arbitrary
restriction that made the language description more complex
and the best argument they could come up with was "this use
of this particular feature doesn't seem to be useful, so let's
not allow it", they would not get very far!

Indeed, it is often the case that things turn out to be useful
which were not specifically understood as useful in advance.
It takes time to learn all the interesting ways that the
features of a language like Ada can work together.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: *\\~record depth~//*

[David C. Hoos, Sr.]

Robert Dewar <robert_dewar@my-deja.com> wrote in message
news:8087ch$5is$1@nnrp1.deja.com...
> In article <3827113A.DCFE454A@callnetuk.com>,
>   Nick Roberts <nickroberts@callnetuk.com> wrote:
>
> <<very nice discussion of why this might be useful snipped>>
<snip>
> For example, it is an angularity
> in the language that out parameters are not allowed in
> procedures, but this restriction is there very deliberately,
> because lots of people think it is an important methodological
> restriction (as everyone knows, I strongly disagree with this
> particular viewpoint, and this point continues to be argued).

Did you mean "out parameters are not allowed in _functions_"?

Re: *\\~record depth~//*

[Robert Dewar]

In article <8093fl$205$1@oak.prod.itd.earthlink.net>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
> Did you mean "out parameters are not allowed in _functions_"?


Yes, indeed, slip of the finger (or more likely of the mind :-)
thanks for correcting this for me.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: *\\~record depth~//*

[Mario Amado Alves]

The structure may in fact happen in real problems, e.g. lexical
knowledge bases, default inheritance networks.

You know you can write

  type Component_List is array (Component'Range)

instead of

  type Component_List is array (Component'First..Component'Last)

.


On Tue, 9 Nov 1999, G wrote:

>  Message from the Deja.com forum: 
>  comp.lang.ada
>  Your subscription is set to individual email delivery
> > 
>   I am still learning (autodidactically) what is probably painfully
> silly and simple to many of you.
> However - I use the Gnat compiler to learn what is possible (though
> not necessarily sensible) in Ada.
> 
>   Some time ago Matt Heaney explained to me here that a record
> declaration
> must only contain elements which are delimited (perhaps not in those
> exact words)
>    I was playing with types tonight and I found that I could extend one
> tagged record such that I may
> include the record from which it was extended in its element list.
> 
> ----------------------------------------------------------------------------------------
> 
> package Problem is
> 
>               -- a PROBLEM is defined by its COMPONENTs and their
> ACTIONs.
> 
>   type Component is (Single, Dependent, Group);           -- for e.g.
>   type Component_List is array (Component'First..Component'Last) of
> Component;
> 
>             -- type Action is (Direct, Indirect); --
> 
>   type Simple_Problem is tagged
>   record
>     Unit : Component;          --  a Unit
>   end record;
> 
>   type Complex_Problem is new Simple_Problem with
>   record
>     Simple_Structure : Component_List;          -- deeper STRUCTURE
>     Simple_Recursive_Reference : Simple_Problem;
>   end record;
> 
>   type Compound_Problem is new Complex_Problem with
>   record
>     Complex_Structure : Component_List;           -- even deeper
> STRUCTURE
>     Complex_Recursive_Reference : Complex_Problem;
>   end record;
> 
> end Problem;
> ------------------------------------------------------------------------------
> 
> I would have thought (my grasp of symbolic logic being as admittedly
> limited
> as it is) that placing a Simple_Problem within the Complex_Problem type
> would fluff with the compiler, but it didn't.  So, obviously one may do
> this sort of thing 'legally' in Ada.
> 
> Would there be any programming situations where this sort of thing would
> apply
> or is it toally irrelevant ?  If records are included within
> abstractions of themselves
> would that make it unneccessarily complex to assign properties to
> instances
> of the records/objects ?
> 
> possibility 1) - you will tell me it is totally silly
> 
> possibility 2) - you will tell me some horrendously complex tale of
> syntax and simpler ways of doing
>                       precisely the same things.
> 
> I am just wondering out loud and as I have this wonderful facility of
> communication with the
> boffins I thought I would ask.
> 
> 
> -Graeme
> -Australia
> 
> 
> 
> 
>  _____________________________________________________________
>  Deja.com: Before you buy.
>  http://www.deja.com/
>  * To modify or remove your subscription, go to
>  http://www.deja.com/edit_sub.xp?group=comp.lang.ada
>  * Read this thread at
>  http://www.deja.com/thread/%3C3826DFBF.52AC2680%40interact.net.au%3E
> 

| | |,| | | | |RuaFrancTaborda24RcD 2815-249CharnecaCaparica 351+212976751
| |M|A|R|I|O| |                                              mob 219354005
| |A|M|A|D|O| |DepartmentoInformaticFCT/UNL 2825-114Caparica 351+212958536
| |A|L|V|E|S| |                                              fax 212948541
| | | | | | | |               maa@di.fct.unl.pt              FCT 212948300



 Sent via Deja.com http://www.deja.com/
 Before you buy.

Re: *\\~record depth~//*

[Matthew Heaney]

In article 
<Pine.LNX.4.10.9911151802000.11396-100000@lexis.di.fct.unl.pt> , Mario
Amado Alves <maa@di.fct.unl.pt>  wrote:

> You know you can write
>
>   type Component_List is array (Component'Range)
>
> instead of
>
>   type Component_List is array (Component'First..Component'Last)


You can even write

  type Component_List is array (Component) of ...;



--
They are very bad reasoners, and vehemently given to opposition, unless
when they happen to be of the right opinion, which is seldom their case.

From "Gulliver Travels," by Jonathan Swift, who could easily have been
writing about modern-day creationists

Re: *\\~record depth~//*

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Best idea always make the type of the subscript explicit in
> the declaration. Either declare the subscript type, or use
> 
>   array (... range x .. y) of ...

I don't mind saying "array(x..y) of..." if x and y determine the type in
the non-confusing way (eg, maybe they're enumeration literals).  But I
never say "array (1..10) of ..." because I think the fact that it
defaults to Integer is an ugly kludge in the language design.

- Bob

Re: *\\~record depth~//*

[G]

I didn't know either of those 'shortcuts'.
Thanks to you both.  I am self-educating.

-Graeme
:-)

Matthew Heaney wrote:

> In article
> <Pine.LNX.4.10.9911151802000.11396-100000@lexis.di.fct.unl.pt> , Mario
> Amado Alves <maa@di.fct.unl.pt>  wrote:
>
> > You know you can write
> >
> >   type Component_List is array (Component'Range)
> >
> > instead of
> >
> >   type Component_List is array (Component'First..Component'Last)
>
> You can even write
>
>   type Component_List is array (Component) of ...;
>
> --
> They are very bad reasoners, and vehemently given to opposition, unless
> when they happen to be of the right opinion, which is seldom their case.
>
> From "Gulliver Travels," by Jonathan Swift, who could easily have been
> writing about modern-day creationists

Re: *\\~record depth~//*

[Robert Dewar]

In article <38312BD8.3D753AE1@interact.net.au>,
  G <Dizzy@interact.net.au> wrote:
> I didn't know either of those 'shortcuts'.
> Thanks to you both.  I am self-educating.
>
> -Graeme
> :-)

I would suggest working through one of the online tutorials
in Ada, since there seem to be quite a few basic things that
you are missing, and trying to fill them in with scattered
Q&A on CLA will leave important holes. Also get a good Ada
book and read it :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: *\\~record depth~//*

[Robert Dewar]

In article <38312BD8.3D753AE1@interact.net.au>,
  G <Dizzy@interact.net.au> wrote:
> I didn't know either of those 'shortcuts'.
> Thanks to you both.  I am self-educating.
>
> -Graeme
> :-)

These are not shortcuts, the use of

  array (subtype-mark) of ...

is the normal way of writing array declarations, and is
pretty fundamental.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: *\\~record depth~//*

[Robert Dewar]

In article <38312BD8.3D753AE1@interact.net.au>,
  G <Dizzy@interact.net.au> wrote:
> I didn't know either of those 'shortcuts'.
> Thanks to you both.  I am self-educating.
>
> -Graeme

Just to follow up further on my comment that

  array (subtype-mark) of ...

is not a shortcut.

The fundamental idea of an array declaration is that you need
to specify the subtype of the subscript(s). The above is
the basic way of doing things. It is the .. notation that
is a shortcut

  array (x .. y) of ...

is a shortcut (and sometimes a confusing one) for

  subtype subscr is ... range X .. Y;
  array (subscr) of ...

What is confusing here is the type to put in for ... in the
subtype declaration. The rule is a bit peculiar:

If the types of x and y are other than universal integer, then
the type for ... is taken from the types of x and y.

If universal integers are used, then quite arbitrarily (and
in the view of many quite unwisely since it introduces junk
implementation dependencies in an implicit manner), the type
chosen is Standard.Integer.

Best idea always make the type of the subscript explicit in
the declaration. Either declare the subscript type, or use

  array (... range x .. y) of ...


Sent via Deja.com http://www.deja.com/
Before you buy.