Dereferencing and style guides

Dereferencing and style guides

[Natasha Kerensikova]

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

Re: Dereferencing and style guides

[Dmitry A. Kazakov]

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

Re: Dereferencing and style guides

[Robert A Duff]

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

Re: Dereferencing and style guides

[Eryndlia Mavourneen]

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)

Re: Dereferencing and style guides

[Georg Bauhaus]

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!

Re: Dereferencing and style guides

[Jeffrey Carter]

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

Re: Dereferencing and style guides

[Robert A Duff]

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

Re: Dereferencing and style guides

[Georg Bauhaus]

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...

Re: Dereferencing and style guides

[Georg Bauhaus]

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 ...

Re: Dereferencing and style guides

[Eryndlia Mavourneen]

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)

Re: Dereferencing and style guides

[Robert A Duff]

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

Re: Dereferencing and style guides

[Stefan.Lucks]

[-- 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--

Re: Dereferencing and style guides

[Adam Beneschan]

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

Re: Dereferencing and style guides

[Robert A Duff]

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

Re: Dereferencing and style guides

[Bill Findlay]

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;

Re: Dereferencing and style guides

[Robert A Duff]

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

Re: Dereferencing and style guides

[G.B.]

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...)

Re: Dereferencing and style guides

[Bill Findlay]

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

Re: Dereferencing and style guides

[Randy Brukardt]

"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.

Re: Dereferencing and style guides

[Randy Brukardt]

"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.

Re: Dereferencing and style guides

[Randy Brukardt]

"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.