* *\\~record depth~//* @ 1999-11-09 0:00 G 1999-11-08 0:00 ` Nick Roberts ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: G @ 1999-11-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: *\\~record depth~//* 1999-11-09 0:00 *\\~record depth~//* G @ 1999-11-08 0:00 ` Nick Roberts 1999-11-09 0:00 ` Robert Dewar 1999-11-09 0:00 ` oops - same with neater formatting G 1999-11-15 0:00 ` *\\~record depth~//* Mario Amado Alves 2 siblings, 1 reply; 13+ messages in thread From: Nick Roberts @ 1999-11-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: *\\~record depth~//* 1999-11-08 0:00 ` Nick Roberts @ 1999-11-09 0:00 ` Robert Dewar 1999-11-09 0:00 ` David C. Hoos, Sr. 0 siblings, 1 reply; 13+ messages in thread From: Robert Dewar @ 1999-11-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: *\\~record depth~//* 1999-11-09 0:00 ` Robert Dewar @ 1999-11-09 0:00 ` David C. Hoos, Sr. 1999-11-09 0:00 ` Robert Dewar 0 siblings, 1 reply; 13+ messages in thread From: David C. Hoos, Sr. @ 1999-11-09 0:00 UTC (permalink / raw) 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_"? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: *\\~record depth~//* 1999-11-09 0:00 ` David C. Hoos, Sr. @ 1999-11-09 0:00 ` Robert Dewar 0 siblings, 0 replies; 13+ messages in thread From: Robert Dewar @ 1999-11-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* oops - same with neater formatting 1999-11-09 0:00 *\\~record depth~//* G 1999-11-08 0:00 ` Nick Roberts @ 1999-11-09 0:00 ` G 1999-11-15 0:00 ` *\\~record depth~//* Mario Amado Alves 2 siblings, 0 replies; 13+ messages in thread From: G @ 1999-11-09 0:00 UTC (permalink / raw) > --------------------------- > > 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; > ------------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: *\\~record depth~//* 1999-11-09 0:00 *\\~record depth~//* G 1999-11-08 0:00 ` Nick Roberts 1999-11-09 0:00 ` oops - same with neater formatting G @ 1999-11-15 0:00 ` Mario Amado Alves 1999-11-15 0:00 ` Matthew Heaney 2 siblings, 1 reply; 13+ messages in thread From: Mario Amado Alves @ 1999-11-15 0:00 UTC (permalink / raw) To: comp.lang.ada@list.deja.com 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: *\\~record depth~//* 1999-11-15 0:00 ` *\\~record depth~//* Mario Amado Alves @ 1999-11-15 0:00 ` Matthew Heaney 1999-11-16 0:00 ` G 0 siblings, 1 reply; 13+ messages in thread From: Matthew Heaney @ 1999-11-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: *\\~record depth~//* 1999-11-15 0:00 ` Matthew Heaney @ 1999-11-16 0:00 ` G 1999-11-16 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: G @ 1999-11-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: *\\~record depth~//* 1999-11-16 0:00 ` G @ 1999-11-16 0:00 ` Robert Dewar 1999-11-16 0:00 ` Robert A Duff 1999-11-16 0:00 ` Robert Dewar 1999-11-16 0:00 ` Robert Dewar 2 siblings, 1 reply; 13+ messages in thread From: Robert Dewar @ 1999-11-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: *\\~record depth~//* 1999-11-16 0:00 ` Robert Dewar @ 1999-11-16 0:00 ` Robert A Duff 0 siblings, 0 replies; 13+ messages in thread From: Robert A Duff @ 1999-11-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: *\\~record depth~//* 1999-11-16 0:00 ` G 1999-11-16 0:00 ` Robert Dewar @ 1999-11-16 0:00 ` Robert Dewar 1999-11-16 0:00 ` Robert Dewar 2 siblings, 0 replies; 13+ messages in thread From: Robert Dewar @ 1999-11-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: *\\~record depth~//* 1999-11-16 0:00 ` G 1999-11-16 0:00 ` Robert Dewar 1999-11-16 0:00 ` Robert Dewar @ 1999-11-16 0:00 ` Robert Dewar 2 siblings, 0 replies; 13+ messages in thread From: Robert Dewar @ 1999-11-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~1999-11-16 0:00 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-11-09 0:00 *\\~record depth~//* G 1999-11-08 0:00 ` Nick Roberts 1999-11-09 0:00 ` Robert Dewar 1999-11-09 0:00 ` David C. Hoos, Sr. 1999-11-09 0:00 ` Robert Dewar 1999-11-09 0:00 ` oops - same with neater formatting G 1999-11-15 0:00 ` *\\~record depth~//* Mario Amado Alves 1999-11-15 0:00 ` Matthew Heaney 1999-11-16 0:00 ` G 1999-11-16 0:00 ` Robert Dewar 1999-11-16 0:00 ` Robert A Duff 1999-11-16 0:00 ` Robert Dewar 1999-11-16 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox