* Dereferencing and style guides @ 2013-09-30 6:35 Natasha Kerensikova 2013-09-30 7:13 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Natasha Kerensikova @ 2013-09-30 6:35 UTC (permalink / raw) Hello, I have found that I often feel the to explicitly dereference access values, using .all, even when it can be omitted, because it feels more readable. That's especially true in portions of code that deal with both "real" objects and access to such object. However, I don't think I have ever met or discussed with anyone who does not favor using .all only it is mandatory. And I haven't found any style guide that explicitly favors one way or the other. I think somehow I like to have my statements as context-free as possible. So when I see Some_Variable.all I don't have to remember that Some_Variable is actually an access value rather than a full-fledged object. On the other hand, I think I understand the case for syntax overloading: I could be seen as a feature to have the same syntax (when possible) for an access value and an object value, just like it is for array indexation and function calls. Though I don't really subscribe to the point of view. So what do you think about the topic? Are there other people here favoring non-mandatory .all? Have I missed some guidelines and rationals discussion the question? Thanks for your help, Natasha ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-09-30 6:35 Dereferencing and style guides Natasha Kerensikova @ 2013-09-30 7:13 ` Dmitry A. Kazakov 2013-09-30 12:51 ` Robert A Duff 2013-09-30 13:53 ` Eryndlia Mavourneen 2 siblings, 0 replies; 21+ messages in thread From: Dmitry A. Kazakov @ 2013-09-30 7:13 UTC (permalink / raw) On Mon, 30 Sep 2013 06:35:09 +0000 (UTC), Natasha Kerensikova wrote: > So what do you think about the topic? > Are there other people here favoring non-mandatory .all? > Have I missed some guidelines and rationals discussion the question? I don't believe many would agree, but anyway. From my point of view a referential type (such as access type) represents a subtype of the target type. Therefore there should be no .all or any other explicit dereferencing operation, because this is not the parent's type operation. For the same reason := should have mean deep assignment not the shallow one as in Ada. For shallow assignment there should have been another operation here, or overloaded :=, e.g. type T is ...; type T_Ptr is access T; X, Y := T_Ptr; begin X := Y; -- Deep copy X := Y'Access; -- Shallow copy -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-09-30 6:35 Dereferencing and style guides Natasha Kerensikova 2013-09-30 7:13 ` Dmitry A. Kazakov @ 2013-09-30 12:51 ` Robert A Duff 2013-09-30 16:49 ` Georg Bauhaus 2013-09-30 13:53 ` Eryndlia Mavourneen 2 siblings, 1 reply; 21+ messages in thread From: Robert A Duff @ 2013-09-30 12:51 UTC (permalink / raw) Natasha Kerensikova <lithiumcat@gmail.com> writes: > I think somehow I like to have my statements as context-free as > possible. So when I see Some_Variable.all I don't have to remember that > Some_Variable is actually an access value rather than a full-fledged > object. I agree with you that dereferencing should be explicit. Aliasing is dangerous. It's good to have a reminder, "There might be other things pointing at this thing." If dereference had a decent syntax, like "^" in Pascal, I would use it always. And I think the language should require that. (A pure functional language is different!) However, the ".all" syntax is just plain weird. "All what?" It makes no sense to me. And it's too verbose (should be a single character). So I don't use it, except when it's required, or in rare cases where I think it's very important to emphasize the aliasing issue. There's an option in GNAT to get it to complain when you leave out ".all". A pragma-Restriction, I think. - Bob ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-09-30 12:51 ` Robert A Duff @ 2013-09-30 16:49 ` Georg Bauhaus 2013-09-30 18:18 ` Jeffrey Carter 2013-10-03 19:20 ` Robert A Duff 0 siblings, 2 replies; 21+ messages in thread From: Georg Bauhaus @ 2013-09-30 16:49 UTC (permalink / raw) On 30.09.13 14:51, Robert A Duff wrote: > However, the ".all" syntax is just plain weird. "All what?" It makes > no sense to me. I take it you are deliberately being forgetful? ;-) All what? All [components] of the referenced object, of course. In true Ada, an plain old object is the only kind of entity that should ever need access through an access value! ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-09-30 16:49 ` Georg Bauhaus @ 2013-09-30 18:18 ` Jeffrey Carter 2013-10-03 19:20 ` Robert A Duff 1 sibling, 0 replies; 21+ messages in thread From: Jeffrey Carter @ 2013-09-30 18:18 UTC (permalink / raw) On 09/30/2013 09:49 AM, Georg Bauhaus wrote: > On 30.09.13 14:51, Robert A Duff wrote: >> However, the ".all" syntax is just plain weird. "All what?" It makes >> no sense to me. > > I take it you are deliberately being forgetful? ;-) > > All what? All [components] of the referenced object, of course. Right. "All of whatever the access value designates" is how I would put it. Returning to the OP, I would say it depends on what you want to emphasize to the reader. If you use ".all" when it isn't required, you're emphasizing that this is a dereference of an access value. If you omit it, you're emphasizing what you're doing with the dereferenced value: indexing, selection of a component or operation, and so on. -- Jeff Carter "You can never forget too much about C++." 115 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-09-30 16:49 ` Georg Bauhaus 2013-09-30 18:18 ` Jeffrey Carter @ 2013-10-03 19:20 ` Robert A Duff 2013-10-04 13:22 ` Georg Bauhaus 2013-10-07 16:10 ` Eryndlia Mavourneen 1 sibling, 2 replies; 21+ messages in thread From: Robert A Duff @ 2013-10-03 19:20 UTC (permalink / raw) Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes: > On 30.09.13 14:51, Robert A Duff wrote: >> However, the ".all" syntax is just plain weird. "All what?" It makes >> no sense to me. > > I take it you are deliberately being forgetful? ;-) > > All what? All [components] of the referenced object, of course. Still makes no sense to me. X.all does not denote "all the components of X". It denotes the object that X designates. Saying, "Yeah it denotes ALL of that object" seems silly. Every name that denotes ANY object denotes all of it. And what if X.all is an Integer, so it has no components. For an access-to-array, should it be X(all)? No, sorry, I think the ".all" syntax is just plain weird. > In true Ada, an plain old object is the only kind of entity that > should ever need access through an access value! Not sure what you mean. - Bob ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-03 19:20 ` Robert A Duff @ 2013-10-04 13:22 ` Georg Bauhaus 2013-10-04 13:25 ` Georg Bauhaus 2013-10-07 16:10 ` Eryndlia Mavourneen 1 sibling, 1 reply; 21+ messages in thread From: Georg Bauhaus @ 2013-10-04 13:22 UTC (permalink / raw) On 03.10.13 21:20, Robert A Duff wrote: > Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes: > >> On 30.09.13 14:51, Robert A Duff wrote: >>> However, the ".all" syntax is just plain weird. "All what?" It makes >>> no sense to me. >> >> I take it you are deliberately being forgetful? ;-) >> >> All what? All [components] of the referenced object, of course. > > Still makes no sense to me. X.all does not denote "all the components > of X". It denotes the object that X designates. > Every name that denotes ANY object denotes all of it. We do get both explicit_dereference and implicit_dereference, which is where points of view are starting to differ, I think. If the object named X is a pointer, it points to another object Y, and lets me refer to/designate Y if I use X in a dereferencing context. Then, X.foo as in many languages, Java, say, is a normal way of referring to that part of Y named "foo". Ada, too, allows referring to parts of pointed-to objects by using that same notation. Then, rather than X.foo, X.all.foo is really a weird construct, somewhat like saying (*X).foo in C, not X->foo. Just telling how I have found explanations of ".all" plausible. There is implicitness in Ada, and I guess they thought there would be uses. > And what if X.all is an Integer, so it has no components. "All of whatever the access value designates", as Jeffrey Carter has put it. For example, it designates not one of the integer's attributes, but the entire thing itself. If X is an "access function", I can also refer to one of the function's components, using one of the pairs in its (Dom -> Ran). For 0-ary functions, with Dom = ∅, I can only legally say Result := X.all; reflecting the potential weirdness of 0-ary functions. I cannot write "X.all" alone if the designated function has a non-empty domain---Ada does not have function values. If X points to a singulary function, I can write a sum of two function values as X (L) + X (R) or as X.all (L) + X.all (R). How should I read this, without dragging in just means of implementation? "X (L)" selects the pair from (Dom -> Ran) that has L in Dom, just as if X were to designate the function's set of pairs, directly, and much as if X were an array, "X.all (L)", OTOH, selects all pairs from (Dom -> Ran) and then picks the one that has L in Dom. I think that this is one possible reading, > For an access-to-array, should it be X(all)? No, just X.all, as X(Whatever) calls for implicit_dereference. "()" and "." signify the different styles of referring to components of arrays/functions and records/etc, respectively. > No, sorry, I think the ".all" syntax is just plain weird. > >> In true Ada, an plain old object is the only kind of entity that >> should ever need access through an access value! > > Not sure what you mean. If the environment of Ada programs were less C-ish, if Ada had been more wide-spread, I guess, then there would not be so many access-to-subp etc. The pointers are, in many cases, just artifacts of implementation. Passing subprograms statically would instead use a mechanism that names the subprograms directly... ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-04 13:22 ` Georg Bauhaus @ 2013-10-04 13:25 ` Georg Bauhaus 0 siblings, 0 replies; 21+ messages in thread From: Georg Bauhaus @ 2013-10-04 13:25 UTC (permalink / raw) On 04.10.13 15:22, Georg Bauhaus wrote: > reflecting the potential weirdness of 0-ary functions. I cannot write > "X.all" alone if the designated function has a non-empty domain---Ada does > not have function values. > > If X points to a singulary function, I can write a sum of two function > values as rather: values of the function at ... ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-03 19:20 ` Robert A Duff 2013-10-04 13:22 ` Georg Bauhaus @ 2013-10-07 16:10 ` Eryndlia Mavourneen 2013-10-08 0:48 ` Robert A Duff 1 sibling, 1 reply; 21+ messages in thread From: Eryndlia Mavourneen @ 2013-10-07 16:10 UTC (permalink / raw) On Thursday, October 3, 2013 2:20:47 PM UTC-5, Robert A Duff wrote: > > . . . > > No, sorry, I think the ".all" syntax is just plain weird. > > - Bob ".all" *is* weird; however, some construct is required, for instance, to distinguish a stand-alone identifier for an object of an access type from a parameterless subprogram. There may be other situations that require it that I am not aware of. -- Eryndlia (KK1T) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-07 16:10 ` Eryndlia Mavourneen @ 2013-10-08 0:48 ` Robert A Duff 2013-10-10 7:35 ` Stefan.Lucks 2013-10-19 2:36 ` Randy Brukardt 0 siblings, 2 replies; 21+ messages in thread From: Robert A Duff @ 2013-10-08 0:48 UTC (permalink / raw) Eryndlia Mavourneen <eryndlia@gmail.com> writes: > On Thursday, October 3, 2013 2:20:47 PM UTC-5, Robert A Duff wrote: >> >> . . . >> >> No, sorry, I think the ".all" syntax is just plain weird. >> >> - Bob > > ".all" *is* weird; however, some construct is required, for instance, > to distinguish a stand-alone identifier for an object of an access > type from a parameterless subprogram. There may be other situations > that require it that I am not aware of. I like the syntax of Pascal: If X is a pointer, then "X" denotes that pointer, "X^" denotes the object it points at (all of it!), and "X^.Y" denotes the Y component of the object X points at (again, all of that component!). And "X.Y" is illegal. Since dereference is just one character, it's not painful to read. And it imparts useful information. - Bob ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-08 0:48 ` Robert A Duff @ 2013-10-10 7:35 ` Stefan.Lucks 2013-10-10 14:48 ` Adam Beneschan 2013-10-19 2:36 ` Randy Brukardt 1 sibling, 1 reply; 21+ messages in thread From: Stefan.Lucks @ 2013-10-10 7:35 UTC (permalink / raw) [-- Attachment #1: Type: TEXT/PLAIN, Size: 730 bytes --] On Mon, 7 Oct 2013, Robert A Duff wrote: > I like the syntax of Pascal: If X is a pointer, then "X" denotes that > pointer, "X^" denotes the object it points at (all of it!), and "X^.Y" > denotes the Y component of the object X points at (again, all of that > component!). And "X.Y" is illegal. > > Since dereference is just one character, it's not painful to read. > And it imparts useful information. Agreed! This is one of the few points where Ada really made things from Pascal worse. ------ I love the taste of Cryptanalysis in the morning! ------ <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html> --Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany-- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-10 7:35 ` Stefan.Lucks @ 2013-10-10 14:48 ` Adam Beneschan 2013-10-10 22:49 ` Robert A Duff 0 siblings, 1 reply; 21+ messages in thread From: Adam Beneschan @ 2013-10-10 14:48 UTC (permalink / raw) On Thursday, October 10, 2013 12:35:31 AM UTC-7, Stefan...@uni-weimar.de wrote: > > I like the syntax of Pascal: If X is a pointer, then "X" denotes that > > pointer, "X^" denotes the object it points at (all of it!), and "X^.Y" > > denotes the Y component of the object X points at (again, all of that > > component!). And "X.Y" is illegal. > > > Since dereference is just one character, it's not painful to read. > > And it imparts useful information. > > Agreed! This is one of the few points where Ada really made things from > Pascal worse. I can imagine that Ada might have adopted the same syntax, if only those old keypunch machines had a ^ character on them. On the other hand, I'm not sure about the idea that "making things just one character" equates to readability. If that were true, APL would be the most readable language around. And C would be second. -- Adam ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-10 14:48 ` Adam Beneschan @ 2013-10-10 22:49 ` Robert A Duff 2013-10-11 8:07 ` Bill Findlay 0 siblings, 1 reply; 21+ messages in thread From: Robert A Duff @ 2013-10-10 22:49 UTC (permalink / raw) Adam Beneschan <adambeneschan@aol.com> writes: > I can imagine that Ada might have adopted the same syntax, if only > those old keypunch machines had a ^ character on them. I thought they did. Except it looked like an up-arrow. Anyway, the solution to keyboards with missing characters is clear: see J.2. 7-bit ASCII was standard at the time. > On the other hand, I'm not sure about the idea that "making things > just one character" equates to readability. If that were true, APL > would be the most readable language around. And C would be second. Well, I didn't say everything should be one character. I said the dereference operator should be one character. So I'd say APL is a bit of a straw man here. I'm quite happy to say "end if;" where C says "}". In Ada, dereference is usually zero characters, so I'm actually arguing for MORE verbosity! Just a little more. - Bob ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-10 22:49 ` Robert A Duff @ 2013-10-11 8:07 ` Bill Findlay 2013-10-11 12:52 ` Robert A Duff 0 siblings, 1 reply; 21+ messages in thread From: Bill Findlay @ 2013-10-11 8:07 UTC (permalink / raw) On 10/10/2013 23:49, in article wcchaco3fne.fsf@shell01.TheWorld.com, "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote: > Adam Beneschan <adambeneschan@aol.com> writes: > >> I can imagine that Ada might have adopted the same syntax, if only >> those old keypunch machines had a ^ character on them. > > I thought they did. Except it looked like an up-arrow. > > Anyway, the solution to keyboards with missing characters > is clear: see J.2. 7-bit ASCII was standard at the time. > >> On the other hand, I'm not sure about the idea that "making things >> just one character" equates to readability. If that were true, APL >> would be the most readable language around. And C would be second. > > Well, I didn't say everything should be one character. I said > the dereference operator should be one character. So I'd say > APL is a bit of a straw man here. I'm quite happy to say > "end if;" where C says "}". > > In Ada, dereference is usually zero characters, so I'm actually arguing > for MORE verbosity! Just a little more. Can I make the contrary case? Given that we know that P is a pointer, P.f or P(i) can only reasonably be interpreted as dereferencing P and selecting a component from the result; so I do not see that P^.f or P^(i) improves comprehensibility to any significant degree. Given that we do not know that P is a pointer, P.f or P(i) is essentially the same cognitive burden as R.f or A(i); from the uniform referent point of view this is an advantage. It fails to be, only if the dereference fails, and we know that that should not happen in Ada 8-). Even if it does, the extra effort of perceiving the semantics correctly is trivial. -- Bill Findlay with blueyonder.co.uk; use surname & forename; ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-11 8:07 ` Bill Findlay @ 2013-10-11 12:52 ` Robert A Duff 2013-10-11 13:02 ` G.B. ` (3 more replies) 0 siblings, 4 replies; 21+ messages in thread From: Robert A Duff @ 2013-10-11 12:52 UTC (permalink / raw) Bill Findlay <yaldnif.w@blueyonder.co.uk> writes: > Can I make the contrary case? Certainly. > Given that we know that P is a pointer, P.f or P(i) can only reasonably be > interpreted as dereferencing P and selecting a component from the result; so > I do not see that P^.f or P^(i) improves comprehensibility to any > significant degree. > > Given that we do not know that P is a pointer, P.f or P(i) is essentially > the same cognitive burden as R.f or A(i); from the uniform referent point of > view this is an advantage. It fails to be, only if the dereference fails, > and we know that that should not happen in Ada 8-). Even if it does, the > extra effort of perceiving the semantics correctly is trivial. By "dereference fails", I assume you're talking about null pointers. I wasn't so worried about that -- I'm more worried about aliasing. I'm thinking "X^.Y := ..." is a helpful reminder that some other pointers might also point to X^. So I'm not convinced. But I guess your point of view is more popular than mine. Consider languages like Java, for ex, where (almost) everything is a pointer, greatly (IMHO) exacerbating the aliasing problem. A pure functional language would be different: there, the semantics of "a thing" and "a pointer to a thing" are indistinguishable, so there's no reason to have explicit dereference operators. - Bob ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-11 12:52 ` Robert A Duff @ 2013-10-11 13:02 ` G.B. 2013-10-11 13:19 ` Bill Findlay ` (2 subsequent siblings) 3 siblings, 0 replies; 21+ messages in thread From: G.B. @ 2013-10-11 13:02 UTC (permalink / raw) On 11.10.13 14:52, Robert A Duff wrote: > A pure functional language would be different: there, the semantics > of "a thing" and "a pointer to a thing" are indistinguishable, > so there's no reason to have explicit dereference operators. I understand they are adding linear types to these languages in order to not need pointers for scalar values/object. (Although, IIRC, this might require that variable of these types be explicitly marked...) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-11 12:52 ` Robert A Duff 2013-10-11 13:02 ` G.B. @ 2013-10-11 13:19 ` Bill Findlay 2013-10-19 2:40 ` Randy Brukardt 2013-10-19 2:46 ` Randy Brukardt 3 siblings, 0 replies; 21+ messages in thread From: Bill Findlay @ 2013-10-11 13:19 UTC (permalink / raw) Robert A Duff <bobduff@shell01.TheWorld.com> wrote: > Bill Findlay <yaldnif.w@blueyonder.co.uk> writes: > >> Can I make the contrary case? > > Certainly. > >> Given that we know that P is a pointer, P.f or P(i) can only reasonably be >> interpreted as dereferencing P and selecting a component from the result; so >> I do not see that P^.f or P^(i) improves comprehensibility to any >> significant degree. >> >> Given that we do not know that P is a pointer, P.f or P(i) is essentially >> the same cognitive burden as R.f or A(i); from the uniform referent point of >> view this is an advantage. It fails to be, only if the dereference fails, >> and we know that that should not happen in Ada 8-). Even if it does, the >> extra effort of perceiving the semantics correctly is trivial. > > By "dereference fails", I assume you're talking about null pointers. > I wasn't so worried about that -- I'm more worried about > aliasing. I'm thinking "X^.Y := ..." is a helpful reminder that > some other pointers might also point to X^. But even without prior knowledge that P is a pointer, there are several ways that must be borne in mind for how P.whatever could be aliased, the existence of another pointer with the same value as P being perhaps the most straightforward. {An anecdote. Many years ago I did once get major benefit from the ^ notation in Pascal. I had to convert a program from using data in an external file to using data in virtual memory. I merely had to write a "get" procedure for the latter and the rest of the code was essentially unchanged, with data^ reinterpreted as a pointer dereference instead of a file record access. The point being that there was some commonality of syntax in Pascal with ^, and there is even more in Ada without it.} > So I'm not convinced. But I guess your point of view is more > popular than mine. Consider languages like Java, for ex, > where (almost) everything is a pointer, greatly (IMHO) exacerbating > the aliasing problem. Yes. Yuck. -- Bill Findlay ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-11 12:52 ` Robert A Duff 2013-10-11 13:02 ` G.B. 2013-10-11 13:19 ` Bill Findlay @ 2013-10-19 2:40 ` Randy Brukardt 2013-10-19 2:46 ` Randy Brukardt 3 siblings, 0 replies; 21+ messages in thread From: Randy Brukardt @ 2013-10-19 2:40 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wcc8uy0t1ec.fsf@shell01.TheWorld.com... ... > By "dereference fails", I assume you're talking about null pointers. > I wasn't so worried about that -- I'm more worried about > aliasing. I'm thinking "X^.Y := ..." is a helpful reminder that > some other pointers might also point to X^. That's helpful? It seems to me that there is a design problem if you have such additional pointers (especially in client code). The only access type you have to use in Ada 2012 is the reference object in the containers libraries. Anything else deserves flogging with a wet noodle. :-) (Unless you are writing a containers library itself, of course.) Randy. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-11 12:52 ` Robert A Duff ` (2 preceding siblings ...) 2013-10-19 2:40 ` Randy Brukardt @ 2013-10-19 2:46 ` Randy Brukardt 3 siblings, 0 replies; 21+ messages in thread From: Randy Brukardt @ 2013-10-19 2:46 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wcc8uy0t1ec.fsf@shell01.TheWorld.com... ... > By "dereference fails", I assume you're talking about null pointers. > I wasn't so worried about that -- I'm more worried about > aliasing. I'm thinking "X^.Y := ..." is a helpful reminder that > some other pointers might also point to X^. Besides my other reply, I don't buy this anyway. If X is a parameter, it might have other aliases around whether or not it is a pointer (certainly, for anything that could be passed by reference). And even if not a parameter X, can be aliased by foreign code, chapter 13 stuff, etc. The moral is, if you worry about potential aliasing, you're just going to drive yourself nuts (or be seriously oversimplifying). Aliasing in Ada really depends on the type of a name: if it has an elementary type, it's OK to assume that it isn't aliased; otherwise, you have to assume that it can be. Dereferences are irrelevant to that calculation, so I don't see much point in emphasizing them. Randy. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-10-08 0:48 ` Robert A Duff 2013-10-10 7:35 ` Stefan.Lucks @ 2013-10-19 2:36 ` Randy Brukardt 1 sibling, 0 replies; 21+ messages in thread From: Randy Brukardt @ 2013-10-19 2:36 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccob70twny.fsf@shell01.TheWorld.com... ... > I like the syntax of Pascal: If X is a pointer, then "X" denotes that > pointer, "X^" denotes the object it points at (all of it!), and "X^.Y" > denotes the Y component of the object X points at (again, all of that > component!). And "X.Y" is illegal. Wasn't '^' one of the characters that weren't allowed to be used in Ada 83 because they were not on ancient keypunches? That's probably the reason for not using that character. But I'd be very unhappy if we required it. The fact that it is *not* required is very important to giving the illusion that you can index a container object directly in Ada 2012 (and modify the elements in place). And in general, you don't really want to expose the fact that access types are used in reference objects -- the idea is to allow direct modifications of the object -- the mechanism used to achieve that should be irrelevant (especially to a reader). Ergo, you never really want to write ".all", because if you have to, you're using too many access types in your program. :-) Randy. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Dereferencing and style guides 2013-09-30 6:35 Dereferencing and style guides Natasha Kerensikova 2013-09-30 7:13 ` Dmitry A. Kazakov 2013-09-30 12:51 ` Robert A Duff @ 2013-09-30 13:53 ` Eryndlia Mavourneen 2 siblings, 0 replies; 21+ messages in thread From: Eryndlia Mavourneen @ 2013-09-30 13:53 UTC (permalink / raw) On Monday, September 30, 2013 1:35:09 AM UTC-5, Natasha Kerensikova wrote: > . . . > So what do you think about the topic? > Are there other people here favoring non-mandatory .all? For me, it depends upon the context and my mood at the moment. I like the clarity of the explicit dereference .all; however, sometimes it just seems silly or clumsy. -- Eryndlia (KK1T) ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2013-10-19 2:46 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-09-30 6:35 Dereferencing and style guides Natasha Kerensikova 2013-09-30 7:13 ` Dmitry A. Kazakov 2013-09-30 12:51 ` Robert A Duff 2013-09-30 16:49 ` Georg Bauhaus 2013-09-30 18:18 ` Jeffrey Carter 2013-10-03 19:20 ` Robert A Duff 2013-10-04 13:22 ` Georg Bauhaus 2013-10-04 13:25 ` Georg Bauhaus 2013-10-07 16:10 ` Eryndlia Mavourneen 2013-10-08 0:48 ` Robert A Duff 2013-10-10 7:35 ` Stefan.Lucks 2013-10-10 14:48 ` Adam Beneschan 2013-10-10 22:49 ` Robert A Duff 2013-10-11 8:07 ` Bill Findlay 2013-10-11 12:52 ` Robert A Duff 2013-10-11 13:02 ` G.B. 2013-10-11 13:19 ` Bill Findlay 2013-10-19 2:40 ` Randy Brukardt 2013-10-19 2:46 ` Randy Brukardt 2013-10-19 2:36 ` Randy Brukardt 2013-09-30 13:53 ` Eryndlia Mavourneen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox