* Records that could be arrays @ 2006-02-23 4:11 Justin Gombos 2006-02-23 4:51 ` tmoran ` (4 more replies) 0 siblings, 5 replies; 23+ messages in thread From: Justin Gombos @ 2006-02-23 4:11 UTC (permalink / raw) I noticed this example code in 5.4.4 of the Ada Quality and Style Guide: type Coordinate is record Row : Local_Float; Column : Local_Float; end record; type Window is record Top_Left : Coordinate; Bottom_Right : Coordinate; end record; Would anyone here write something like that? They are trying to illustrate that records should not always be flat, which is a fine example for that purpose, but this seems to set a poor example. Does anyone see a reason to use a record when an array can be used? My version of the same structure would look more like: type Axis is (Row, Column); type Window_Vertex is (Top_Left, Bottom_Right); type Coordinate is array (Axis) of Local_Float; type Window is array (Window_Vertex) of Coordinate; I have set a rule for myself: Composite types composed solely of one type of element should be declared as arrays rather than records. I've never seen this rule in a coding standard. The idea is that you can be more expressive with an array. Example- there are more options when it comes to an arrays role in control structures. Plus the "others =>" notation is available. Thoughts? -- PM instructions: do a C4esar Ciph3r on my address; retain punctuation. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 4:11 Records that could be arrays Justin Gombos @ 2006-02-23 4:51 ` tmoran 2006-02-23 13:19 ` Justin Gombos 2006-02-23 6:32 ` Wilhelm Spickermann ` (3 subsequent siblings) 4 siblings, 1 reply; 23+ messages in thread From: tmoran @ 2006-02-23 4:51 UTC (permalink / raw) > type Coordinate is > record > Row : Local_Float; > Column : Local_Float; > end record; In mathematics, one usually gives a coordinate as (x,y), while in graphics it's often (vertical, horizontal). Inadvertently switching the order can be an annoying bug. But with type Rows is new Local_Float; type Cols is new Local_Float; the compiler's type checking can point out such errors. In that case, of course, you have to use a record with Row : Rows; Column : Cols; and cannot use an array. If your code might one day have to accomodate 3-D coordinates, then for A in Axis loop Sum := Sum + V(A)**2; needs no change, while Sum := V.Row**2 + V.Column**2; will need a makeover, and thus is much less desirable. The general point is that sometimes an array fits the problem better and sometimes a record fits it better. A rule that says "hey, they're all Local_Float so it should be an array" is much too limiting. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 4:51 ` tmoran @ 2006-02-23 13:19 ` Justin Gombos 2006-02-24 10:19 ` Stephen Leake 0 siblings, 1 reply; 23+ messages in thread From: Justin Gombos @ 2006-02-23 13:19 UTC (permalink / raw) On 2006-02-23, tmoran@acm.org <tmoran@acm.org> wrote: > But with > type Rows is new Local_Float; > type Cols is new Local_Float; > the compiler's type checking can point out such errors. In that case, > of course, you have to use a record Sure, my rule wouldn't apply there because we're no longer talking about a composite of a single element type. Cohen uses x,y coodinates of different types as an example of over typing. I'm kind of on the fence. I've been declaring every dimension within a coordinate system to have the same element type because it seems to be more of a hinderance than a benefit to seperate them. The question is whether y is a function of x, which can't always be answered when the type comes into existence. -- PM instructions: do a C4esar Ciph3r on my address; retain punctuation. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 13:19 ` Justin Gombos @ 2006-02-24 10:19 ` Stephen Leake 0 siblings, 0 replies; 23+ messages in thread From: Stephen Leake @ 2006-02-24 10:19 UTC (permalink / raw) Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes: > On 2006-02-23, tmoran@acm.org <tmoran@acm.org> wrote: >> But with >> type Rows is new Local_Float; >> type Cols is new Local_Float; >> the compiler's type checking can point out such errors. In that case, >> of course, you have to use a record > > Sure, my rule wouldn't apply there because we're no longer talking > about a composite of a single element type. > > Cohen uses x,y coodinates of different types as an example of over > typing. I'm kind of on the fence. I've been declaring every > dimension within a coordinate system to have the same element type > because it seems to be more of a hinderance than a benefit to seperate > them. The question is whether y is a function of x, Or if you want the Cartesian magnitude: sqrt (x**2 + y**2). Or any other function that involves x and y in a single expression. Like rotation: Rotated_Point := (a * Point (x) + b * Point (y), c * Point (x) + d * Point (y)); > which can't always be answered when the type comes into existence. If it's a _point_, we already know about such things. If it's a genuinely new type, yes, it might be unclear. -- -- Stephe ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 4:11 Records that could be arrays Justin Gombos 2006-02-23 4:51 ` tmoran @ 2006-02-23 6:32 ` Wilhelm Spickermann 2006-02-23 13:08 ` Stephen Leake 2006-02-23 13:20 ` Justin Gombos 2006-02-23 8:21 ` john Doef ` (2 subsequent siblings) 4 siblings, 2 replies; 23+ messages in thread From: Wilhelm Spickermann @ 2006-02-23 6:32 UTC (permalink / raw) Hi, Justin Gombos wrote: > I have set a rule for myself: Composite types composed solely > of one type of element should be declared as arrays rather than > records. ... > Thoughts? I think it depends on the meaning of "type". The three floating point numbers in a polar coordinate system are of three different _kinds_ and should be put into a record and not into an array -- even if they have the same _type_. Wilhelm ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 6:32 ` Wilhelm Spickermann @ 2006-02-23 13:08 ` Stephen Leake 2006-02-23 13:20 ` Justin Gombos 1 sibling, 0 replies; 23+ messages in thread From: Stephen Leake @ 2006-02-23 13:08 UTC (permalink / raw) Wilhelm Spickermann <zulo.20.unbenutzbar@spamgourmet.com> writes: > Hi, > > Justin Gombos wrote: > >> I have set a rule for myself: Composite types composed solely >> of one type of element should be declared as arrays rather than >> records. > ... >> Thoughts? > > I think it depends on the meaning of "type". The three floating > point numbers in a polar coordinate system are of three > different _kinds_ and should be put into a record and not into > an array -- even if they have the same _type_. I don't think that follows; the names indicate the kind. The names are the same whether it's an array (the index name) or a record (the component name). Following Randy's suggestion, it might make sense to use different types for the three different polar coordinates. But I would not go that far. -- -- Stephe ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 6:32 ` Wilhelm Spickermann 2006-02-23 13:08 ` Stephen Leake @ 2006-02-23 13:20 ` Justin Gombos 2006-02-23 14:29 ` Wilhelm Spickermann 1 sibling, 1 reply; 23+ messages in thread From: Justin Gombos @ 2006-02-23 13:20 UTC (permalink / raw) On 2006-02-23, Wilhelm Spickermann <zulo.20.unbenutzbar@spamgourmet.com> wrote: > > I think it depends on the meaning of "type". The three floating > point numbers in a polar coordinate system are of three > different _kinds_ and should be put into a record and not into > an array -- even if they have the same _type_. Why? -- PM instructions: do a C4esar Ciph3r on my address; retain punctuation. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 13:20 ` Justin Gombos @ 2006-02-23 14:29 ` Wilhelm Spickermann 2006-02-24 10:31 ` Stephen Leake 0 siblings, 1 reply; 23+ messages in thread From: Wilhelm Spickermann @ 2006-02-23 14:29 UTC (permalink / raw) Hi, Justin Gombos wrote: > On 2006-02-23, Wilhelm Spickermann > <zulo.20.unbenutzbar@spamgourmet.com> wrote: >> >> I think it depends on the meaning of "type". The three >> floating point numbers in a polar coordinate system are of >> three different _kinds_ and should be put into a record and >> not into an array -- even if they have the same _type_. > > Why? > These coordinates are of a different kind as they are used differently -- all geometric formulas handle them differently. So it is just a coincidence if they are of the same type and so I wouldn't draw design decisions from the type alone. This becomes also visible in the missing loop statements in typical polar coordinate operations. And it would be rather unusual for an array to have a special equality definition while it is rather normal for a record (phi is "dont care" when theta is zero -- or AFAIK the other way round in North America). Wilhelm ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 14:29 ` Wilhelm Spickermann @ 2006-02-24 10:31 ` Stephen Leake 2006-02-26 22:34 ` Wilhelm Spickermann 0 siblings, 1 reply; 23+ messages in thread From: Stephen Leake @ 2006-02-24 10:31 UTC (permalink / raw) Wilhelm Spickermann <zhopi.20.unbenutzbar@spamgourmet.com> writes: > This becomes also visible in the missing loop statements in > typical polar coordinate operations. And it would be rather > unusual for an array to have a special equality definition Perhaps it is "unusual" in your experience because you are overly restrictive in using arrays for such types. Having said that, I don't think I've ever overridden equality for an array. But I rarely override equality for any type, so that's not a good measure. > while it is rather normal for a record (phi is "dont care" when > theta is zero -- or AFAIK the other way round in North America). Right. So if we are using an array to represet these coordinates, we would override equality for that type. Ada lets us do that, so there is (by definition :) nothing "wrong" with it! Equal rights for arrays :). I see this as similar to a discussion of implementation for a container. At a high level, we don't care whether a "set" is implemented as an array of bits or a list of some sort. At a lower level, we do, and we ask "what is the implementation that gives the fastest execution time" or similar questions. At a high level, a "point" is an abstract object, and we don't care about the representation. At the low level, we ask "would it ever be convenient to use a loop to process the elements of this type". If the answer is 'yes', we use an array. What I have been saying is that the answer is almost always 'yes', when you consider operations like Text_IO and AUnit checks. If we implemented points as limited private types, we wouldn't be having this discussion. But writing access functions instead of just using Ada syntax is "obviously" too heavy for points, so we make them public types. But the priciple still applies; the implementation of the type is logically separate from the abstract interface of the type. -- -- Stephe ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-24 10:31 ` Stephen Leake @ 2006-02-26 22:34 ` Wilhelm Spickermann 0 siblings, 0 replies; 23+ messages in thread From: Wilhelm Spickermann @ 2006-02-26 22:34 UTC (permalink / raw) Hi, Stephen Leake wrote: > Wilhelm Spickermann <zhopi.20.unbenutzbar@spamgourmet.com> > writes: > >> This becomes also visible in the missing loop statements in >> typical polar coordinate operations. And it would be rather >> unusual for an array to have a special equality definition > > Perhaps it is "unusual" in your experience because you are > overly restrictive in using arrays for such types. > Thats right; it's no argument, I shouldn't have added the last sentence. It's just an implication of my preferences of using records for such structures. Wilhelm ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 4:11 Records that could be arrays Justin Gombos 2006-02-23 4:51 ` tmoran 2006-02-23 6:32 ` Wilhelm Spickermann @ 2006-02-23 8:21 ` john Doef 2006-02-23 9:22 ` Jean-Pierre Rosen 2006-02-23 13:06 ` Stephen Leake 4 siblings, 0 replies; 23+ messages in thread From: john Doef @ 2006-02-23 8:21 UTC (permalink / raw) Justin Gombos a écrit : > I noticed this example code in 5.4.4 of the Ada Quality and Style > Guide: [...] > can be more expressive with an array. Example- there are more options > when it comes to an arrays role in control structures. Plus the > "others =>" notation is available. Thoughts? "others =>" is availabe for records too. JD. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 4:11 Records that could be arrays Justin Gombos ` (2 preceding siblings ...) 2006-02-23 8:21 ` john Doef @ 2006-02-23 9:22 ` Jean-Pierre Rosen 2006-02-23 13:11 ` Stephen Leake 2006-02-23 13:37 ` Justin Gombos 2006-02-23 13:06 ` Stephen Leake 4 siblings, 2 replies; 23+ messages in thread From: Jean-Pierre Rosen @ 2006-02-23 9:22 UTC (permalink / raw) Justin Gombos a �crit : > I have set a rule for myself: Composite types composed solely of one > type of element should be declared as arrays rather than records. > I've never seen this rule in a coding standard. The idea is that you > can be more expressive with an array. Example- there are more options > when it comes to an arrays role in control structures. Plus the > "others =>" notation is available. Thoughts? > I beg to disagree here. Arrays are for *iterative* structures, if you don't have a for loop over an array, it should be a record. The fact that all components are of the same type may be an accident that changes during program evolution. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 9:22 ` Jean-Pierre Rosen @ 2006-02-23 13:11 ` Stephen Leake 2006-02-23 13:37 ` Justin Gombos 1 sibling, 0 replies; 23+ messages in thread From: Stephen Leake @ 2006-02-23 13:11 UTC (permalink / raw) Jean-Pierre Rosen <rosen@adalog.fr> writes: > Justin Gombos a �crit : >> I have set a rule for myself: Composite types composed solely of one >> type of element should be declared as arrays rather than records. >> I've never seen this rule in a coding standard. The idea is that you >> can be more expressive with an array. Example- there are more options >> when it comes to an arrays role in control structures. Plus the >> "others =>" notation is available. Thoughts? >> > I beg to disagree here. Arrays are for *iterative* structures, if you > don't have a for loop over an array, it should be a record. This is a good point. However, in my experience, I often end up using a for loop in ancilliary places, even if there is no for loop in the main use of the type. For example, Text_IO Put, Get, and AUnit checks, are more easily done with for loops. > The fact that all components are of the same type may be an accident > that changes during program evolution. Yes. -- -- Stephe ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 9:22 ` Jean-Pierre Rosen 2006-02-23 13:11 ` Stephen Leake @ 2006-02-23 13:37 ` Justin Gombos 1 sibling, 0 replies; 23+ messages in thread From: Justin Gombos @ 2006-02-23 13:37 UTC (permalink / raw) On 2006-02-23, Jean-Pierre Rosen <rosen@adalog.fr> wrote: > > I beg to disagree here. Arrays are for *iterative* structures, if > you don't have a for loop over an array, it should be a record. In most cases you don't know at the time you code the type whether you'll use a loop; and records offer no advantages either way. While limitations can be quite useful when they apply to visibility or access, I see no advantage to limiting the expressive power that arrays have. > The fact that all components are of the same type may be an accident > that changes during program evolution. Good point. -- PM instructions: do a C4esar Ciph3r on my address; retain punctuation. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 4:11 Records that could be arrays Justin Gombos ` (3 preceding siblings ...) 2006-02-23 9:22 ` Jean-Pierre Rosen @ 2006-02-23 13:06 ` Stephen Leake 2006-02-23 20:23 ` Simon Wright 2006-02-24 21:23 ` Randy Brukardt 4 siblings, 2 replies; 23+ messages in thread From: Stephen Leake @ 2006-02-23 13:06 UTC (permalink / raw) Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes: > I noticed this example code in 5.4.4 of the Ada Quality and Style > Guide: > > type Coordinate is > record > Row : Local_Float; > Column : Local_Float; > end record; > > type Window is > record > Top_Left : Coordinate; > Bottom_Right : Coordinate; > end record; > > Would anyone here write something like that? Yes; Windex has it. Although if I was rewriting it from scratch now, I might use an array. > They are trying to illustrate that records should not always be flat, > which is a fine example for that purpose, but this seems to set a poor > example. Does anyone see a reason to use a record when an array can > be used? My version of the same structure would look more like: > > type Axis is (Row, Column); > type Window_Vertex is (Top_Left, Bottom_Right); > > type Coordinate is array (Axis) of Local_Float; > type Window is array (Window_Vertex) of Coordinate; > > I have set a rule for myself: Composite types composed solely of one > type of element should be declared as arrays rather than records. > I've never seen this rule in a coding standard. The idea is that you > can be more expressive with an array. Example- there are more options > when it comes to an arrays role in control structures. Plus the > "others =>" notation is available. Thoughts? I usually lean towards arrays, partly for the reasons you give, partly because I have library utilities that work much more nicely with arrays than records; Text_IO and containers for example. I can create a Text_IO procedure Put for an array with a simple instantiation; for a record, I have to use auto_text_io. But records are deeply embedded in my psyche; these types just feel more natural as records than arrays. I guess we need to catch the kids in high school, and teach them to use arrays instead of records. -- -- Stephe ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 13:06 ` Stephen Leake @ 2006-02-23 20:23 ` Simon Wright 2006-02-24 21:23 ` Randy Brukardt 1 sibling, 0 replies; 23+ messages in thread From: Simon Wright @ 2006-02-23 20:23 UTC (permalink / raw) Stephen Leake <stephe_on_the_web@toadmail.com> writes: > But records are deeply embedded in my psyche; these types just feel > more natural as records than arrays. I guess we need to catch the kids > in high school, and teach them to use arrays instead of records. I would certainly go for the record approach. Because in my world it is rare to the point of non-existence to have structures like this; there's always some extra component of a different type. What's the logical difference between (r, theta) and (x, y)? the former could hardly be treated as an array. Well, since I personally would make Metres a subtype of Float, ditto Radians, perhaps there's not that much difference in practice -- but a world, logically. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-23 13:06 ` Stephen Leake 2006-02-23 20:23 ` Simon Wright @ 2006-02-24 21:23 ` Randy Brukardt 2006-02-25 11:39 ` Dmitry A. Kazakov 1 sibling, 1 reply; 23+ messages in thread From: Randy Brukardt @ 2006-02-24 21:23 UTC (permalink / raw) "Stephen Leake" <stephe_on_the_web@toadmail.com> wrote in message news:u8xs2xm0l.fsf@toadmail.com... > Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes: > > > I noticed this example code in 5.4.4 of the Ada Quality and Style > > Guide: > > > > type Coordinate is > > record > > Row : Local_Float; > > Column : Local_Float; > > end record; > > > > type Window is > > record > > Top_Left : Coordinate; > > Bottom_Right : Coordinate; > > end record; > > > > Would anyone here write something like that? > > Yes; Windex has it. Although if I was rewriting it from scratch now, > I might use an array. Claw also has types like this: type Point_Type is record X, Y : Int; end record; type Size_Type is record Width, Height : Int; -- Width=X_Size, Height=Y_Size. end record; type Rectangle_Type is record Left, Top, Right, Bottom : Int; end record; That's partly because we're matching the Windows definitions for these types, but also because these "feel" like records to me. I generally only use arrays when I'm storing a number of identical items with identical uses (although ordering may matter); "Left" and "Bottom" hardly have the same meaning or use, even though they have the same type and sometimes need to be combined. And its certainly easier to change just one if it isn't an array. Randy. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-24 21:23 ` Randy Brukardt @ 2006-02-25 11:39 ` Dmitry A. Kazakov 2006-02-26 3:24 ` Steve Whalen 0 siblings, 1 reply; 23+ messages in thread From: Dmitry A. Kazakov @ 2006-02-25 11:39 UTC (permalink / raw) On Fri, 24 Feb 2006 15:23:51 -0600, Randy Brukardt wrote: > Claw also has types like this: > > type Point_Type is record > X, Y : Int; > end record; > > type Size_Type is record > Width, Height : Int; -- Width=X_Size, Height=Y_Size. > end record; > > type Rectangle_Type is record > Left, Top, Right, Bottom : Int; > end record; > > That's partly because we're matching the Windows definitions for these > types, but also because these "feel" like records to me. I think that the essential question is whether co-ordinates have the same type. The rest is a question of language deficiency. In this case an inability to provide an array interface to a record type (to have enumerated components), or a record interface to an array (to have named components.) It looks logical to choose the same type for all co-ordinates. However for a teletype display they probably should be different. There is a subtler question whether absolute co-ordinates and distances should of the same type. Sort of, whether the relativity theory applies to GUI... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-25 11:39 ` Dmitry A. Kazakov @ 2006-02-26 3:24 ` Steve Whalen 2006-02-26 9:51 ` Dmitry A. Kazakov 0 siblings, 1 reply; 23+ messages in thread From: Steve Whalen @ 2006-02-26 3:24 UTC (permalink / raw) Dmitry A. Kazakov wrote: > ... The rest is a question of language deficiency. In this case an > inability to provide an array interface to a record type (to have > enumerated components), or a record interface to an array (to have named > components.) ... I'm not sure what you mean by a language deficiency. If you really want to address an object as either a record or an array, doesn't something like this meet your needs? with Ada.Text_IO; use Ada.Text_IO; with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; procedure Redefine is type IntRecord is record FirstInt : Integer; SecondInt : Integer; end record; type IntArray is array (1 .. 2) of Integer; RecVar : IntRecord := (FirstInt => 1, SecondInt => 2); ArrayVar : IntArray; for ArrayVar'Address use RecVar'Address; begin Put("First Record Element = "); Put(RecVar.FirstInt); New_Line; Put("Array Element 2 = "); Put(ArrayVar(2)); New_Line; end Redefine; ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-26 3:24 ` Steve Whalen @ 2006-02-26 9:51 ` Dmitry A. Kazakov 2006-02-27 2:26 ` Steve Whalen 0 siblings, 1 reply; 23+ messages in thread From: Dmitry A. Kazakov @ 2006-02-26 9:51 UTC (permalink / raw) On 25 Feb 2006 19:24:32 -0800, Steve Whalen wrote: > Dmitry A. Kazakov wrote: >> ... The rest is a question of language deficiency. In this case an >> inability to provide an array interface to a record type (to have >> enumerated components), or a record interface to an array (to have named >> components.) ... > > I'm not sure what you mean by a language deficiency. If you really > want to address an object as either a record or an array, doesn't > something like this meet your needs? > > with Ada.Text_IO; use Ada.Text_IO; > with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; > > procedure Redefine is > > type IntRecord is > record > FirstInt : Integer; > SecondInt : Integer; > end record; > type IntArray is > array (1 .. 2) of Integer; > > RecVar : IntRecord := (FirstInt => 1, SecondInt => 2); > > ArrayVar : IntArray; > for ArrayVar'Address > use RecVar'Address; (:-)) Is it C or FORTRAN? I thought nobody uses EQUIVALENCE blocks anymore! No, the above is not an implementation of two interfaces by the same type. It is two overlapped objects of two different types. The difference, apart from safety issues, is that you have to do it on per instance basis. To get it right, you need 1) multiple interface inheritance (this comes with Ada 200Y) 2) abstract array and record interfaces (this does not.) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-26 9:51 ` Dmitry A. Kazakov @ 2006-02-27 2:26 ` Steve Whalen 2006-02-27 9:33 ` Dmitry A. Kazakov 2006-03-01 22:44 ` Robert A Duff 0 siblings, 2 replies; 23+ messages in thread From: Steve Whalen @ 2006-02-27 2:26 UTC (permalink / raw) Dmitry A. Kazakov wrote: > ... (:-)) Is it C or FORTRAN? I thought nobody uses EQUIVALENCE blocks anymore! > > No, the above is not an implementation of two interfaces by the same type. > It is two overlapped objects of two different types.... I'm not recommending anyone actually use the 'Address overlay, but it is in Ada for a reason. A programmer or designer would have to give me a REAL good reason for doing anything like this in a production system, and even then I'd probably say no: pick record or array. About the only way I'd agree to using such code would be if there were thousands of lines of code that "wanted" to reference a central data structure as an array, and thousands of lines of code that "wanted" to reference the same data as a record, but I don't think I've ever seen this happen in the real world. But... You said it was an Ada language limitation that you couldn't use an array as a record and vice versa. My point is that if it was really important to do this, you have the option to do a risky implementation specific overlay and have the expressive power of both array and record representations. By doing it like in my example, you are documenting the risky behavior and documenting that you have verified that the internal representations of the array and the record are identical at the bit level. And yes, I WANT this kind of trickery to be on a variable by variable basis, not for an entire class or type of data. I don't think I'd want Ada to have a facility to do array and record overlays beyond what exists (in the example I gave), because to me arrays and records are NOT synonymous. I can't think of a single "real world" example where the use of the data and the nature of the data in the application didn't clearly suggest that either it was fundamentally an array or a record. I guess that part of the reason I don't want this feature is because I agree with with Jean-Pierre Rosen's statement that arrays are really for iterative structures, so I don't see much need for this since most of the various types of examples given in this thread are clearly (to me) more safely and properly defined as records. I don't know that I'd want to burden the compiler with trying to ensure that an array and record had bit equal representation clauses either given or implied before allowing such an overlay. If equal internal representation is NOT the case, I'd hate to think of the inefficiency of a program using both "array style" AND "record style" access code with the compiler having to do a lot of "conversion" of representation in order to support the hypothesized "overlay" facility. Ada compilers have enough to keep straight already. Or at least I don't see enough utility in such a feature to justify the added complexity. Of course I may be misunderstanding what array/record overlay facility you have in mind. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-27 2:26 ` Steve Whalen @ 2006-02-27 9:33 ` Dmitry A. Kazakov 2006-03-01 22:44 ` Robert A Duff 1 sibling, 0 replies; 23+ messages in thread From: Dmitry A. Kazakov @ 2006-02-27 9:33 UTC (permalink / raw) On 26 Feb 2006 18:26:43 -0800, Steve Whalen wrote: > I don't think I'd want Ada to have a facility to do array and record > overlays beyond what exists (in the example I gave), because to me > arrays and records are NOT synonymous. I can't think of a single "real > world" example where the use of the data and the nature of the data in > the application didn't clearly suggest that either it was fundamentally > an array or a record. Consider a linear algebra library. Aren't matrices arrays? Good. Aren't sparse matrices arrays? Hmm. Interface /= implementation. I was talking about array interface. The implementation of the interface can be any. > I guess that part of the reason I don't want this feature is because I > agree with with Jean-Pierre Rosen's statement that arrays are really > for iterative structures, so I don't see much need for this since most > of the various types of examples given in this thread are clearly (to > me) more safely and properly defined as records. Defined /= declared > I don't know that I'd want to burden the compiler with trying to ensure > that an array and record had bit equal representation clauses either > given or implied before allowing such an overlay. If equal internal > representation is NOT the case, I'd hate to think of the inefficiency > of a program using both "array style" AND "record style" access code > with the compiler having to do a lot of "conversion" of representation > in order to support the hypothesized "overlay" facility. There is no any burden for the compiler, because it is up to the programmer to implement the interface. There is a definite burden for the language designers to unify the type system and language syntax. > Ada compilers have enough to keep straight already. Or at least I don't > see enough utility in such a feature to justify the added complexity. > Of course I may be misunderstanding what array/record overlay facility > you have in mind. What I mean is: type Sparse_Matrix is private array (...) of ...; private type Sparse_Matrix is tagged record ...; -- Here the compiler will politely ask me to provide an implementation -- of access to element primitive operations of Sparse_Matrix. or type Joystick is private record X : Integer; Y : Integer end record; private task type Joystick is ...; -- Here I will be required to provide access to components methods, -- which I will implement via rendezvous! (:-)) Ada should finally get ADTs right! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Records that could be arrays 2006-02-27 2:26 ` Steve Whalen 2006-02-27 9:33 ` Dmitry A. Kazakov @ 2006-03-01 22:44 ` Robert A Duff 1 sibling, 0 replies; 23+ messages in thread From: Robert A Duff @ 2006-03-01 22:44 UTC (permalink / raw) "Steve Whalen" <SteveWhalen001@hotmail.com> writes: > Dmitry A. Kazakov wrote: > > ... (:-)) Is it C or FORTRAN? I thought nobody uses EQUIVALENCE blocks anymore! > > > > No, the above is not an implementation of two interfaces by the same type. > > It is two overlapped objects of two different types.... > > I'm not recommending anyone actually use the 'Address overlay, ... I'm not entirely sure what Dmitry is asking for, but I'm pretty sure it's not overlays. > I don't think I'd want Ada to have a facility to do array and record > overlays beyond what exists (in the example I gave), because to me > arrays and records are NOT synonymous. I can't think of a single "real > world" example where the use of the data and the nature of the data in > the application didn't clearly suggest that either it was fundamentally > an array or a record. > > I guess that part of the reason I don't want this feature is because I > agree with with Jean-Pierre Rosen's statement that arrays are really > for iterative structures, so I don't see much need for this since most > of the various types of examples given in this thread are clearly (to > me) more safely and properly defined as records. Yes, arrays are about iteration. But there are several features built in to Ada that "iterate" over record components. That is, they do something like "for each component loop...". Equality of records is defined in terms of equality of the components. Finalization is defined in terms of Finalize on subcomponents. Stream attributes are defined in terms of the component attributes. There's something fishy when a piece of functionality is available to the language designer, but not the programmer. Of course, to make a "for each record component" facility available to programmers would require some interesting type rules. The type of the current component in that loop needs to be some sort of class-wide type that covers all the component types. And for the built-in stuff, that's exactly what happens -- for example, "=" works only when all the components are non-limited, and therefore have an "=". I've had cases where there's a hierarchy of 100 or so tagged types, forming a tree -- each record extension has some components of type access-to-something'Class. I'd like to define a Tree_Walk operation that follows all such pointers, and calls some class-wide Action procedure. In Ada 95, it would be generic; in Ada 2005, I'd pass a "not null access procedure". It's possible to do that in Ada, but you have to override a walker method on every type. That's error prone, because you have to remember to update the walker every time you add a record component. It would be really nice if the compiler could do that for me -- after all, the compiler knows what all the components are, and it does something very similar in implementing "=" and streams etc. One of my favorite features of Ada is that when I write an aggregate without 'others', the compiler complains if I forgot something. > I don't know that I'd want to burden the compiler with trying to ensure > that an array and record had bit equal representation clauses either How about burdening the compiler with generating code to touch each component? Nothing to do with representation. > Of course I may be misunderstanding what array/record overlay facility > you have in mind. Me, too. ;-) - Bob ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2006-03-01 22:44 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-02-23 4:11 Records that could be arrays Justin Gombos 2006-02-23 4:51 ` tmoran 2006-02-23 13:19 ` Justin Gombos 2006-02-24 10:19 ` Stephen Leake 2006-02-23 6:32 ` Wilhelm Spickermann 2006-02-23 13:08 ` Stephen Leake 2006-02-23 13:20 ` Justin Gombos 2006-02-23 14:29 ` Wilhelm Spickermann 2006-02-24 10:31 ` Stephen Leake 2006-02-26 22:34 ` Wilhelm Spickermann 2006-02-23 8:21 ` john Doef 2006-02-23 9:22 ` Jean-Pierre Rosen 2006-02-23 13:11 ` Stephen Leake 2006-02-23 13:37 ` Justin Gombos 2006-02-23 13:06 ` Stephen Leake 2006-02-23 20:23 ` Simon Wright 2006-02-24 21:23 ` Randy Brukardt 2006-02-25 11:39 ` Dmitry A. Kazakov 2006-02-26 3:24 ` Steve Whalen 2006-02-26 9:51 ` Dmitry A. Kazakov 2006-02-27 2:26 ` Steve Whalen 2006-02-27 9:33 ` Dmitry A. Kazakov 2006-03-01 22:44 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox