Ada Pointer Problem

Ada Pointer Problem

[skidmarks]

Each Ptr assignment below yields the following error message:

--    9.    Ptr     : a.X_Ptr  := Object'Access;
--       non-local pointer cannot point to local object

In the past, the only way that I seem to be able to fix the problem is to
put the pointer and assignment in global space (either in file global or
in a package spec). I've looked at Ada as a Second Language (Cohen) and, 
with less diligence, at the Ada LRM but can't figure what I'm doing wrong. 
What am I doing wrong?

thanks
art

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

package a is
   type X     is new Integer;
   type X_Ptr is access all X;
end a;

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

-- Main Program

with a;

Procedure b is
   subtype Y         is a.X;
   subtype Y_Ptr     is a.X_Ptr;

   Object  : aliased a.X;
   Object_Y: aliased Y;
   Ptr     : a.X_Ptr  := Object'Access;
   Ptr_Y   : Y_Ptr    := Object'Access;
   Ptr_OY  : a.X_Ptr  := Object'Access;
   Ptr_1Y  : Y_Ptr    := Object'Access;

begin -- b
   Ptr     := Object'Access;
   Ptr_Y   := Object'Access;
end b;

Re: Ada Pointer Problem

[David C. Hoos]

The problem is that Object is local to procedure B, while
X_Ptr is declared at library level (i.e., non-local).

The principle is that Object exists only when procedure B is
executing, and what is trying to be prevented is having a value
of type X_Ptr available when Object no longer exists.  This could
happen if B were not the main procedure, but were instead a
library-level procedure that could be called by some other
subprogram.

Since procedure B is known to the programmer to be the main
procedure, in this case, if one is using GNAT, one could
use the 'Unrestricted_Access attribute, instead of the 'Access
attribute, and do what you want.

----- Original Message ----- 
From: "skidmarks" <aschwarz@acm.org>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada-france.org>
Sent: Friday, October 01, 2004 10:26 AM
Subject: Ada Pointer Problem


> Each Ptr assignment below yields the following error message:
>
> --    9.    Ptr     : a.X_Ptr  := Object'Access;
> --       non-local pointer cannot point to local object
>
> In the past, the only way that I seem to be able to fix the problem is to
> put the pointer and assignment in global space (either in file global or
> in a package spec). I've looked at Ada as a Second Language (Cohen) and,
> with less diligence, at the Ada LRM but can't figure what I'm doing wrong.
> What am I doing wrong?
>
> thanks
> art
>
> -----------------------------------------------------------
> -----------------------------------------------------------
>
> package a is
>    type X     is new Integer;
>    type X_Ptr is access all X;
> end a;
>
> --------------------------------------------------------
>
> -- Main Program
>
> with a;
>
> Procedure b is
>    subtype Y         is a.X;
>    subtype Y_Ptr     is a.X_Ptr;
>
>    Object  : aliased a.X;
>    Object_Y: aliased Y;
>    Ptr     : a.X_Ptr  := Object'Access;
>    Ptr_Y   : Y_Ptr    := Object'Access;
>    Ptr_OY  : a.X_Ptr  := Object'Access;
>    Ptr_1Y  : Y_Ptr    := Object'Access;
>
> begin -- b
>    Ptr     := Object'Access;
>    Ptr_Y   := Object'Access;
> end b;
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
>

Re: Ada Pointer Problem

[Ludovic Brenta]

skidmarks writes:
> Each Ptr assignment below yields the following error message:
>
> --    9.    Ptr     : a.X_Ptr  := Object'Access;
> --       non-local pointer cannot point to local object
>
> In the past, the only way that I seem to be able to fix the problem
> is to put the pointer and assignment in global space (either in file
> global or in a package spec). I've looked at Ada as a Second
> Language (Cohen) and, with less diligence, at the Ada LRM but can't
> figure what I'm doing wrong.  What am I doing wrong?

Others have explained the problem, but I think you can solve it by
declaring a local access type (not subtype):

with A;
procedure B is
   type Y is access all A.X; -- local to B

   Object : aliased a.X; -- also local to B

   Ptr : Y := Object'Access;
begin -- B
   null;
end B;

I haven't tried or verified it in the RM, this is just a hint.  But I
think this solution reflects good design; it guarantees that Object
exists for at least as long as type Y.  Thus, you cannot pass Ptr to
subprograms outside of B.

-- 
Ludovic Brenta.

Re: Ada Pointer Problem

[Jeffrey Carter]

David C. Hoos wrote:

> The principle is that Object exists only when procedure B is
> executing, and what is trying to be prevented is having a value
> of type X_Ptr available when Object no longer exists.  This could
> happen if B were not the main procedure, but were instead a
> library-level procedure that could be called by some other
> subprogram.

Since the main procedure may be called recursively, it can happen with 
the main procedure as well.

> Since procedure B is known to the programmer to be the main
> procedure, in this case, if one is using GNAT, one could
> use the 'Unrestricted_Access attribute, instead of the 'Access
> attribute, and do what you want.

'Unchecked_Access is part of the language, and more portable than 
'Unrestricted_Access.

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail
14

Re: Ada Pointer Problem

[aschwarz1309]

Thanks.

However, if the object is declared in a scoped environment it would seem that the only way that a pointer error could occur would be with explicit exporting of a value. Wouldn't checking this be a more reasonable approach than rejecting benign instances (for the next iteration of Ada)?

EXAMPLE: (or am I missing the point?)

    with Pkg;

    package body David is
      Object_Ptr : Pkg.Ptr_Type;

       procedure P1( Ptr  : out Pkg.Ptr_Type ) is
         P1_Object_Ptr : Pkg.Ptr_Type;

         procedure P1_P1( Ptr : out Pkg.Ptr_Type ) is
            P1_P1_Object_Ptr : Pkg.Ptr_Type;
         begin -- P1_P1
            P1_P1_Object_Ptr  := <local something>'Access;  -- no harm so far
            P1_Object_Ptr     := P1_P1_Object_Ptr;          -- error
            Object_Ptr        := P1_P1_Object_Ptr;          -- error
            Ptr               := P1_P1_Object_Ptr;          -- error
         end P1_P1;

         begin -- P1
            P1_Object_Ptr  := <local something>'Access;  -- no harm so far
            Object_Ptr     := P1_P1_Object_ptr;          -- error
            Ptr            := P1_Object_Ptr;             -- error
         end P1;
    end David;



> The problem is that Object is local to procedure B, while
> X_Ptr is declared at library level (i.e., non-local).
> 
> The principle is that Object exists only when procedure B is
> executing, and what is trying to be prevented is having a value
> of type X_Ptr available when Object no longer exists.  This could
> happen if B were not the main procedure, but were instead a
> library-level procedure that could be called by some other
> subprogram.
> 
> Since procedure B is known to the programmer to be the main
> procedure, in this case, if one is using GNAT, one could
> use the 'Unrestricted_Access attribute, instead of the 'Access
> attribute, and do what you want.
> 
> ----- Original Message ----- 
> From: "skidmarks" <aschwarz@acm.org>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada-france.org>
> Sent: Friday, October 01, 2004 10:26 AM
> Subject: Ada Pointer Problem
> 
> 
> > Each Ptr assignment below yields the following error message:
> >
> > --    9.    Ptr     : a.X_Ptr  := Object'Access;
> > --       non-local pointer cannot point to local object
> >
> > In the past, the only way that I seem to be able to fix the problem is to
> > put the pointer and assignment in global space (either in file global or
> > in a package spec). I've looked at Ada as a Second Language (Cohen) and,
> > with less diligence, at the Ada LRM but can't figure what I'm doing wrong.
> > What am I doing wrong?
> >
> > thanks
> > art
> >
> > -----------------------------------------------------------
> > -----------------------------------------------------------
> >
> > package a is
> >    type X     is new Integer;
> >    type X_Ptr is access all X;
> > end a;
> >
> > --------------------------------------------------------
> >
> > -- Main Program
> >
> > with a;
> >
> > Procedure b is
> >    subtype Y         is a.X;
> >    subtype Y_Ptr     is a.X_Ptr;
> >
> >    Object  : aliased a.X;
> >    Object_Y: aliased Y;
> >    Ptr     : a.X_Ptr  := Object'Access;
> >    Ptr_Y   : Y_Ptr    := Object'Access;
> >    Ptr_OY  : a.X_Ptr  := Object'Access;
> >    Ptr_1Y  : Y_Ptr    := Object'Access;
> >
> > begin -- b
> >    Ptr     := Object'Access;
> >    Ptr_Y   := Object'Access;
> > end b;
> > _______________________________________________
> > comp.lang.ada mailing list
> > comp.lang.ada@ada-france.org
> > http://www.ada-france.org/mailman/listinfo/comp.lang.ada
> >
> 

Re: Ada Pointer Problem

[Jeffrey Carter]

aschwarz1309@att.net wrote:

> However, if the object is declared in a scoped environment it would
> seem that the only way that a pointer error could occur would be with
> explicit exporting of a value. Wouldn't checking this be a more
> reasonable approach than rejecting benign instances (for the next
> iteration of Ada)?

That would require that the compiler perform flow analysis, something 
the ARM is not likely to mandate.

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail
14

Re: Ada Pointer Problem

[Randy Brukardt]

"Jeffrey Carter" <spam@spam.com> wrote in message
news:OUm7d.504$UP1.332@newsread1.news.pas.earthlink.net...
> aschwarz1309@att.net wrote:
>
> > However, if the object is declared in a scoped environment it would
> > seem that the only way that a pointer error could occur would be with
> > explicit exporting of a value. Wouldn't checking this be a more
> > reasonable approach than rejecting benign instances (for the next
> > iteration of Ada)?
>
> That would require that the compiler perform flow analysis, something
> the ARM is not likely to mandate.

Right. Flow analysis for legality rules isn't a possibility. Among other
things, it would make whether an error occurs undecidable in some cases.

                   Randy.

Re: Ada Pointer Problem

[skidmarks]

Thank you all. I think that 'Unchecked_Access is probably the answer.

But, to be a little critical, since we want to be really, really safe,
we should provide a unique check/uncheck access for each bit in a
pointer. That way we can be extra-special sure that:
1. The meaning is precise and clear,
2. The program will lack lucidity because of the obtuseness of the
suggestion, and
3. Where one line is suitable in other languages, several are due in
Ada.

And yes, I am frustrated.

A little anecdote. I've followed Ada since it's pre-inception in the
mid-70's, and still have the original SigPlan Green Book. I liked the
idea of Ada and the language of Ada, until 1988. In 1988 I had a
little design problem that I wanted to solve with a pointer. I looked,
and looked, and looked all over the LRM and Ada as a Second Language
(by Cohen) for a pointer. After four hours I found 'Access Type'. It
took four hours to solve a four minute problem. I think because of Ada
snobishnes (we can do better than you can and can do it without using
your keywords or terminology).

I think that I'm better than fair in Ada. I also think that I'm
wasting time on this language. It takes too long to do simple things,
and is a research effort to do the possible but not pedestrian.

Please take this as a critique and not a criticism. I would rather see
improvements than be wasted by flame.

art

Re: Ada Pointer Problem

[Jeffrey Carter]

skidmarks wrote:

> In 1988 I had a
> little design problem that I wanted to solve with a pointer. I looked,
> and looked, and looked all over the LRM and Ada as a Second Language
> (by Cohen) for a pointer. After four hours I found 'Access Type'. It
> took four hours to solve a four minute problem. I think because of Ada
> snobishnes (we can do better than you can and can do it without using
> your keywords or terminology).

The word "pointer" is clearly there in ARM83 3.8 ("Access Types") and in 
the index. If it took you 4 hrs to find it, I don't think we can blame 
the ARM or Ada.

The terminology is not snobbishness but precision. The language 
definition should not unnecessarily constrain implementations. An access 
value may not necessarily be just a pointer; it may contain bounds 
information if it designates an unconstrained array type, for example, 
and there are such implementations.

There was also a design principle that shorter names were preferable: 
"task" instead of "thread" or "process", "access" instead of "pointer".

Finally, "is access X" reads better than "is pointer X".

-- 
Jeff Carter
"Death awaits you all, with nasty, big, pointy teeth!"
Monty Python & the Holy Grail
20

Re: Ada Pointer Problem

[Georg Bauhaus]

skidmarks <aschwarz@acm.org> wrote:
: 
: And yes, I am frustrated.
: 
: A little anecdote. I've followed Ada since it's pre-inception in the
: mid-70's, and still have the original SigPlan Green Book. I liked the
: idea of Ada and the language of Ada, until 1988. In 1988 I had a
: little design problem that I wanted to solve with a pointer. I looked,
: and looked, and looked all over the LRM and Ada as a Second Language
: (by Cohen) for a pointer. After four hours I found 'Access Type'. It
: took four hours to solve a four minute problem. I think because of Ada
: snobishnes (we can do better than you can and can do it without using
: your keywords or terminology).

So maybe there is an opportunity to improve the exposition of
Ada language constructs for programmers expecting wide spread
terminology.
Even if there is good reason to make the distinction
between the _various_ pointer like things and addresses in Ada
explicit.
OTOH, almost every introductory chapter, starting from the beginning,
mentions access values.
Ada as a Second Language has a whole chapter describing access
types. They are also mentioned in the introductory chapter, IIRC.
Does Ada assume programmers that have had an opportunity to
become familiar with their tool?

In order to find "pointer" in the ARM (Ada 95, admittedly)
I pressed the search key twice for "pointer" and found:

 18. (77) Access values are called "pointers" or "references" in some
     other languages.


I'd have a similar problem problem with

template<> class Something<T>

when accompanied by mystic talk about template specializations
and pointers and saving instances.
Just trying to find "generics" the standard or TC++PL won't be helpful
I think.  OTOH, there are C++ rules that help understanding this line.
Stroustrup explains in Ch 13; it does take time though to read this.
I wouldn't know how to quickly solve a "template problem"
without studying this chapter or something equivalent.
(Well, a solution might be found by accident.) Can you blame
a language for having an impressive set of rules, and its own
terms?

Likewise, how would a Scheme programmer, never having seen
CommonLISP, know that you cannot have a function valued thing at place
one in a list? Instead you have to use FUNCALL. Newsgroups
are a Good Thing then, because this is where you can ask
if you are stuck between hundred of pages of formal writing :-)

: I think that I'm better than fair in Ada. I also think that I'm
: wasting time on this language. It takes too long to do simple things,
: and is a research effort to do the possible but not pedestrian.

Could you give some examples?
 

-- Georg

Re: Ada Pointer Problem

[skidmarks]

Thank you for your response, most assuredly thank you for not taking
offense and starting a flame.

> 
> So maybe there is an opportunity to improve the exposition of
> Ada language constructs for programmers expecting wide spread
> terminology.
> Even if there is good reason to make the distinction
> between the _various_ pointer like things and addresses in Ada
> explicit.
> OTOH, almost every introductory chapter, starting from the beginning,
> mentions access values.
> Ada as a Second Language has a whole chapter describing access
> types. They are also mentioned in the introductory chapter, IIRC.
> Does Ada assume programmers that have had an opportunity to
> become familiar with their tool?
> 
> In order to find "pointer" in the ARM (Ada 95, admittedly)
> I pressed the search key twice for "pointer" and found:
> 
>  18. (77) Access values are called "pointers" or "references" in some
>      other languages.
> 

Ada draws sharp distinction between Ada constructs and similar
constructs in other languages. In the early years (Ada 83) this
distinction seems to have led to an abandonment of the use of common
terminology in favor of the Ada specific flavor. This resulted in my
inability to find a 'pointer'. My recollection is that the Ada 83 LRM
and 'Ada as a Second Language' have no index or table of contents
reference to 'pointer'. Looking for a pointer becomes fruitless, and
looking for an 'Access Type' works if you already know that an 'Access
Type' is what you want.

Ada 95 improves the search time for items with different Ada flavors
but with common names in other languages. Pointer is one of the
explicit references, and one which would have improved the Ada 83 LRM
and books.


> Could you give some examples?
>  

The best example is the one that prompted my original posting. Within
a subprogram I attempted to create a pointer to an object created in
the same subprogrm using a typedef imported from another spec file.
This thread shows good reasons why this is inadvisable and why such
care was spent making it impossible to do using 'Access'. My compiler
(Green Hills Version 3.5) provided not the slightest clue as to why
this happened or where to look for a rationale. My argument is that
even if the compiler had been more congenial, the language is still
tortuous. And for me, tortuous to the point of being almost unusable.
To continue the point, the Ada developers recognized both the
indavisability of doing what I wanted and the advisability of letting
me do this assignment, also mentioned in this thread and very
gratefully received by me. However, this is a research game. Ada has
protected me to the point that I can't get my job done without
research. Commmon assumptions are uncommonly treated.

Now (back to pointers) I am similarly frustrated. I want to point to
an object created on the call stack and to pass/use this pointer to my
hearts delight. However, I don't know how. Rather than belabor the
point and spending my time in research (and your time in answering
what must be almost frivolous questions), I am using heap allocation.
'Ada as a Second Language' recommends that the heap deallocator
(Unchecked_Deallocation) not be used - on fear of death no doubt.
Fortunately, this is a non-real-time program on a PC with an available
address space of 2Gb. The period of execution is small enough that
wasting space is not a problem. Hence, no Unchecked_Deallocation will
be used.

Why pointers? The compilers we are using pass by value. Arrays and
records copied to the stack on subprogram entry, and copied back on
subprogram exit (or so I have been told). A pointer reduces this copy
operation.

Pointers are useful for maintaining indirect references to volatile
data. The reference changes when the data changes, but no copy
operation is required.

Pointers are useful in lists.

And so on.

The 'point' is that the required reading to do simple, but perhaps
non-pedestrian things, is far larger than in other languages. This
intrudes on my ability to produce a product (but does not impact good
design).

Putting it another way, I can build a house with a steel hammer or a
brass hammer. If I used a brass hammer I would be required to
periodically grind it's head to make it true. The brass hammer is
shiny, bright, and a real pleasure to look at, but lacks something in
use. As (in my opinion) does Ada.

> 
> -- Georg

art

Re: Ada Pointer Problem

[Jeffrey Carter]

skidmarks wrote:

> My recollection is that the Ada 83 LRM
> and 'Ada as a Second Language' have no index or table of contents
> reference to 'pointer'. Looking for a pointer becomes fruitless, and
> looking for an 'Access Type' works if you already know that an 'Access
> Type' is what you want.

I have the ARM 83, and "pointer" is in the index.

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: Ada Pointer Problem

[Jean-Pierre Rosen]

skidmarks a écrit :

  > Ada draws sharp distinction between Ada constructs and similar
> constructs in other languages. In the early years (Ada 83) this
> distinction seems to have led to an abandonment of the use of common
> terminology in favor of the Ada specific flavor. 
Well, this may be intensional for pointers, because Ada pointers are 
really different from pointers in other languages. But it is certainly 
not true of other terms. For example, "Task" was the common accepted 
name for concurrent activities. The term "thread" was introduced much later.

> [...] My argument is that
> even if the compiler had been more congenial, the language is still
> tortuous. And for me, tortuous to the point of being almost unusable.
> To continue the point, the Ada developers recognized both the
> indavisability of doing what I wanted and the advisability of letting
> me do this assignment, also mentioned in this thread and very
> gratefully received by me. However, this is a research game. Ada has
> protected me to the point that I can't get my job done without
> research. Commmon assumptions are uncommonly treated.
Let's be clear: to use Ada appropriately, you need some training. Ada is 
different from other languages on many aspects, and rightly so I would 
say, otherwise there would be no benefit in using Ada. True enough, the 
programmer used to other languages does not find the one to one mapping 
he would find with other languages.

Ada is for industrial projects, and for providing a different view of 
software development. Some training is required, as it would be with any 
new engineering process in any other part of industry. If a new machine 
is put in a factory, everybody will agree that people must be trained to 
use it. Why do the software people believe that they should be able to 
use a new language just by a trial-and-error process?

> Why pointers? The compilers we are using pass by value. Arrays and
> records copied to the stack on subprogram entry, and copied back on
> subprogram exit (or so I have been told). A pointer reduces this copy
> operation.
Are you sure? Did you check it, or is it just hear-say? Any decent Ada 
compiler would not pass big structures by copy.
Moreover, access parameters might be a better solution than heap allocation.

> Putting it another way, I can build a house with a steel hammer or a
> brass hammer. If I used a brass hammer I would be required to
> periodically grind it's head to make it true. The brass hammer is
> shiny, bright, and a real pleasure to look at, but lacks something in
> use. As (in my opinion) does Ada.
> 
Since you like hammer analogies, here is one from Booch, which in my 
view applies better to Ada:

"Give a power drill to a carpenter who never heard about electricity, 
and he will use it as a hammer.
He will hit his fingers and bend a few nails, because a power drill 
makes a lousy hammer"

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Ada Pointer Problem

[Georg Bauhaus]

skidmarks <aschwarz@acm.org> wrote:
:  Ada has
: protected me to the point that I can't get my job done without
: research.

I know that feeling; as it happens I am just know changing a part
of a program to use access values (here: pointers to constant items),
however, not for reasons of speed but for semantic reasons.

Each time the compiler takes me through the tedium of making access to
objects explicit, I remember my every day work, debugging programs
written in languages that invite me, and others, to just do
this and just do that. And it turns out that many of the obscure
runtime failures and porting surprises are a result of forgiving
languages. Reference types, unchecked arrays, unchecked visibility,
and then suddenly an unforeseen value is passed in during an I/O
operation, and the whole thing breaks down leaving one and a half
pages of stack trace. Then the stack trace doesn't even provide
enough information, because some things are nicely handled by implicit
language mechanisms, and are thus not shown.

This may be an exaggeration in favour of Ada-like languages, but
empirically I find errors in programs more quickly and using fewer
levels of indirection using Ada and avoiding pointers.

: Why pointers? The compilers we are using pass by value. Arrays and
: records copied to the stack on subprogram entry, and copied back on
: subprogram exit (or so I have been told). A pointer reduces this copy
: operation.

Confirming what J-P Rosen has said, I find this surprising. The compilers
I use choose an efficient parameter passing mode. When records or arrays are
passed and are sufficiently small, this may mean by copy, provided the
language definition allows pass-by-copy. Otherwise the compilers choose
to pass references.


: Pointers are useful [...]

No doubt.

: The 'point' is that the required reading to do simple, but perhaps
: non-pedestrian things, is far larger than in other languages. This
: intrudes on my ability to produce a product (but does not impact good
: design).

How long are these products in use?


-- Georg

Re: Ada Pointer Problem

[Dale Stanbrough]

skidmarks wrote:

> Why pointers? The compilers we are using pass by value. Arrays and
> records copied to the stack on subprogram entry, and copied back on
> subprogram exit (or so I have been told). A pointer reduces this copy
> operation.

This is a load of rubbish. Scalars are passed by copy in-copy out.
Other objects are passed in a manner that the compiler thinks will
be efficient. 
For almost any array and record that will be by reference.

> Putting it another way, I can build a house with a steel hammer or a
> brass hammer. If I used a brass hammer I would be required to
> periodically grind it's head to make it true. The brass hammer is
> shiny, bright, and a real pleasure to look at, but lacks something in
> use. As (in my opinion) does Ada.

You can't use a language without knowing it. If you think it should
work like all the other languages you know, then use them. Seems
simpler to me.

If you are not prepared to read the instructions before use, you
shouldn't be surprised if something breaks.

Dale

-- 
dstanbro@spam.o.matic.bigpond.net.au

Re: Ada Pointer Problem

[Ludovic Brenta]

Jean-Pierre Rosen writes:
> Ada is for industrial projects [...] Why do the software people
> believe that they should be able to use a new language just by a
> trial-and-error process?

I have seen many software people develop software by trial and error.
Not many software people are software engineers.

Sad but true.

-- 
Ludovic Brenta.

Re: Ada Pointer Problem

[Björn Persson]

Jean-Pierre Rosen wrote:

> Why do the software people believe that they should be able to 
> use a new language just by a trial-and-error process?

Or just by trial, without errors ...

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Ada Pointer Problem

[skidmarks]

Jean-Pierre Rosen <rosen@adalog.fr> wrote in message news:<blv5kc.tv.ln@skymaster>...
> Are you sure? Did you check it, or is it just hear-say? Any decent Ada 
> compiler would not pass big structures by copy.
> Moreover, access parameters might be a better solution than heap allocati
> on.

Again I apologize for not doing the actual research. We are using an
ICC Compiler targeted to the i960. The compiler vintage I don't know,
but the initial use was about 1990. I will personally check this claim
and verify it's correctness. Sloppy of me not to do it at first blush.

However, the use of pointers is independent of the failure of
reasonable argument passage. I believe that this is (my own) red
herring thrown in with an excess of self-rightous zeal. Sorry.

Re: Ada Pointer Problem

[Benjamin Ketcham]

Jeffrey Carter <spam@spam.com> wrote:
> 
> The terminology is not snobbishness but precision. The language 
> definition should not unnecessarily constrain implementations. An access 
> value may not necessarily be just a pointer; it may contain bounds 
> information if it designates an unconstrained array type, for example, 
> and there are such implementations.

But even in C, it is already understood (by some, and pedantically
explained to the others on a near-daily basis) that "pointers" are
abstract entities, not necessarily the same as "machine addresses";
some implementations transparently use "fat pointers"; and in all
cases, additional information than the "address" can be considered
to be conceptually contained within the pointer, i.e., the type of
the referenced object, particularly the size/alignment for stride
calculations (though of course that information is typically not actually
carried around in the bit pattern, rather is applied at compile-time).

> There was also a design principle that shorter names were preferable: 
> "task" instead of "thread" or "process", "access" instead of "pointer".

But it's not an "access", it's an "access type".  Longer, plus more
than one word.

> Finally, "is access X" reads better than "is pointer X".

Right, to be grammatical (and to match existing verbal usage) you'd
say "is (a) pointer *to* X".  Of course in the code, you'd say something
much more compact, not involving English words at all: whether that is
an advantage or a disadvantage is obviously the territory of religion!
I know which I prefer, but then I like assembly language too.

Also, seems to me, "pointer" is a noun, "access" is normally a verb.
The nouning of verbs doesn't necessarily make for better reading, IMO.

And finally, "pointer to X" very intuitively describes what the
construct does, in a way that makes sense to the first-year CS student
and the deep hardware engineer alike.  "Access type" seems like obtuse
government terminology, divorced from any physical or intuitive
meaning.  How is one to guess that the "access" is by indirection?
I want to "access" *all* my variables!  What is the opposite of
"access", a no-read/no-write type?  Sounds very Zen.
Are not the indexing of an array, calling of a function, ":=", etc., also
examples of "access methods"?  Shouldn't it really be called the
"indirect access type" or "access-by-reference type"?  Yeah, there
we go, getting to my real criticism of Ada: not verbose enough. ;)

--Benjamin

Re: Ada Pointer Problem

[John B. Matthews]

In article <1097898789.244849@yasure>,
 Benjamin Ketcham <bketcham@drizzle.com> wrote:
> Also, seems to me, "pointer" is a noun, "access" is normally a verb.
> --Benjamin

Access is a noun, as well as a verb; pointer is a kind of dog:-)

-- 
John
----
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/

Re: Ada Pointer Problem

[Georg Bauhaus]

Benjamin Ketcham <bketcham@drizzle.com> wrote:
: Also, seems to me, "pointer" is a noun, "access" is normally a verb.
: The nouning of verbs doesn't necessarily make for better reading, IMO.

Correct me if I'm wrong, my Latin is rusty and my English is unreliable,
but I think that the relations between "to succeed" and "the success"
and between "to proceed" and "the process" indicate that originally,
"access" has been a noun more than a verb. (latin accessus and 
accedi/accedere, I believe). At least "to success" is still not a verb
AFAIK :-)


-- Georg