Re: Self-referential types

Re: Self-referential types

[Ted Dennison]

In article <3802597B.9205AEE8@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> Ted Dennison wrote:
> >
> > Below is a code sample that is taken directly from Cohen's AAASL,
> > section 11.8.3:
> >
> > procedure Test is
> >
> >    type Cell_Type;
> >
> >    type List_Type is access all Cell_Type;
> >
> >    type Cell_Type is
> >      limited record
> >         Contents_Part      : String (1..20);
> >         Next_Cell_Part     : List_Type := Cell_Type'Access;
> >         Previous_Cell_Part : List_Type := Cell_Type'Access;
> >      end record;

> invokes the various accessibility rules.  In particular, when
> inside the definition of a type, <type_name>'Access is presumed
> to have an accessibility level deeper than that of the enclosing type,
> meaning it is also deeper than List_Type.  Note that there is
> nothing preventing the values of next and previous being copied
> into global variables, whereas you might have a local object of type
> Cell_Type.
OK. After masticating on this parargraph for a while, I think what you
are saying is that I theoreticly could do this:

   Global : List_Type;
   procedure Local is
      Cell : Cell_Type;
   begin
      Global := Cell.Next_Cell_Part;
   end Local;

..and then after a call to Local, I now have in Global a pointer into
unallocated stack space.

I think what was confusing me was that I'm used to thinking about
accessability levels in record *objects*, not types. But I can't speak
for what was confusing Cohen. :-)

> To avoid the use of "'Unchecked_Access" you could simply default
> initialize to "null,"  You could define a separate function to do the

..or use a second null record with an access discriminant, as I have
seen done elsewhere.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Self-referential types

[Matthew Heaney]

In article <7tvgud$qh7$1@nnrp1.deja.com> , Ted Dennison 
<dennison@telepath.com>  wrote:

> I think what was confusing me was that I'm used to thinking about
> accessability levels in record *objects*, not types.

But it *is* an object.  Inside the declaration of a limited type T, the
expression T'Access refers to the "current instance" of the type.


> But I can't speak for what was confusing Cohen. :-)

I don't understand why you have a smiley there.  Are you saying there's
a mistake in Ada As A 2nd Language?  If so, on what page?  Perhaps there
is just a misunderstanding about what Norm was saying.

Matt

--
Creationists attempt to draw a line between evolutionary biology and the
rest of science by remarking that large-scale evolution cannot be
observed.  This tactic fails.  Large-scale evolution is no more
inaccessible to observation than nuclear reactions or the molecular
composition of water.

Abusing Science: The Case Against Creationism
Philip Kitcher

Re: Self-referential types

[Ted Dennison]

In article <3803bd26_4@news1.prserv.net>,
  "Matthew Heaney" <matthew_heaney@acm.org> wrote:
> In article <7tvgud$qh7$1@nnrp1.deja.com> , Ted Dennison
> <dennison@telepath.com>  wrote:
>
> > I think what was confusing me was that I'm used to thinking about
> > accessability levels in record *objects*, not types.
>
> But it *is* an object.  Inside the declaration of a limited type T,
the
> expression T'Access refers to the "current instance" of the type.

But the accessablity problem exists because it is a *type* declaration,
not an object declaration. If we were talking about an object
declaration, its lifetime would be the same as that of the access type,
and there would be no problem.

> > But I can't speak for what was confusing Cohen. :-)
>
> I don't understand why you have a smiley there.  Are you saying
> there's a mistake in Ada As A 2nd Language?  If so, on what page?
> Perhaps there is just a misunderstanding about what Norm was saying.

To quote from my original posting:
   Below is a code sample that is taken directly from Cohen's AAASL,
   section 11.8.3:

I'm looking at a copy of the second edition. Page numbers can vary in
different printings. But in my copy this part of 11.8.3 is on page 491.

My suspicion is that he got bit by using an early version of Gnat to
compile his examples. I have a very foggy memory that accessability
checks possibly weren't put into Gnat until late '96 or so (I remember a
minor brouhaha resulting from a lot of incorrectly coded Ada95 sources
suddenly breaking on Gnat users). His book is copyrighted 1996.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Self-referential types

[Robert A Duff]

Ted Dennison <dennison@telepath.com> writes:

> I'm trying to create my first self referential type. But there's
> obviously something about this technique I'm missing, because all
> attempts produce compiler errors in multiple compilers.
> 
> Below is a code sample that is taken directly from Cohen's AAASL,
> section 11.8.3:
> 
> procedure Test is
> 
>    type Cell_Type;
> 
>    type List_Type is access all Cell_Type;
> 
>    type Cell_Type is
>      limited record
>         Contents_Part      : String (1..20);
>         Next_Cell_Part     : List_Type := Cell_Type'Access;
>         Previous_Cell_Part : List_Type := Cell_Type'Access;
>      end record;
> begin
>    null;
> end Test;
> 
> Compiling this with Gnat gives me:
> Test.adb:10:43: non-local pointer cannot point to local object
> Test.adb:11:43: non-local pointer cannot point to local object
> 
> I don't see an accesability level problem here, ...

    X: List_Type;

    procedure Nested is
        Local: Cell_Type;
    begin
        X := Local.Next_Cell_Part;
    end Nested;

    Nested;
    
    ... X.all ... -- Here, X is a dangling pointer.

That's the accessibility level problem.  You need to use
'Unchecked_Access, and you need to be careful not to do the above.
The language design tries to prevent dangling pointers
unless you do something "unchecked".

>...and it looks like it
> thinks Cell_Type is an object, not a type.

It *is* an object -- the "current instance" of the type (sort of like
"self" or "this" in some other languages).

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Self-referential types

[Vladimir Olensky]

Ted Dennison wrote in message <7ttb4a$8mq$1@nnrp1.deja.com>...
>I'm trying to create my first self referential type. But there's
>obviously something about this technique I'm missing, because all
>attempts produce compiler errors in multiple compilers.
>
>Below is a code sample that is taken directly from Cohen's AAASL,
>section 11.8.3:
>
>procedure Test is
>
>   type Cell_Type;
>
>   type List_Type is access all Cell_Type;
>
>   type Cell_Type is
>     limited record
>        Contents_Part      : String (1..20);
>        Next_Cell_Part     : List_Type := Cell_Type'Access;
>        Previous_Cell_Part : List_Type := Cell_Type'Access;
>     end record;
>begin
>   null;
>end Test;




It seems that this example  was not tested.

How it is  possible to initialize access variable
by the initial value that is access attribute to type ?
Access attributes can not be applied to type.
It may only be  applied to some object but not to its description.

Also compiles are probably giving  misleading error messages.

If you change your example to:
-------------------------------------
Procedure Test is
    type Cell_Type;
    type List_Type is access all Cell_Type;

    type Cell_Type is    limited record
        Contents_Part : String (1..20);
        Next_Cell_Part : List_Type := null;
        Previous_Cell_Part : List_Type := null;
    end record;

 Wrong_Initialization : List_Type := Cell_Type'Access;

begin
    null;
end Test;
------------------------------------------
than you will have right error message regarding
Wrong_Initialization  varible:

>>>test.adb:14:37: "Access" attribute cannot be applied to type
gnatmake: "test.adb" compilation error

Regards,
Vladimir Olensky

Re: Self-referential types

[Matthew Heaney]

In article <s04ql7cqh1s45@corp.supernews.com> , "Vladimir Olensky" 
<vladimir_olensky@yahoo.com> wrote:

> How it is  possible to initialize access variable
> by the initial value that is access attribute to type ?

Yes, of course it's possible to initialize an access object that is an
access to a type!

For a limited type T, then inside the declaration of the type, the
expression T'Access refers to the "current instance" of the type.

This is something a lot of programmers haven't learned yet.

This is the basis for programming with access discriminants, which is
how you do MI in Ada95.

For example:

  type Handle_Type (Stack : access Stack_Type) is
    limited null record;

  type Stack_Type is
    limited record
      Handle : Handle_Type (Stack_Type'Access);  --!!!
      <other stuff>
    end record;


Here's another example:

  type T is tagged limited private;
...
private

  function Do_Get_Default (O : T) return T2;

  function Get_Default (O : T'Class) return T2;

  type T is
    tagged limited record
       O : T2 := Get_Default (T'Access);  --!!!
    end record;


Where

  function Get_Default (O : T'Class) return T2 is
  begin
    return Do_Get_Default (O);
  end;


This is the idiom you use if you want to let a descendent type change
the default of component declared by the ancestor.



> Access attributes can not be applied to type.

Wrong.

> It may only be  applied to some object but not to its description.

Wrong.

> Also compiles are probably giving  misleading error messages.

No, the compiler was correct.


--
The new standards [for science curricula in Kansas] do not forbid the
teaching of evolution, but the subject will no longer be included in
statewide tests for evaluating students--a virtual guarantee, given the
realities of education, that this central concept of biology will be
diluted or eliminated, thus reducing courses to something like chemistry
without the periodic table, or American history without Lincoln.

Stephen Jay Gould, Time, 23 Aug 1999

Re: Self-referential types

[Ted Dennison]

In article <3802f2db_2@news1.prserv.net>,
  "Matthew Heaney" <matthew_heaney@acm.org> wrote:

> This is the basis for programming with access discriminants, which is
> how you do MI in Ada95.

Is there somewhere I can go to see an example of this kind of MI? The
Rationale says pretty much the same thing, but Cohen's tome doesn't go
over it at all.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Self-referential types

[Matthew Heaney]

In article <7tvjav$se6$1@nnrp1.deja.com> , Ted Dennison 
<dennison@telepath.com>  wrote:

>> This is the basis for programming with access discriminants, which is
>> how you do MI in Ada95.
>
> Is there somewhere I can go to see an example of this kind of MI? The
> Rationale says pretty much the same thing, but Cohen's tome doesn't go
> over it at all.

You can read my posts in the Ada95 design patterns archive.  The
observer and mediator patterns feature the access discriminant
technique.  (Last month (sep 99) I did a whole series on observer
variations.)

<http://www.acm.org/archives/patterns.html>

Let me know if you have trouble finding or understanding the material.

I also recently wrote Indexed_IO (B tree) and Indexed_Sequential_IO (B+
tree) packages.  The File_Type is implemented using the Rosen Trick,
which uses self-reference to get a variable view of an otherwise
constant object.

<http://www.adapower.com/reuse/indexed_io.html>

Matt

--
If we let the Creationists have their way, we may as well go whole hog.
Let us reintroduce the flat-earth theory, the chemistry of the four
elements, and mediaeval astrology.  For these outworn doctrines have
just as much claim to rival current scientific views as Creationism does
to challenge evolutionary biology.

Abusing Science: The Case Against Creationism
Philip Kitcher

Re: Self-referential types

[Robert I. Eachus]

Matthew Heaney wrote:
  
> For a limited type T, then inside the declaration of the type, the
> expression T'Access refers to the "current instance" of the type.
> 
> This is something a lot of programmers haven't learned yet.
> 
> This is the basis for programming with access discriminants, which is
> how you do MI in Ada95.

   I have to butt in here.  It may be how you do MI in Ada, and it is
one way, but I find it ugly.  If you treat a private access type as the
object, then you have to do a bit more work inside the package, but the
exterior looks much cleaner, and the users don't have to use 'Access at
all.  (Often you don't need it inside the package either.)

   The linked list example becomes:

   generic
     type Element is private; --or limited private
   package Lists is
      type List is private;
      procedure Append(L: in out List; E: in Element);
      procedure Prepend(L: in out List; E: in Element);
      procedure Pop(L: in out List; E: out Element);
      function Is_Empty(L: List) return Boolean;
      function First(L: List) return Element;
      function Last(L: List) return Element;
      -- etc
   private
      type Real_List_Element;
      type List is access all List;
      type Real_List_Element is record
        E: Element;
        -- if Element is limited private, you need to declare another
access
        -- type and use it here.
        Next, Previous: List;
      end record;
   end Lists;
       
-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Self-referential types

[Matthew Heaney]

In article <3803B5E3.F96A6DD4@mitre.org> , "Robert I. Eachus" 
<eachus@mitre.org> wrote:

>> This is the basis for programming with access discriminants, which is
>> how you do MI in Ada95.
>
>    I have to butt in here.  It may be how you do MI in Ada, and it is
> one way, but I find it ugly.  If you treat a private access type as the
> object, then you have to do a bit more work inside the package, but the
> exterior looks much cleaner, and the users don't have to use 'Access at
> all.  (Often you don't need it inside the package either.)

I think we're in agreement.

I use access discriminants (indeed, taggedness) strictly as an
implementation technique.  As much as possible you want to push the type
composition infrastructure into the private part of the spec.

For example, most of my observer types only privately derive from
Observer_Type; the public part is just "limited private."

with Clock_Timers;
package Digital_Clocks is

  type Digital_Clock (Timer : access Clock_Timer'Class) is
    limited private;

private

  type Control_Type (Clock : access Digital_Clock) is
    new Limited_Controlled with null record;

  type Digital_Clock (Timer : access Clock_Timer'Class) is
    new Observer_Type (Timer) with record
      Control : Control_Type (Digital_Clock'Access);  --!!!
    end record;

end Digital_Clocks;

Here, Digital_Clock "multiply inherits" from two different parent types.
All the machinery is hidden in the private region, exactly where it
belongs.


I do one better when I observe two subjects simultaneously:

with Master_Timers;
with Slave_Timers;
package Digital_Clocks is

  type Digital_Clock
    (Master : access Master_Timer;
     Slave  : access Slave_Timer) is limited private;

private

  type Master_Obs_Type (Clock : access Digital_Clock) is
    new Observer_Type with null record;

  type Slave_Obs_Type (Clock : access Digital_Clock) is
    new Observer_Type with null record;

  type Control_Type (Clock : access Digital_Clock) is
    new Limited_Controlled with null record;

  type Digital_Clock (...) is
    limited record
      Master_Obs : Master_Obs_Type (Digital_Clock'Access);
      Slave_Obs  : Slave_Obs_Type (Digital_Clock'Access);
      Control    : Control_Type (Digital_Clock'Access);
    end record;

end Digital_Clocks;


Here, Digital_Clock "multiply inherits" from three different parent
types.  But all the machinery is hidden in the private region, exactly
where it should be.

In recent article I showed how to observe individual attributes of a
subject, as compared to observing the subject itself.

If you declare the observer types as children of the subject, then you
can even hide the fact that the subject derives from Subject_Type.

Some guys use public taggedness everywhere with gay abandon.  This is
wrong.  Don't use taggedness unless you need to, and if you do, then
hide it in the private region if you can.

Under no circumstances should you have deep inheritance hierarchies.
Make hierarchies broad and shallow; say, an abstract parent type and a
non-abstract sibling derivations.  (This is the approach I use over and
over again in my articles in the Design Patterns archive.)

I realize this is not the OO approach of other languages, but the
benefits are that you have far less coupling.

These examples (and many more) can all be found in the design patterns
archive.

<http://www.acm.org/archives/patterns.html>


I will be discussing this technique this Sunday (17 Oct 99) during my
Design Patterns tutorial, at this year's SIGAda conference.

Matt


--
The political forces that try to eliminate evolution from science
classrooms impose a narrow, sectarian doctrine on our educational
systems. This imposition represents an affront not only to the
constitutional separation of church and state but also to the moral and
intellectual integrity embedded in that constitution.

<http://www.nabt.org/evolutionks.html>

Re: Self-referential types

[Vladimir Olensky]

Matthew Heaney wrote in message <3803c8bc_2@news1.prserv.net>...
>In article <3803B5E3.F96A6DD4@mitre.org> , "Robert I. Eachus"
><eachus@mitre.org> wrote:

>I will be discussing this technique this Sunday (17 Oct 99) during my
>Design Patterns tutorial, at this year's SIGAda conference.


By the way  are you going to make it available online or available
for download  (e.g. on Adapower tutorials page).
It would be very valuable.

  I found that proceedings and materials of almost all  conferences
are usually neither available online nor for download.
I think this is extremely bad. By such a lot of valuable information just
lost.
Only participants have it.
I think that in case of Ada all proceedings and materials should be
freely available online and for download.
I think that this is one of the ways to promote Ada.
If this work need sponsors I hope that Ada Resource Association
could be such and moreover it could even sponsor the work to make
most valuable Ada books available online (including setting up agreements
with publishers and authors). This could be real investment in Ada.

Regards,
Vladimir Olensky

Re: Self-referential types

[Vladimir Olensky]

Vladimir Olensky wrote in message ...

>  I found that proceedings and materials of almost all  conferences
>are usually neither available online nor for download.


As a matter of fact some time ago I was trying to get some interesting
reports of one of the conferences (I do not remember now it's exact name)
that was held in Europe but found that I  should pay to local Verlag
distributor (which does not exist at my location) to obtain them.
 I was very disappointed.

Here I should mention that SigAda (former Tri-Ada) papers are
available at www.AdaIC.org. For some reason there is no materials
for 1997.
But there is no other direct references from "Reports & Papers"
page to  proceedings (available online)  of other conferences where
Ada related  report were presented.
There were  others that were held not only in US but in Europe also.

May be I was not trying too hard to find them ?
But I do not think it should  hard.


Regards,
Vladimir Olensky

Re: Self-referential types

[Robert Dewar]

In article <s08h609obhk23@corp.supernews.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:

> I think this is extremely bad. By such a lot of valuable
> information just lost.
> Only participants have it.

There is the amazing facility known as a library (I guess the
online crowd have forgotten about these amazing institutions :-)

> I think that in case of Ada all proceedings and materials
> should be
> freely available online and for download.

When authors create works, including conference presentations,
they are copyrighted. It is up to the presenters and organizers
of conferences to decide how available to make the materials.
Consumers always prefer complete availability, producers are
not always willing to comply :-)

I am sure that if you ask the typical net surfer whether XXX
should be freely available online, the answer will be yes for
almost all possible XXX. It is sort of like asking people if
they would like it better if stores would stop charging money
for their merchandise ...

The dynamics here is quite tricky. Even getting the ISO standard
semi-available was a huge effort. Most owners of copyrights
are very nervous about net availability, and are also nervous
about the kind of sentiment expressed here (everything should
automatically be made available free).

Remember that, following the commerce clause of the
constitution, the purpose of copyright is to encourage
creation. It's hard already to get publishers to risk
doing Ada books, if you insist they all be on line, then
one possible outcome is that they will all be on line,
all zero of them, so you have to work for a balance here.


> I think that this is one of the ways to promote Ada.
> If this work need sponsors I hope that Ada Resource
> Association could be such and moreover it could even sponsor
> the work to make
> most valuable Ada books available online (including setting up
agreements
> with publishers and authors).

Ahem .. this is not just a matter of "work .. [to] .. setting
up agreements", there is $$$ involved. Why would a publisher
publish a book, if anyone can download it free? Well there are
legitimate answers to this and a few publishers have been
convinced to publish electronic books, or allow their hard
copy books to be available on line, but this is an exception.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Self-referential types

[Vladimir Olensky]

Robert Dewar wrote in message <7uds5f$ljp$1@nnrp1.deja.com>...
>In article <s08h609obhk23@corp.supernews.com>,
>  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>
>> I think this is extremely bad. By such a lot of valuable
>> information just lost.
>> Only participants have it.
>
>There is the amazing facility known as a library (I guess the
>online crowd have forgotten about these amazing institutions :-)

   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I do not think so. This is more general issue.

Availability of printed information in a library  depends
on where this library is located (country, location etc.).
I am sure that the library of NY university and many
other universities in some countries  have a lot of the
printed materials. A lot of libraries in many countries
do not have many of the published materials.
It is just imposible to have all in an average labrary.
This is also a matter of $$$.
This vary from country to country and in some of them
in order to get some material you should order that
material and wait several weeks or monthes.
After that  one gets  it for limited period of time.
In some countries one should be either student
or proffesor to get access to the university labraries.
Just weight all the efforts for getting needed information
and it will be clear  why now Internet plays such great
role in education (obtaining needed information).
If the materil is available online one can save a lot
of time and efforts.
There are some other issues here that also has
significant impact on that.

In many  cases online internet access is the
only alternative. One can (almost) instantly obtains what
is needed.

Internet now has great positive impact on the progress
and will have much more in the future.


>> I think that in case of Ada all proceedings and materials
>> should be
>> freely available online and for download.


<snipped>

>> I think that this is one of the ways to promote Ada.
>> If this work need sponsors I hope that Ada Resource
>> Association could be such and moreover it could even sponsor
>> the work to make
>> most valuable Ada books available online (including setting up
>agreements
>> with publishers and authors).
>
>Ahem .. this is not just a matter of "work .. [to] .. setting
>up agreements", there is $$$ involved. Why would a publisher
>publish a book, if anyone can download it free? Well there are
>legitimate answers to this and a few publishers have been
>convinced to publish electronic books, or allow their hard
>copy books to be available on line, but this is an exception.


When I said  to "sponsor" I hoped that this would mean to spend
some $$$.
 I had the understanding that  this is one of the goals of the Ada
Resource Association   to promote Ada. To promote something
one need to spend some money for that in a right way.
(Java promotion is a good example of that).

I  just wonder if Ada Resource  Association  has some $$$ to
sponsor and promote Ada in a way described above ?


Regards,
Vladimir Olensky

Re: Self-referential types

[Laurent Guerby]

Robert Dewar <robert_dewar@my-deja.com> writes:
> [...]
> Remember that, following the commerce clause of the
> constitution, the purpose of copyright is to encourage
> creation. It's hard already to get publishers to risk
> doing Ada books, if you insist they all be on line, then
> one possible outcome is that they will all be on line,
> all zero of them, so you have to work for a balance here.
> [...]

The Ada case is a bit special, since 2 Ada books come from work that
were available for free on the net: the book from the "Lovelace"
tutorial and "Ada for C/C++ programmers" which started as a web page.

Also an argument to consider is that if everyone was using copyright
to get the "monopoly" (okay, not the right term) of having something
available on a printed book, there would be no web page and no web at
all! All the information available for free on the web is a proof that
copyright-protected and sold-for-money books are not strictly
necessary to encourage creation.

However as you said, there is a balance to be found there, see Tim
O'Reilly opinions on book publishing on the matter for example.

--LG

Re: Self-referential types

[Ted Dennison]

In article <3803c8bc_2@news1.prserv.net>,
  "Matthew Heaney" <matthew_heaney@acm.org> wrote:
> In article <3803B5E3.F96A6DD4@mitre.org> , "Robert I. Eachus"
> <eachus@mitre.org> wrote:
>

>   type Digital_Clock (...) is
>     limited record
>       Master_Obs : Master_Obs_Type (Digital_Clock'Access);
>       Slave_Obs  : Slave_Obs_Type (Digital_Clock'Access);
>       Control    : Control_Type (Digital_Clock'Access);
>     end record;

Ok...What does this buy you over using non-anonomous access fields and
an initilization? And how does this constitute MI?

> Some guys use public taggedness everywhere with gay abandon.  This is
> wrong.  Don't use taggedness unless you need to, and if you do, then
> hide it in the private region if you can.

Hmm. Generally I do that so that someone who wants to extend a new type
that I haven't thought of doesn't have to put it in a child package. But
admittedly, I don't myself derive new types without putting them in
child packages. So perhaps I'm allowing too much freedom?

> I will be discussing this technique this Sunday (17 Oct 99) during my
> Design Patterns tutorial, at this year's SIGAda conference.

Hmmm. It would be nice to attend that. But I don't think I could sell
enough candy bars at work in the next couple of days to pay for the
trip. :-)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Self-referential types

[Matthew Heaney]

In article <7u25pu$p4k$1@nnrp1.deja.com> , Ted Dennison 
<dennison@telepath.com>  wrote:

>>   type Digital_Clock (...) is
>>     limited record
>>       Master_Obs : Master_Obs_Type (Digital_Clock'Access);
>>       Slave_Obs  : Slave_Obs_Type (Digital_Clock'Access);
>>       Control    : Control_Type (Digital_Clock'Access);
>>     end record;
>
> Ok...What does this buy you over using non-anonomous access fields and
> an initilization? And how does this constitute MI?

Because the observer types have a primitive operation (Update) called by
their subject.  The Master_Timer subject calls back the Master_Obs
component of the Digital_Clock, and the Slave_Timer subject calls back
the Slave_Obs component.

See the article about multiple subjects in the design patterns archive,
from whence this was paraphrased.

Perhaps it would have been more obvious to have done it this way:

  type Digital_Clock (...) is
    new Limited_Controlled with record
      Master_Obs : Master_Obs_Type (Digital_Clock'Access);
      Slave_Obs  : Slave_Obs_Type (Digital_Clock'Access);
    end record;

Syntactically, Digital_Clock has only a single parent,
Limited_Controlled.  But logically, it has three parents
(Limited_Controlled once, and Observer_Type twice).


Matt

--
The theory of evolution is quite rightly called the greatest unifying
theory in biology.  The diversity of organisms, similarities and
differences between kinds of organisms, patterns of distribution and
behavior, adaptation and interaction, all this was merely a bewildering
chaos of facts until given meaning by the evolutionary theory.

Populations, Species, and Evolution
Ernst Mayr

Re: Self-referential types

[Robert I. Eachus]

Matthew Heaney wrote:
> 
> In article <3803B5E3.F96A6DD4@mitre.org> , Iwrote:

> >    I have to butt in here.  It may be how you do MI in Ada, and it is
> > one way, but I find it ugly.  If you treat a private access type as the
> > object, then you have to do a bit more work inside the package, but the
> > exterior looks much cleaner, and the users don't have to use 'Access at
> > all.  (Often you don't need it inside the package either.)
> 
> I think we're in agreement.

   I'm not sure we are, since I was addressing a slightly different
point.
You pass access parameters in cases where I pass a private access type
to
eliminate any visible (to the user of the abstraction) use of 'Access. 
If you need to make subclassing visible, you end up making the use of
access parameters necessary, but I believe that public subclassing is a
bad thing, and that most visible subclassing should be done using
generic packages to do mix-ins.  I wasn't really criticizing your
approach, just pointing out that
Ada supports two different idioms in this area.

> Under no circumstances should you have deep inheritance hierarchies.
> Make hierarchies broad and shallow; say, an abstract parent type and a
> non-abstract sibling derivations.  (This is the approach I use over and
> over again in my articles in the Design Patterns archive.)

  Amen!  Even when I have lots of generic mixins in the private part,
the Ada idiom seems to be that there are three types of classes:
abstract root classes,
intermediate (again abstract) subclasses when doing mixins, and the
(non-abstract) visible classes that actually have objects associated
with them.  In Ada is is almost always a bug to have a non-abstract
parent of a class.
 
> I realize this is not the OO approach of other languages, but the
> benefits are that you have far less coupling.
 
  Amen again.  Have you ever read "Nesting in Ada is for the Birds" by
Lori Clarke, and others?  It was written before Ada 83 was finalized,
and discussed the same beneficial effect on coupling when you removed
nesting of procedures.

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Self-referential types

[Brian Rogoff]

On Wed, 13 Oct 1999, Robert I. Eachus wrote:
>   Amen again.  Have you ever read "Nesting in Ada is for the Birds" by
> Lori Clarke, and others?  It was written before Ada 83 was finalized,
> and discussed the same beneficial effect on coupling when you removed
> nesting of procedures.

Does it discuss the detrimental effect on lots of other aspects of Ada
when you remove nesting of procedures?

-- Brian

Re: Self-referential types

[Robert I. Eachus]

Brian Rogoff wrote:
 
> Does it discuss the detrimental effect on lots of other aspects of Ada
> when you remove nesting of procedures?

   Okay, I'll bite what are they?  Note that nesting of procedures
refers to
procedures declared inside other procedures, not procedures called
inside other procedures, or within packages.

   AFIAK, it is almost always poor engineering to declare procedures
within other procedures in Ada. The chief exception is recursive descent
parsers, and even in that case there are good arguments for using
unnested procedures.  Also there are cases where you want to break a
procedure into subunits for implementation reasons:

   procedure A (Some: Parameters) is
     Some_Local: Variables;
     procedure Start is separate;   -- Ed will write
     procedure Do_It is separate;   -- Joe is doing this
     procedure Cleanup is separate; -- Ed again
   begin Start; Do_It; Cleanup; end A;

   Often though, those separates disappear before the code is entered
into the CM system.  Ada lets fold called once procedures back in as
declare blocks with no change in semantic interpretation.

   Note also that I am talking about procedures.  Many (nested)functions
in Ada would be implemented in other languages as macros.  Using such
inlined functions is good programming practice in Ada.  

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Self-referential types

[Marin David Condic]

"Robert I. Eachus" wrote:

>    AFIAK, it is almost always poor engineering to declare procedures
> within other procedures in Ada. The chief exception is recursive descent
> parsers, and even in that case there are good arguments for using
> unnested procedures.  Also there are cases where you want to break a
> procedure into subunits for implementation reasons:
>

This debate has been around before and a case has been made on the other
side. Similar to the Cobol "perform", nested procedures give you a way of
grouping blobs of code under some sort of descriptive name which helps
clarify the main body of the code - especially where the main body of the
code might otherwise become too deeply nested in control sturctures. For
example:

procedure Process_Payroll is
    procedure Read_In_Transaction_Trapping_Device_Errors (
        Trans : out Trans_Type) is
    begin
        --Use Your Imagination
    end Read_In_Transaction_Trapping_Device_Errors ;
    function Transaction_Successfully_Read return Boolean is
    begin
        --More of the same...
    end Transaction_Successfully_Read ;
    procedure Edit_Transaction_For_Keypunch_Errors (
        Trans : in out Trans_Type) is
    begin
        --Fill in the blanks.
    end Edit_Transaction_For_Keypunch_Errors ;
begin
    --blahblahblah

    while (not End_Of_File (Trans_File)) loop
        Read_In_Transaction_Trapping_Device_Errors (Trans) ;
        if (Transaction_Successfully_Read) then
            Edit_Transaction_For_Keypunch_Errors (Trans) ;
        end if ;
        --yadayadayada
    end loop ;

    --blahblahblah
end Process_Payroll ;

You can always export the nested procedures by making them "is separate" or
just stand-alone procedures brought in with a "with" clause, but if the code
volume is not too large and the access to common data is high, I'd prefer to
see it local to the same file from which it is called. I wouldn't think of
that as bad software engineering or bad style. It all depends on if it is
helping you clarify what you are doing and is not being badly overused.

Obviously, after "a certain size" you probably want these things in separate
units for configuration management, reusability and other concerns. What is
the threshold? I'd say "As many lines as you can read while holding your
breath." :-)

MDC
--
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.mcondic.com/

Re: Self-referential types

[Robert I. Eachus]

Marin David Condic wrote:
 
> This debate has been around before and a case has been made on the other
> side. Similar to the Cobol "perform", nested procedures give you a way of
> grouping blobs of code under some sort of descriptive name which helps
> clarify the main body of the code - especially where the main body of the
> code might otherwise become too deeply nested in control sturctures.

  But this is the wrong way to do that in Ada. There are two similar
cases and several structurally different ways to organize them.  First
if there is no shared local data common to all of the subprograms, or if
tasking is not an issue, you can put the local data in a package body. 
The package exports the subprograms, and the driver just contains a few
calls and perhaps some logic:

package Payroll is
  procedure Read_In_Transaction_Trapping_Device_Errors (
     Trans : out Trans_Type); 
  function Transaction_Successfully_Read return Boolean;
  procedure Edit_Transaction_For_Keypunch_Errors (
     Trans : in out Trans_Type);
end package Payroll;

with Payroll; use Payroll;
procedure Process_Payroll is
begin
  --blahblahblah
  while (not End_Of_File (Trans_File)) loop
    Read_In_Transaction_Trapping_Device_Errors (Trans) ;
    if (Transaction_Successfully_Read) then
       Edit_Transaction_For_Keypunch_Errors (Trans) ;
    end if ;
     --yadayadayada
  end loop ;
     --blahblahblah
end Process_Payroll ;

   Why is this better?  Because it promotes reuse.  Other payroll
operations can be created which share some, but not all, of the
subroutines used by Process_Payroll.

   The other case, of course, is where you have many payroll objects and
need local data for each, whether or not tasking is involved.  You can
either create payroll objects and store the local data as part of their
state, create a task type to represent the instances, or (usually best)
create an instance of a generic package for each payroll.  The
instantiation of this package may be internal to Process_Payroll, or
Process_Payroll can be just another declaration in that package.

   But in any case, the "right" place to keep state in Ada is almost
always in packages or tasks, not subprogram bodies.

   I'll tell you a (now oft-told) story about this.  At Honeywell we
implemented an in house cross-compiler from Multics to the DPS-6
series.  During the implementation, we had no idea whether the best way
to find uplevel references in the stack would be via static links or a
display.  Multics being Multics, we put a counter in the compiler, with
a feature to squirrel away the source whenever an uplevel reference was
encountered.  It also sent mail to the Ada compiler group every morning
if it trapped a reference.  (The compiler was installed on several
Multics machines, but they were all connected to the ARPAnet.)  Oh, the
compiler also did a full call tree trace to allow the code generator to
combine the stack frame of a nested procedure with its parent if the
compiler could determine that there were no recursive calls, and no
stack objects whose size depended on the parameters to the inner
procedure.

   I finally set the trap off two and half years later, while we were
running the ACVC tests.

   Needless to say, we implemented neither static links or a display,
and just left in the code (in the run time) which walked down the call
stack until it found the statically containing frame.  Potentially very
slow if there was an uplevel reference, but as we had shown, wasting
even one clock per stack frame created would have been slower on the
average.  (Note that the 'dynamic' walk was needed for exceptions in any
case.)

   As a result, not only that compiler, but most Ada compilers, are
tailored to the expected feature usage.  Anyone who violates those
assumptions will be penalized by slow code.  (Another example is
exceptions, in Ada the compiler author will try to lower the cost of
creating exception handler scopes at the cost of extra overhead when an
exception occurs.  Therefore, you are much better off checking in the
code for conditions that are not all that rare.)
 

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Self-referential types

[Robert Dewar]

In article <38079D6F.4F7C00FA@mitre.org>,
  "Robert I. Eachus" <eachus@mitre.org> wrote:
>   But this is the wrong way to do that in Ada. There are two
similar
> cases and several structurally different ways to organize
them.  First
> if there is no shared local data common to all of the
subprograms, or if
> tasking is not an issue, you can put the local data in a
  ^^^^^^^^^^^^^^^^^^^^^^^

Ah ha! There it is. The trouble is that the creator may not
think tasking is an issue, but later on a consumer is interested
in task safety. PLEASE PLEASE default your thinking to assume
that tasking *is* an issue, and make thinks task safe by
default. Only introduce (well documented!) thread non-safety
deliberately if there is a VERY good reason for it.

package body.
> The package exports the subprograms, and the driver just
contains a few
> calls and perhaps some logic:


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Self-referential types

[Robert I. Eachus]

Robert Dewar wrote:
  
> Ah ha! There it is. The trouble is that the creator may not
> think tasking is an issue, but later on a consumer is interested
> in task safety. PLEASE PLEASE default your thinking to assume
> that tasking *is* an issue, and make thinks task safe by
> default. Only introduce (well documented!) thread non-safety
> deliberately if there is a VERY good reason for it.

    Sorry, that was an aside that could be misleading.  I was referring
to a different issue:  The cases where the outer  procedure creates one
or more tasks.  These cases are somewhat harder to deal with because of
the rules about masters and when a scope is left.  For instance if you
move a task out of a procedure, so its entries are visible to other
(formerly nested) procedures, then you may have to add explicit code to
terminate the tasks at the right point in time.  This is why you may
want to instantiate a generic package inside the procedure to get the
right semantics without kludges.

    In the cases Robert Dewar is talking about, where tasking is not
dealt with in otherwise sharable code, you can often factor the tasking
out at a higher level.  I often wrap procedures this way:

  procedure Protected_Foo is begin Lock.Seize ; Foo; Lock.Release; end;
  -- add parmeters to taste.

  This provides both tasking and non-tasking safe versions.  It will
work correctly even if Foo is recursive.  The other way to deal with
potential tasking is to pass all shared data in one or more explicit
parameters.  This way the caller can do anything necessary at his
level.  The random number packages in Ada are a result of this type of
thinking.  Since they pass a generator object around, it is up to the
user in a tasking environment to decide which tasks should share
generators and how.


-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Self-referential types

[Robert Dewar]

In article <38077EB3.E6911567@mitre.org>,
  "Robert I. Eachus" <eachus@mitre.org> wrote:
> Brian Rogoff wrote:
>
>    AFIAK, it is almost always poor engineering to declare
procedures
> within other procedures in Ada. The chief exception is
recursive descent
> parsers.

What an *amazing* statement. I am completely flabbergasted!

First, I don't see recursive descent parsers as being
relevant here, and see no reason for nesting there.

There are however MANY MANY examples where nesting makes
excellent sense, and IMO any language that does not permit
nested procedures is badly broken,

There are zillions of reasons for nesting, but let me just
give two.

1. Localization of names. If you have a small procedure that
is just called a couple of times within a single procedure,
it is FAR better to restrict its name space by nesting it
within the calling procedure, and it is indeed very bad
style to unnest it in this case. One particular case is
where you have a recursive implementation of a non recursive
procedure interface for the client, often referencing one
of the parameters of the outer procedure non-locally.

2. Nested procedures makes it FAR easier to make things thread
safe, because you can have variables that are "global" to a set
of cooperating procedures, but are still on a local
thread-specific stack of the enclosing procedurers.
In a language without nested procedures, you often see real
global variables used for this purpose, which is a common
source of non-thread safeness. Yes, you can take the position
that you should never have any non-local references, but this
often obfuscates the code and is error prone.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Self-referential types

[Brian Rogoff]

On Mon, 18 Oct 1999, Robert Dewar wrote:
> In article <38077EB3.E6911567@mitre.org>,
>   "Robert I. Eachus" <eachus@mitre.org> wrote:
> >    AFIAK, it is almost always poor engineering to declare
> procedures
> > within other procedures in Ada. The chief exception is
> recursive descent
> > parsers.
> 
> What an *amazing* statement. I am completely flabbergasted!
> 
> First, I don't see recursive descent parsers as being
> relevant here, and see no reason for nesting there.

The argument I hear is that by nesting the inner parsing routines have 
no arguments, FWIW. 

Also, when writing backtracking recursive descent parsers (OK, I've only
done it once in Ada :-) the solution with procedure nesting and procedure 
parameters (faked with generics in Ada) seems fairly understandable to me. 

> There are however MANY MANY examples where nesting makes
> excellent sense, and IMO any language that does not permit
> nested procedures is badly broken,

I agree, but IMO the readability argument, perhaps subsuming your 
arguments, is important enough that all other considerations are
secondary. I find this true even in "sequential" Ada.

-- Brian

> 
> There are zillions of reasons for nesting, but let me just
> give two.
> 
> 1. Localization of names. If you have a small procedure that
> is just called a couple of times within a single procedure,
> it is FAR better to restrict its name space by nesting it
> within the calling procedure, and it is indeed very bad
> style to unnest it in this case. One particular case is
> where you have a recursive implementation of a non recursive
> procedure interface for the client, often referencing one
> of the parameters of the outer procedure non-locally.
 > 
> 2. Nested procedures makes it FAR easier to make things thread
> safe, because you can have variables that are "global" to a set
> of cooperating procedures, but are still on a local
> thread-specific stack of the enclosing procedurers.
> In a language without nested procedures, you often see real
> global variables used for this purpose, which is a common
> source of non-thread safeness. Yes, you can take the position
> that you should never have any non-local references, but this
> often obfuscates the code and is error prone.
> 
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.
> 
> 

Re: Self-referential types

[Ed Falis]

On Mon, 18 Oct 1999 01:23:27 GMT, Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <38077EB3.E6911567@mitre.org>,
>   "Robert I. Eachus" <eachus@mitre.org> wrote:
> > Brian Rogoff wrote:
> >
> >    AFIAK, it is almost always poor engineering to declare
> procedures
> > within other procedures in Ada. The chief exception is
> recursive descent
> > parsers.
> 
> What an *amazing* statement. I am completely flabbergasted!

Just so it's clear (which it's not from the quoting above),  I'm pretty
sure it was Eachus, not Rogoff, who made the comment this 
starts with.

- Ed

Re: Self-referential types

[Robert Dewar]

In article <1103_940211488@DZOG-CHEN>,
  falis@ma.aonix.com (Ed Falis) wrote:
> On Mon, 18 Oct 1999 01:23:27 GMT, Robert Dewar
<robert_dewar@my-deja.com> wrote:
> > In article <38077EB3.E6911567@mitre.org>,
> >   "Robert I. Eachus" <eachus@mitre.org> wrote:
> > > Brian Rogoff wrote:
> > >
> > >    AFIAK, it is almost always poor engineering to declare
> > procedures
> > > within other procedures in Ada. The chief exception is
> > recursive descent
> > > parsers.
> >
> > What an *amazing* statement. I am completely flabbergasted!
>
> Just so it's clear (which it's not from the quoting above),
I'm pretty
> sure it was Eachus, not Rogoff, who made the comment this
> starts with.
>
> - Ed
>

Yes, I understood it to be a comment from Eachus, and that's
why I was flabbergasted :-) If it had been from
some one else, I would
not have been so suprised :-) :-)

Sorry for unclear quoting


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Self-referential types

[Robert I. Eachus]

   It is nice to be so respectfully disagreed with by so many people,
and so
quickly too. ;-)  However, I don't think they are really disagreeing
with my point, just with the words I used to say it.

   Let's say you have an otherwise large subprogram, with a lot of
complexity and a lot of hidden scope variables and data, you have two
choices of how to implement it:

   You can create a procedure or function with a lot of other nested
subprograms, or

   You can create a package with the shared state in the body, and the
previous complex procedure as a public interface to that package.

   In Ada you should almost always (there are those words again) choose
the later.  The exceptions tend to be those cases where the enclosing
subprogram has lots of record or array parameters.  But that is normaly
bad programming practice.

   To specifically address Richard Riehle's comments, I tend to do the
same thing as he does with case statements, but I unnest the case
alternatives and put them in a package.  If there is local state needed
from the enclosing procedure, I make it a generic package and
instantiate it locally to pass the parameters of the enclosing
procedure.

   Doing all this takes effort.  You have to think about what state is
getting passed where.  (Unless, of course, you did all that right during
detailed design. ;-) I refuse to see that as anything other than a
benefit.  I can't begin to count the number of times I have caught
subtle programming or design bugs this way, and of course the
maintenance programmer will love you for it.  Well, maybe that is a bit
strong.  Certainly he or she won't detest you, and may even say hello in
the hallway or the cafeteria.  Of course, if you get stuck with the
maintenance job, you will find yourself saying, "Gee, I'm glad I did
this right," rather than "What the hell was I thinking when I wrote
this."

  I could give examples, but why bother.  Everyone reading this must
have had the experience of a subtle bug caused by undocumented (and
usually unintended) coupling between otherwise unrelated units.
   
-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Self-referential types

[Richard D Riehle]

In article <380BA036.E9F51F22@mitre.org>,
	"Robert I. Eachus" <eachus@mitre.org> wrote:

>   To specifically address Richard Riehle's comments, I tend to do the
>same thing as he does with case statements, but I unnest the case
>alternatives and put them in a package.  If there is local state needed
>from the enclosing procedure, I make it a generic package and
>instantiate it locally to pass the parameters of the enclosing
>procedure.

I agree with this principal.  In fact, with the advent of private
child packages, one can promote these little procedures to a next
level above the procedure in which they would have been nested and
leverage their visibility through private package specifications within
the same parent-child hierarchy.  As you so carefully note in your
message, this does require some planning.   In a large-scale development
effort, planning at this level of detail is often absent from the
process.  

Richard Riehle
http://www.adaworks.com

Re: Self-referential types

[Robert I. Eachus]

Richard D Riehle wrote:
>                                        As you so carefully note in your
> message, this does require some planning.   In a large-scale development
> effort, planning at this level of detail is often absent from the
> process.

    I think that this really sums it all up.  Fortunately less often
recently, I get put on "Red Teams" to decide if some project can be
saved, and if so how.  (And for how much, or whether it is better to
cancel it anyway.)

    So from my experience, too many nested procedures is an indication
of (very) bad design.  As I also said, nested functions, usually small,
don't seem to imply bad design, but nested procedures do.  If I were to
make this a serious metric by itself, I would use something like, for
each procedure start with zero.  Climb to the root, and for each
nesting, if inside another subprogram or task entry add one.  Sum over
all procedures and divide by the number of procedures to normalize.

    I could then set up a scale: 0.1 or less very good,...0.5
acceptable, >1.5
reject.  I don't for two reasons.  First I have some coupling measures
which do a better job, and second, you don't need a scale.  Most code is
either near zero, around one, or over three...

    In fact, MITRE did do a lot of work on coupling and cohesion
measures using DIANA a few years ago--I would lie to update the tools to
use ASIS.
But in reality, these tools were of no use at all.  The results were
either, "Gee, this is just short of perfection, can you do anything
about package XXX?" or "This code sucks, but you knew that just from the
effort to get it processed by the front-end of the tool.  There is no
reason to tell you where it sucks or how to fix it.  But if you care the
answers are 'everywhere' and 'don't'."

    Incidently, I took a look at some of the GNAT library packages.  For
almost all of them, the count as expressed above would be zero.  The
exceptions?  Explicit finite state such as in GNAT.Regexp, where such
structure is completely justified.  But while Robert Dewar and I may
write such code, most programmers never do.

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Self-referential types

[Wes Groleau]

> Personally I use (at least I try too, I don't always succeed) nested
> procedures to increase code clarity.

It generally has that effect for me.

> This reduces the overall clutter in a unit, and I find it a lot easier
> to check my overall logic if I do this, it doesn't eliminate the need
> for comments (or indeed, proper written documentation), but it does
> make the program easier to understand. YMMV.

If good naming conventions are used, it can _greatly_ reduce the need
for comments.

Re: Self-referential types

[Robert Dewar]

In article <380CA5AC.82499FE2@ftw.rsc.raytheon.com>,
  Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
> If good naming conventions are used, it can _greatly_ reduce
> the need for comments.

My own view is that good names are an *adjunct* to good
comments, not a substitute for them.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Self-referential types

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 949 bytes --]


Robert Dewar <robert_dewar@my-deja.com> a �crit dans le message :
7um9ji$dor$1@nnrp1.deja.com...
> In article <380CA5AC.82499FE2@ftw.rsc.raytheon.com>,
>   Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
> > If good naming conventions are used, it can _greatly_ reduce
> > the need for comments.
>
> My own view is that good names are an *adjunct* to good
> comments, not a substitute for them.
>
I would say it the other way round:
Not everything can be put in good names, therefore comments are necessary to
express what cannot be put in the name.
But if the info is in the name, then it is repeated each time it is used;
therefore, I would discourage something like this:
LL : Natural ; -- this is the line length

in favour of the (comment-less):
Line_Length : Natural;

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

Re: Self-referential types

[Robert Dewar]

In article <7un1me$6jm$1@wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> LL : Natural ; -- this is the line length
>
> in favour of the (comment-less):
> Line_Length : Natural;


Yes, but I am guessing that in context I would not like EITHER
of these alternatives, instead probably what is needed is
something like:

Line_Length : Natural;
--  This is the length of the current line, not including the
--  terminating control characters. It is set each time a new
--  command is processed, and reflects the length of the command
--  after stripping trailing spaces.


Well the details will vary, but you get the idea, comments very
often need to express far more detail than can be contained in
a reasonable length name. If anything, the name Line_Length is
more dangerous than LL in this regard, since it can seduce the
programmer into thinking that documentation is not required.

I actually prefer a rule that says that comments should be
independent of names. Yes, that might lead to overcommenting
in some rare instances, but that's a disease that I can put
up with much better than the serious epidemic of under
commenting :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Self-referential types

[Larry Kilgallen]

In article <7um9ji$dor$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <380CA5AC.82499FE2@ftw.rsc.raytheon.com>,
>   Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
>> If good naming conventions are used, it can _greatly_ reduce
>> the need for comments.
> 
> My own view is that good names are an *adjunct* to good
> comments, not a substitute for them.

Well try this wording:

	If bad naming conventions are used, it can _greatly_ increase
	the need for comments.


	Example:

		declare

			--
			-- Despite what you might infer from our efforts
			-- to cloak the symbol table, the following
			-- contains the number of miles to the next city.
			--

			Weight_In_Kilograms : NATURAL := 0;

:-)

Larry Kilgallen

Comments (was: Self-referential types)

[Wes Groleau]

> > If good naming conventions are used, [nested procedures] 
> > CAN greatly reduce the need for comments.
> 
> My own view is that good names are an *adjunct* to good
> comments, not a substitute for them.

My own view is comments like the following are worse than 
unnecessary, they are pure clutter:

  -- check whether the current transaction is completed
  if Is_Completed (Current_Transaction) then

     -- if so, close the source and destination DB files
     DB_IO.Close (Source);
     DB_IO.Close (Destination);

I can't count the number of times I have seen code (in many 
languages) with many useless comments like the above, but
with NONE of the comments it really needed.

I suspect "my own view" and "your own view" are the same,
but we're applying them to different things.

Re: Comments (was: Self-referential types)

[Ehud Lamm]

On Thu, 21 Oct 1999, Wes Groleau wrote:

|My own view is comments like the following are worse than 
|unnecessary, they are pure clutter:
|
|-- check whether the current transaction is completed
|if Is_Completed (Current_Transaction) then
|

See my "Guidelines for checking exerices" on my Ada page, section 4.
It is stated rather extermely, so don't jump on me...

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: Comments (was: Self-referential types)

[Ted Dennison]

In article
<Pine.A41.3.96-heb-2.07.991021191504.30582K-100000@pluto.mscc.huji.ac.il
>,
  Ehud Lamm <mslamm@mscc.huji.ac.il> wrote:
> On Thu, 21 Oct 1999, Wes Groleau wrote:
>
> |My own view is comments like the following are worse than
> |unnecessary, they are pure clutter:
> |
> |-- check whether the current transaction is completed
> |if Is_Completed (Current_Transaction) then
> |
>
> See my "Guidelines for checking exerices" on my Ada page, section 4.
> It is stated rather extermely, so don't jump on me...

I generally disagree with #5 (using some brainless "naming convention"
to distinguish types/variables/constants rather than simply naming them
appropriately for the job they do). But, as has been shown here numerous
times in the past, its a quite debatable point.

However, it might be a good idea to point out the more contraversial
points of your standard to your students, so that they are exposed to
the pro and con viewpoints. They still have to follow *your* standard in
class, of course. :-)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Comments (was: Self-referential types)

[Ehud Lamm]

In article <7uponp$s4h$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> In article

>
> I generally disagree with #5 (using some brainless "naming convention"
> to distinguish types/variables/constants rather than simply naming them
> appropriately for the job they do). But, as has been shown here numerous
> times in the past, its a quite debatable point.
>
> However, it might be a good idea to point out the more contraversial
> points of your standard to your students, so that they are exposed to
> the pro and con viewpoints. They still have to follow *your* standard in
> class, of course. :-)
>
> --
> T.E.D.


I already posted a reply, but since it seems that it got lost somewhere
inside deja, I'll give the gist of it again.

My students and I debate most of these issues, anyway.

My 'philosophy' is best captured by guidline #9: explanations and reasoning
are much more important than any God-like rule. I much prefer understanding
to following orders...

P.S If someone did see my previous reply, let me know. It is really
intriguing to know where it ended up... :-)

--
Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm
Check it out and subscribe to the E-List


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Comments (was: Self-referential types)

[Robert Dewar]

In article
<Pine.A41.3.96-heb-2.07.991021191504.30582K-100000@pluto.mscc.hu
ji.ac.il>,
  Ehud Lamm <mslamm@mscc.huji.ac.il> wrote:
>4. Don't put in too many comments in the code. I want tov be
able to see
>the code itself. Do not have comments like "loop from 1 to 10"
- I can
>read the code. Comments SHOULD appear at the start of logical
sections
>(those that have a specific functionality).

I think this is dangerous advice to students, since they hate
commenting,
and a suggestion that puts the don't in front of the "do" here
is upside
down. Over-commenting is easily correctable, a life long
aversion to
writing any comments, which seems to aflict many programmers, is
hard
or impossible to cure. At first students will tend to over
comment a bit,
because they don't understand the code as well as you do, but I
think it is
a tactical mistake to step on that tendency to early on.

>5. Use a coding convention that distinguishes types/variables
and
>constants. I suggest name like "Student_Record" for variables
(first
>letter capitalized), names like MAXSTUDENT fro constants, and
names like
>student_record_type for types. But you may choose you own.
After you
>choose, stick to one standard.

I do not consider this helpful at all, and I particularly
dislike the
C-style all caps for constants. So I agree with Ted here. I
don't
think that arbitrary rules like this are the least bit helpful

   X : Universal_Integer_Type;

is ugly, when obviously the name Universal_Integer is a noun
that is just
right for use as a type name.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Comments (was: Self-referential types)

[Ehud Lamm]

In article <7ur1gn$q5h$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article
> <Pine.A41.3.96-heb-2.07.991021191504.30582K-100000@pluto.mscc.hu
> ji.ac.il>,
>   Ehud Lamm <mslamm@mscc.huji.ac.il> wrote:
> >4. Don't put in too many comments in the code. I want tov be
> able to see
> >the code itself.
>
> I think this is dangerous advice to students, since they hate
> commenting,
> and a suggestion that puts the don't in front of the "do" here
> is upside
> down. Over-commenting is easily correctable, a life long
> aversion to
> writing any comments, which seems to aflict many programmers, is
> hard
> or impossible to cure. At first students will tend to over
> comment a bit,
> because they don't understand the code as well as you do, but I
> think it is
> a tactical mistake to step on that tendency to early on.
>

I make my student comment like crazy. This just points out that really
useless comments are not what I am looking for. I, like you, am very much in
favour of thourgh commenting - and no studunet of mine can fail to notice
that after seeing the remarks on his first exercise...

>  But you may choose you own.
> After you
> >choose, stick to one standard.

This is the major part of the guideline, which both you and Ted didn't
appreciate.

>I particularly dislike the
> C-style all caps for constants. So I agree with Ted here. I
> don't
> think that arbitrary rules like this are the least bit helpful
>
>    X : Universal_Integer_Type;
>
> is ugly, when obviously the name Universal_Integer is a noun
> that is just
> right for use as a type name.
>

Most of the time, esp. in Ada I agree that name like Index_Type and
Number_type are not verey elegant. I prefer giving good names (for example
following the noun/adjective distinction etc.) - and this is why (among other
reasons) I am willing to accept almost any half decent standard -as long as
the programmer is consistent. don't call one variable AVARIABLE and the next
on iVAR (following Hungarian). Decide what you prefer. We can argue about
your choice, but at this is a legitimate argument - in most cases.

So why did I give the advice I gave, which both you and Ted don't li,e, and
which I myself am not willing to defend "to the death?"

Well, you have to remember that for most of my students English is a foreign
language. So they tend to use bad names - for lack of vocab or language
skills. They tend to miss  the noun/verb distinction when naming functions
and procedures etc. So instead of saying "choose good names," which may leave
them in the dark I give one solution - even if it is not great. They are free
to choose their own naming scheme. Usually I don't really mind - so long as
the code is readable.

One more reason for the guideline is that I want the guidlines to provide
information, that may otherwise be lacking. So I prefer giving an exmaple of
a standard - even if it is not desribed completly, just so that the students
will have a better grasp of what I am talking about.

Consider waht I require from comments. I say 'name, student number, question
number, and general description of routine."  Of course for a hefty package
this is barely enough. I know that, and so do they. This is just a beginning.
When I teach about packages, ADTs, ADOs - I take time to discuss what seems
reasonable to include in the comments accompanying such modules.

Thanks for your comments. Maybe some student will see them, and we will have
a discussion about it....


--
Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm
Check it out and subscribe to the E-List


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Comments

[Georg Bauhaus]

Ehud Lamm <mslamm@mscc.huji.ac.il> wrote:

: Well, you have to remember that for most of my students
: English is a foreign language. So they tend to use bad
: names - for lack of vocab or language skills. They tend to
: miss  the noun/verb distinction when naming functions and
: procedures etc.

So, wouldn't it seem advisable to have "Natural Language
Skills" in the curriculum? At least for non-english speakers
(like me :-|)?  While there is ongoing talk about The
Globalisation (again), I can see that students are advised
to learn a foreign language, but are otherwise left alone -
the plans for their time at universities do not, in general,
explicitely include slots for other skill that are nevertheless
considered essential.

As an aside, knowing how to use a typewriter seems also to be
helpful, yet this isn't taught, is it? :-)

-# Georg Bauhaus

Re: Comments

[Ehud Lamm]

In article <7usvo6$9kq$1@news-hrz.uni-duisburg.de>,
  Georg Bauhaus <georg@zorro.uni-duisburg.de> wrote:

>
> So, wouldn't it seem advisable to have "Natural Language
> Skills" in the curriculum? At least for non-english speakers
> (like me :-|)?  While there is ongoing talk about The
> Globalisation (again), I can see that students are advised
> to learn a foreign language, but are otherwise left alone -
> the plans for their time at universities do not, in general,
> explicitely include slots for other skill that are nevertheless
> considered essential.
>

The students must pass an exam on English as a second language, or pass an
English course. But this just isn't enough.

I am all for language skills. Alas most people lack them - even in their
native tongues.

Most people fial in phrasing questions, so it is natural that student fail in
phrasing answers - even when they know them!

(By the way: i started a thread on this in several groups, under the title
"formulating good questions").

This is whole subject is off topic here. But as often mentioned in other
groups Dijkstra suposedly said that you can tell if someone is a good
programmer by judging their native language skills.

--
Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm
Check it out and subscribe to the E-List


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Comments

[Robert I. Eachus]

Ehud Lamm wrote:
 
> This is whole subject is off topic here. But as often mentioned in other
> groups Dijkstra suposedly said that you can tell if someone is a good
> programmer by judging their native language skills.

   Let's not try to make this an urban legend.  He said exactly that.
Well, I think his exact words were: "The best predictor of a student's
success as a software engineer is his skill in using his native native
language."  In any case, he said it at a software engineering conference
in early June 1979--over twenty years ago, ouch!  He also said that if
he was running a school to teach programming, he would tie the student's
hands behind their backs for the first year.

   In the discussion following, Dijkstra pointed out that to be a
compiler developer, you had to speak English, Dutch, German, or Russian
as a young child, even if it was not your "milk tongue."

-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Comments

[Jerry van Dijk]

In article <38162C84.A762A730@mitre.org> eachus@mitre.org writes:

>   In the discussion following, Dijkstra pointed out that to be a
>compiler developer, you had to speak English, Dutch, German, or Russian
>as a young child, even if it was not your "milk tongue."

Wow, with three out of four I qualify...

:-) :-)

--
--  Jerry van Dijk  | email: jdijk@acm.org
--  Team-Ada        | www:   stad.dsl.nl/~jvandyk
--  Paris, France   | Leiden, Holland

Re: Comments

[Ted Dennison]

In article <941090045.3snx@jvdsys.stuyts.nl>,
  jerry@jvdsys.stuyts.nl wrote:
> In article <38162C84.A762A730@mitre.org> eachus@mitre.org writes:
>
> >   In the discussion following, Dijkstra pointed out that to be a
> >compiler developer, you had to speak English, Dutch, German, or
Russian
> >as a young child, even if it was not your "milk tongue."
>
> Wow, with three out of four I qualify...
>
> :-) :-)
>
> --
> --  Jerry van Dijk  | email: jdijk@acm.org

Well, we shouldn't be horribly shocked that he'd make statements
calculated to raise our estimation of developers whose last names start
with "Dijk". :-)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Comments (was: Self-referential types)

[Wes Groleau]

> One more reason for the guideline is that I want the guidlines to provide
> information, that may otherwise be lacking. So I prefer giving an exmaple of
> a standard - even if it is not desribed completly, just so that the students
> will have a better grasp of what I am talking about.

Just make sure it's a GOOD example.  Principle of technical writing:
When 
given text which tells what to do, accompanied by an example, many
people 
will follow the example even if it is the opposite of the text.

Re: Comments (was: Self-referential types)

[M.]

Wes Groleau wrote in message <380F2BA5.1EEE15F1@ftw.rsc.raytheon.com>...
>My own view is comments like the following are worse than
>unnecessary, they are pure clutter:
>
>  -- check whether the current transaction is completed
>  if Is_Completed (Current_Transaction) then
>
>     -- if so, close the source and destination DB files
>     DB_IO.Close (Source);
>     DB_IO.Close (Destination);

These are rather benign examples of what I call "duh" comments.  In other
cases, the names are not so descriptive, and the comments refer to these
names, making them especially useless. e.g.:

-- Add 2 to st
st := st + 2;

-- Flibber the Gibbet
Flibber(Gibbet);

Such comments can arise when the programmer writes the comments first, then
the code.  This is a good practice IF the programmer uses it to establish
the semantic requirements of the code, so that it will be easier to write
(and maintain) code that implements them.  "Duh" comments defeat this
purpose by blurring the distinction between semantic requirements and
implementation.

M.

Re: Comments (was: Self-referential types)

[Larry Kilgallen]

Reply-To: Kilgallen@eisner.decus.org.nospam
Organization: LJK Software
Lines: 10

In article <381477C9.E1388FF3@ftw.rsc.raytheon.com>, Wes Groleau <wwgrol@ftw.rsc.raytheon.com> writes:

> Just make sure it's a GOOD example.  Principle of technical writing:
> When given text which tells what to do, accompanied by an example, many
> people will follow the example even if it is the opposite of the text.

And that is the wisest course if the set of people who miss the normative
text includes the proofreaders :-).

Larry Kilgallen

Re: Self-referential types

[Richard D Riehle]

In article <7um9ji$dor$1@nnrp1.deja.com>,
	Robert Dewar <robert_dewar@my-deja.com> wrote:

>My own view is that good names are an *adjunct* to good
>comments, not a substitute for them.

Many software products developed in Ada are based on some
larger systems engineering specification.  The software must
reflect the constraints of that specification.  For example,
in one communications satellite software effort, it was common
to see comments that referred back to a paragraph of the
engineering specification.  

It would have been quite foolhardy to rely only on the names of
the entities.   Many of these names described some complicated
calculation that could only be understood by looking at the
underlying mathematics in the engineering specification.  For
trivial programs in which one is simply getting and putting
data to and from files, meaningful names might be enough. For
serious engineering applications, we need comments that correspond
to the original specification.  

As usual, we use the kind of tools appropriate for the problem
space and solution space.  I am beginning to think that people who
make up hard and fast rules for computer programming are people who
no longer actually write programs.  Perhaps they never did.

Richard Riehle
http://www.adaworks.com
 

Re: Self-referential types

[Robert A Duff]

Richard D Riehle <laoXhai@ix.netcom.com> writes:

> As usual, we use the kind of tools appropriate for the problem
> space and solution space.  I am beginning to think that people who
> make up hard and fast rules for computer programming are people who
> no longer actually write programs.  Perhaps they never did.

Hmm.  I had a hand in writing a book that's got thousands of absolutely
hard and fast rules for programming.  It's the Ada 95 Reference Manual.
And I still actually write programs.  ;-) ;-)

- Bob

Re: Self-referential types

[Richard D Riehle]

In article <wccu2ni3weo.fsf@world.std.com>,
	Robert A Duff <bobduff@world.std.com> wrote:

in response to the following outrageous hyperbole,

>Richard D Riehle <laoXhai@ix.netcom.com> writes:
>
>> As usual, we use the kind of tools appropriate for the problem
>> space and solution space.  I am beginning to think that people who
>> make up hard and fast rules for computer programming are people who
>> no longer actually write programs.  Perhaps they never did.
>
>Hmm.  I had a hand in writing a book that's got thousands of absolutely
>hard and fast rules for programming.  It's the Ada 95 Reference Manual.
>And I still actually write programs.  ;-) ;-)

Robert,

This is not at all the same thing.  The formulation of a syntax and
semantics for a programming language is not, in my mind, the equivalent
of telling a programmer which of those language features to use or 
not use.   I realize that many programmers resent Ada because they
feel it does impose too many rules.  I would not want to return to
Assembler, even though there are fewer language rules.  Even so, I
still encounter those elitists who would rather program in Assembler
because high-order languages are too restrictive.  To them, those of
us _sissies_ who no longer program in Assembler are not really programmers.

The kind of people mentioned in my post are those who thumb through
your program and criticize you for having an exit statement in a loop,
a use or use type clause in a perfectly safe place, a goto when it is
absolutely necessary, or some other construct they read about somewhere
in some magazine.  For example, when Dijkstra published his famous CACM
letter, "Go To Considered Harmful,"  thousands of programming managers
who did not read the article adopted the title as a standard, thereby
screwing up millions of lines of COBOL code.  COBOL, at that time, was
completely inappropriate for structured methods, and attempts to produce
structured code resulted in some of the most obfuscated constructs one
could imagine.  

Taking the Ada example.  The rules of Ada are certainly strict.  That 
is not a bad thing.  It would have been a bad thing if there were no
mechanisms for relaxing those strict rules when it was appropriate. One
reason Ada is better than Java for lots of things is the ability to
relax the rules.  So, Robert, even though you were involved in writing
a language that has lots of rules, you and others engaged in this
effort had the good sense to include capabilities for suspending those
rules when the correct solution called for it.

Consequently, I would not include you and the other designers of Ada in
my outrageous hyperbole.  You wrote a language reference manual that 
said, "These are the default rules. Use them and be safe."  Then you
added, "These are the workarounds when you need them."

Richard Riehle
http://www.adaworks.com 

Re: Self-referential types

[Michel DELARCHE]

A telling anecdote about name-based vs. comment-based "clarity": in one
of my previous lives I was part of a team developing Fortran software
with the 8-character limitations in names etc. ; one variable that would
read CAPENDEG (an easily understandable French abbreviation for
"Heading-in-degrees") would not need any additional comment, either on a
stand-alone basis or by means of reference to previous specification
documents. The nag is that neither the military airmen writing the high
level specifications with the "obvious" assumption that they were
talking about magnetic headings nor the software engineers who were
developing the software with the (not less "obvious") assumption that
they were dealing with geographic headings, realised the
misunderstanding until the first mapped  trajectories came out of the
system, looking slightly tilted to the trained eyes of the aviators.
Both groups realised then that both the initial specifications and the
subsequent software implementation had missed something. More expressive
languages like Ada might have defined a more strict (sub)type and even a
unit system (cf. the recent thread on the Mars Orbiter crash), but I'm
still not sure that the "obvious" distinction between magnetic and
geographic heading would have popped up earlier that it did.

Based on my (past) experience of software development for a variety of
application fields, I think that the main problem with software
documentation integrity and maintainability is precisely that kind of
diverging implicit assumptions made by dedicated yet necessarily rather
narrowly trained professionals that fail to realise that what is
"obvious" to them may not be so "obvious" to someone else.

Richard D Riehle a �crit :

> In article <7um9ji$dor$1@nnrp1.deja.com>,
>         Robert Dewar <robert_dewar@my-deja.com> wrote:
>
> >My own view is that good names are an *adjunct* to good
> >comments, not a substitute for them.
>
> Many software products developed in Ada are based on some
> larger systems engineering specification.  The software must
> reflect the constraints of that specification.  For example,
> in one communications satellite software effort, it was common
> to see comments that referred back to a paragraph of the
> engineering specification.
>
> It would have been quite foolhardy to rely only on the names of
> the entities.   Many of these names described some complicated
> calculation that could only be understood by looking at the
> underlying mathematics in the engineering specification.  For
> trivial programs in which one is simply getting and putting
> data to and from files, meaningful names might be enough. For
> serious engineering applications, we need comments that correspond
> to the original specification.
>
> As usual, we use the kind of tools appropriate for the problem
> space and solution space.  I am beginning to think that people who
> make up hard and fast rules for computer programming are people who
> no longer actually write programs.  Perhaps they never did.
>
> Richard Riehle
> http://www.adaworks.com
>

Re: Self-referential types

[Richard D Riehle]

In article <3802f2db_2@news1.prserv.net>,
	"Matthew Heaney" <matthew_heaney@acm.org> wrote:

>Yes, of course it's possible to initialize an access object that is an
>access to a type!

Matthew is correct about this.  I have several examples of this in 
Ada book I am writing.   Here is an pared down version of one of 
them fully coded with specification, body, and a little test program.

generic
   type Item is private;
package Access_Discriminant_2 is
  type Outer is limited private;
  type Outer_Reference is access all Outer;
  procedure Initialize  (Data : in out Outer; 
                         FV : Float := 0.0;
                         IV : Integer := 0);
  function  Flag_Is     (Data : Outer) return Natural;
  function  Sentinel_Is (Data : Outer) return Float;
 private
  type Inner;
    type Inner (Outer_Link : access Outer) is limited
     record
         Inner_Value : Float := 0.0;
     end record;
  procedure Initialize (Data : in out Inner; V : Integer := 0);
  type Outer is limited
     record
        Outer_Data : Inner(Outer_Link => Outer'Access);
        Flag : Natural := 0;
     end record;
end Access_Discriminant_2;

with the following package body,

package body Access_Discriminant_2 is

  procedure Initialize (Data : in out Outer; 
                        FV : Float := 0.0;
                        IV : Integer := 0) is
  begin
     Data.Outer_Data.Inner_Value := 0.0;
     Initialize(Data.Outer_Data, V => IV);
  end Initialize;

  procedure Initialize (Data : in out Inner; V : Integer := 0) is
  begin
     Data.Outer_Link.Flag := V;
  end;

  function Flag_Is (Data : Outer) return Natural is
  begin
    return Data.Flag;
  end Flag_Is;

  function Sentinel_Is (Data : Outer) return Float
 is
  begin
    return Data.Outer_Data.Inner_Value;
  end Sentinel_Is;


end Access_Discriminant_2;

and this little program that shows how to use it,

with Access_Discriminant_2;
procedure Test_Access_Discriminant_2 is
  package Access_Demonstration is new Access_discriminant_2
                 (Item => Float);
  type Reference is access all Access_Demonstration.Outer;
  Outer_Data : aliased Access_Demonstration.Outer;
  Outer_Reference : Reference := Outer_Data'Access;
begin
  Access_Demonstration.Initialize(Outer_Reference.all, 
                                  FV =>  14.2, 
                                  IV =>  42);
end Test_Access_Discriminant_2;

This example is one of a series that demonstrates variations on the
theme, including ideas regarding improved encapsulation, and 
circumstances under which it can be appropriate in design.  

As to the notion of multiple-inheritance, most attempts to 
implement MI in Ada are no where close to true MI, including
this one.  However, this one is a pretty good composition 
mechanism for achieving other important design requirements.

Richard Riehle

Re: Self-referential types

[news.oxy.com]

Matthew Heaney wrote in message <3802f2db_2@news1.prserv.net>...
>In article <s04ql7cqh1s45@corp.supernews.com> , "Vladimir Olensky"
><vladimir_olensky@yahoo.com> wrote:
>
>> How it is  possible to initialize access variable
>> by the initial value that is access attribute to type ?
>
>Yes, of course it's possible to initialize an access object that is an
>access to a type!
>
>For a limited type T, then inside the declaration of the type, the
>expression T'Access refers to the "current instance" of the type.


Very good clarification indeed.

>This is something a lot of programmers haven't learned yet.

Let alone people which primary occupation is not  programming
( as for me my primary occupation is telecommunications).

>This is the basis for programming with access discriminants, which is
>how you do MI in Ada95.
>
>For example:
>
>  type Handle_Type (Stack : access Stack_Type) is
>    limited null record;
>
>  type Stack_Type is
>    limited record
>      Handle : Handle_Type (Stack_Type'Access);  --!!!
>      <other stuff>
>    end record;
>
>
>Here's another example:
>
>  type T is tagged limited private;
>...
>private
>
>  function Do_Get_Default (O : T) return T2;
>
>  function Get_Default (O : T'Class) return T2;
>
>  type T is
>    tagged limited record
>       O : T2 := Get_Default (T'Access);  --!!!
>    end record;
>
>
>Where
>
>  function Get_Default (O : T'Class) return T2 is
>  begin
>    return Do_Get_Default (O);
>  end;
>
>
>This is the idiom you use if you want to let a descendent type change
>the default of component declared by the ancestor.
>


All this is very interesting indeed.
As for me I  never used such thing and was not sure  that it makes any sense
to apply  access attrubute to anything except oject instance.
In other languages there exists "Self" parameter and when it is used in
class declarations it refers to current class instance.

You might  put a short article regarding this issue to Adapower.
I am sure it will be very useful.

>> Access attributes can not be applied to type.
>Wrong.

It is wrong  only for limited types.
For types that are not limited it is true.

>> It may only be  applied to some object but not to its description.
>Wrong.

The same as above.
For non limited types compiler gives you an error message:
------------------------------------------------------
Wrong_Initialization : List_Type := Cell_Type'Access;

test.adb:14:37: "Access" attribute cannot be applied to type
gnatmake: "test.adb" compilation error
-----------------------------------------------------------------
This can make one think that it is always true .
If GNAT would give you additional info  that such
construct could be applied only to limited types this
could make person  to look deeper to that (at least out
of curiosity ).


Again thanks for good  clarification. It is very useful.

Regards,
Vladimir Olensky

Re: Self-referential types

[Ted Dennison]

In article <s06ji18vh1s47@corp.supernews.com>,
  "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote:
>
> Matthew Heaney wrote in message <3802f2db_2@news1.prserv.net>...
> >This is the basis for programming with access discriminants, which is
> >how you do MI in Ada95.
> You might  put a short article regarding this issue to Adapower.
> I am sure it will be very useful.

I'd like to heartily second that one. I tried every resource I could
find to figure this out before I resorted to c.l.a. The example in
Cohen's book is wrong, and he doesn't address its use in MI at all. The
rationale just talks about it but doesn't put up any examples. I
couldn't even find anything in the LRM that said this was legal after
over an hour of searching. It'd be a shame if the only real
documentation of this technique was word of mouth.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Self-referential types

[Stanley R. Allen]

Ted Dennison wrote:
> 
> The example in
> Cohen's book is wrong, and he doesn't address its use in MI at all.

For the record, Cohen is aware that the example on page 491 is
in error and has noted so in his errata:

    http://www.research.ibm.com/people/n/ncohen/a3sl_errata.html

-- 
Stanley Allen
mailto:s_allen@hso.link.com

Re: Self-referential types

[Ted Dennison]

In article <3803987F.2049ABFE@hso.link.com>,
  "Stanley R. Allen" <s_allen@hso.link.com> wrote:
> Ted Dennison wrote:
> >
> > The example in
> > Cohen's book is wrong, and he doesn't address its use in MI at all.
>
> For the record, Cohen is aware that the example on page 491 is
> in error and has noted so in his errata:
>
>     http://www.research.ibm.com/people/n/ncohen/a3sl_errata.html

So he has. He gave a good explanation of why too. (sigh).

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Self-referential types

[Vladimir Olensky]

Ted Dennison wrote in message <7tvq5g$28u$1@nnrp1.deja.com>...
>In article <s06ji18vh1s47@corp.supernews.com>,
>  "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote:
>>
>> Matthew Heaney wrote in message <3802f2db_2@news1.prserv.net>...
>> >This is the basis for programming with access discriminants, which is
>> >how you do MI in Ada95.
>> You might  put a short article regarding this issue to Adapower.
>> I am sure it will be very useful.
>
>I'd like to heartily second that one. I tried every resource I could
>find to figure this out before I resorted to c.l.a. The example in
>Cohen's book is wrong, and he doesn't address its use in MI at all. The
>rationale just talks about it but doesn't put up any examples. I
>couldn't even find anything in the LRM that said this was legal after
>over an hour of searching. It'd be a shame if the only real
>documentation of this technique was word of mouth.


I think that the first part of it could explain why in Ada there is no SELF
or THIS parameter ( which object instance can use to obtain reference
to itself in other languages)  and their equivalent constructs in Ada
(and also what is similar and what is different  in Ada and other
 languages regarding that issue).
When this clear than other part may discuss more advanced
topics such as MI implementation.
Doing it this way  may help people  experienced in other languages
or people beginning to learn Ada to grasp the idea without any
additional strain.
Comparison always help in introducing things that are not very familiar
to others.
Also if that is easy to understand then there would be less  causes for
some people to tell that Ada is too complicated/complex language
that only military could like.

Regards,
Vladimir Olensky.

Multiple Inheritance in Ada 95 [was Re: Self-referential types]

[Tucker Taft]

Ted Dennison wrote:
> 
> In article <s06ji18vh1s47@corp.supernews.com>,
>   "news.oxy.com" <Vladimir_Olensky@oxy.com> wrote:
> >
> > Matthew Heaney wrote in message <3802f2db_2@news1.prserv.net>...
> > >This is the basis for programming with access discriminants, which is
> > >how you do MI in Ada95.
> > You might  put a short article regarding this issue to Adapower.
> > I am sure it will be very useful.
> 
> I'd like to heartily second that one. I tried every resource I could
> find to figure this out before I resorted to c.l.a. The example in
> Cohen's book is wrong, and he doesn't address its use in MI at all. The
> rationale just talks about it but doesn't put up any examples. I
> couldn't even find anything in the LRM that said this was legal after
> over an hour of searching. It'd be a shame if the only real
> documentation of this technique was word of mouth.

I have included a copy of a Language Study Note I wrote during the
Ada 9X design process.  It explains the was to support multiple-inheritance
hierarchies using various Ada 95 features.  Feel free to post this
to AdaPower, etc.

> 
> --
> T.E.D.
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA
--------------------------------------------------------------------
!topic LSN on Multiple Inheritance in Ada 9X
!key LSN-1033 on Multiple Inheritance in Ada 9X
!reference MS-3.4.1;4.6
!reference MS-3.6.1;4.6
!reference MS-12.3.6;4.6
!from Tucker Taft $Date: 92/09/02 17:44:17 $ $Revision: 1.1 $
!discussion

This Language Study Note discusses the creation of
multiple inheritance type (semi-)lattices using the proposed
Ada 9X object-oriented programming features.  
It is in part directed at programmers familiar with
other object-oriented programming languages that 
build in syntax for a particular multiple-inheritance mechanism,
rather than simply providing features needed to support it.

In this discussion, we will in general use Ada 9X terminology, where
every object has a single "type," and multiple similar types
(typically in some kind of hierarchy or oligarchy)
form a "class" of types.  If we want to use the term "class" as
it is used in C++ or Eiffel, we will always say "C++ class" or
"Eiffel class."

In some languages, such as Eiffel, multiple inheritance
serves many purposes.  For example, there is no equivalent in Eiffel
to the "include" statement of C/C++ or the "with/use" clauses
of Ada.  Therefore, to gain direct visibility to the
declarations of some other module, one must inherit from
that module (Eiffel class).

In C/C++, one can simply "include" file containing
a set of type and object definitions.

In Ada, one first identifies the external modules of interest
via "with" clauses, and then chooses selectively whether
to make only the name of the module (package) visible, or
its contents (via a "use" clause).

In both Eiffel and C++, one can choose to inherit from
some other type, without making that visible to clients
of the new type.  Effectively, the linguistic multiple 
inheritance mechanism is being used to express not
an "is a refinement of" relationship, but rather 
an "is implemented using" relationship.

Finally, there are the situations where
a single type visibly inherits from two or
more other types.  In these cases, this is rarely
a symmetric situation.  Rather, one of the ancestor
types is the "primary" ancestor, while the others
are typically "mix-ins" designed to augment behavior
of the primary ancestor.

Ada 9X supports multiple-inheritance module inclusion
(via multiple "with"/"use" clauses), multiple-inheritance
"is-implemented-using" via private extensions and record composition,
and multiple-inheritance mix-ins via the use of
generics, formal packages, and access discriminants.

The Ada 9X mechanisms are designed to eliminate "distributed" overhead,
so that there is no added expense for the general user
of the language because of the presence of the mechanisms supporting
multiple inheritance.

There are basically three distinct situations associated
with multi-inheritance mixins:

  1) The case where the mix-in provides components
     and operations, and any overriding of these operations
     needs only to look at the components of the mix-in itself.

  2) The case where the mix-in provides components and operations,
     and some of the overriding of these operations needs access
     to the whole object, rather than just the components of the mix-in.

  3) Like (2), and in addition, any object with the mix-in must
     be able to be linked onto a list (or into some similar 
     heterogeneous data structure) of other objects with the same mix-in.

Case (1) is handled completely in Ada 9X by a record or private extension,
with the type being mixed in (in a possibly extended form) as a 
component of the record extension.

Case (2) is handled with a generic, that takes any type in
a given class (formal derived type), adds components (via extension) 
and operations, and then reexports the extended type.  The new operations
have access to the whole object, not just to the components
being added.

Case (3) is handled with an access discriminant, that provides
access to the enclosing object for the operations of the mix-in,
while still allowing links through the mix-in.  Generics can
also be used to simplify the definition.

Here are a few examples:

Case (1) --
   One has an abstract type "Set_of_Strings" and one wants to implement
   it by reusing an existing (concrete) type "Hash_Table":

   Here is the abstract type:

      type Set_Of_Strings is tagged limited private;
      type Element_Index is new Natural;  -- Index within set.

      No_Element : constant Element_Index := 0;

      Invalid_Index : exception;

      procedure Enter(
        -- Enter an element into the set, return the index
         Set : in out Set_Of_Strings; 
         S : String; 
         Index : out Element_Index) is <>;

      procedure Remove(
        -- Remove an element from the set; ignore if not there
         Set : in out Set_Of_Strings; 
         S : String) is <>; 

      procedure Combine(
        -- Combine Additional_Set into Union_Set
         Union_Set : in out Set_Of_Strings;
         Additional_Set : Set_Of_Strings) is <>;

      procedure Intersect(
        -- Remove all elements of Removal_Set from Intersection_Set
         Intersection_Set : in out Set_Of_Strings;
         Removal_Set : Set_Of_Strings) is <>;

      function Size(Set : Set_Of_Strings) return Element_Index is <>;
        -- Return a count of the number of elements in the set

      function Index(
        -- Return the index of a given element; return No_Element if not there.
         Set : Set_Of_Strings; 
         S : String) return Element_Index is <>;

      function Element(Index : Element_Index) return String is <>;
        -- Return element at given index position
        -- raise Invalid_Index if no element there.
    private
      type Set_Of_Strings is tagged limited ...

   Here is an implementation of this abstract type that
   inherits its interface from Set_Of_Strings, and its implementation
   from Hash_Table:

      type Hashed_Set(Table_Size : Positive) is 
        new Set_Of_Strings with private;

      -- Now we give the specs of the operations being implemented
      procedure Enter(
        -- Enter an element into the set, return the index
         Set : in out Hashed_Set;
         S : String; 
         Index : out Element_Index);

      procedure Remove(
        -- Remove an element from the set; ignore if not there
         Set : in out Hashed_Set;
         S : String);
      . . . etc.

    private
      type Hashed_Set(Table_Size : Positive) is 
        new Set_Of_Strings with record
          Table : Hash_Table(1..Table_Size);
        end record;

   In the body of this package, we would provide the bodies
   for each of the operations, in terms of the operations
   available from Hash_Table.  Chances are they don't match exactly,
   so a little bit of "glue" code will be necessary in any case.
      
  
Case (2) --
   One has a type Basic_Window that responds to various
   events and calls.  One wants to embellish the Basic_Window
   in various ways with various mix-ins.

     type Basic_Window is tagged limited private;
     procedure Display(W : Basic_Window);
     procedure Mouse_Click(W : in out Basic_Window; Where : Mouse_Coords);
     . . . 

   Now one can define any number of mix-in generics, like the following:
  
     generic
       type Some_Window is new Window with private;
         -- take in any descendant of Window
     package Label_Mixin is
       type Window_With_Label is new Some_Window with private;
         -- Jazz it up somehow.

       -- Overridden operations:
       procedure Display(W : Window_With_Label);

       -- New operations:
       procedure Set_Label(W : in out Window_With_Label; S : String);
         -- Set the label
       function Label(W : Window_With_Label) return String;
         -- Fetch the label
     private
       type Window_With_Label is 
         new Some_Window with record
           Label : String_Quark := Null_Quark;  
             -- An XWindows-Like unique ID for a string
         end record;

   In the generic body, we implement the Overridden and New operations
   as appropriate, using any inherited operations, if necessary.  For
   example, this might be an implementation of the overridden Display:

       procedure Display(W : Window_With_Label) is
       begin
           Display(Some_Window(W));
             -- First display the window normally,
             -- by passing the buck to the parent type.

           if W.Label /= Null_Quark then
             -- Now display the label if it is not null
               Display_On_Screen(XCoord(W), YCoord(W)-5, Value(W.Label));
                 -- Use two inherited functions on Basic_Window
                 -- to get the coordinates where to display the label.
           end if;
       end Display;

   Presuming we have several such generic packages defined,
   We can now create the desired window by mixing in repeatedly.
   First we declare the tailored window as a private extension
   of Basic_Window, and then we define it via a sequence of
   instantiations:

       type My_Window is Basic_Window with private;
       . . .
     private
       package Add_Label is new Label_Mixin(Basic_Window);
       package Add_Border is 
         new Border_Mixin(Add_Label.Window_With_Label);
       package Add_Menu_Bar is 
         new Menu_Bar_Mixin(Add_Border.Window_With_Border);

       type My_Window is 
         new Add_Menu_Bar.Window_With_Menu_Bar with null;
           -- Final window is a null extension of Window_With_Menu_Bar.
           -- We could instead make a record extension and
           -- add components for My_Window over and above those
           -- needed by the mix-ins.

Case(3) --
   In this case, let us presume we have two independent
   hierarchies, one for Windows, which represent areas on the
   screen, and one for Monitors, which wait for an object to change,
   and then do something in reaction to it.
   An object that supports Monitors keeps a linked list of
   Monitors, and calls their Update operation whenever the object
   is changed.  For example:

     type Monitor;
     type Monitor_Ptr is access Monitor'CLASS;

     type Monitored_Object is tagged limited 
       -- Monitored objects are derived from this root type
       record
         First : Monitor_Ptr;  - List of monitors
         -- More components to be added by extension
       end record;

     type Monitored_Object_Ptr is access Monitored_Object'CLASS;
  
     type Monitor is tagged limited 
       record
         Next : Monitor_Ptr;
         Obj : Monitored_Object_Ptr;
         -- More components to be added by extension
       end record;
     procedure Update(M : in out Monitor) is <>;
       -- Dispatching operation, called when monitored object
       -- is changed.

   Now suppose we want to create a Window that can
   act as a Monitor as well as a Window:

   First we define a mix-in that is a monitor, and override its Update op:

     type Monitor_Mixin(Win : access Basic_Window'CLASS) is 
       new Monitor with null;
     procedure Update(M : in out Monitor_Mixin);

   The body for this Update could be:

     procedure Update(M : in out Monitor_Mixin) is
       -- On an Update, simply re-Display the window
     begin
         Display(M.Win);  -- This is a dispatching call
     end Update;

   Now we can "mix" this Monitor_Mixin into any window type, as follows:

     type Window_That_Monitors is 
       new My_Window with record
         Mon : Monitor_Mixin(Window_That_Monitors'ACCESS);
       end record;

   We could define a tailored Monitor mix-in that did something 
   besides just call the Display operation of the associated
   Window.  But in many cases, this simple one will do the job.

-----------------------------
As these examples illustrate, Ada 9X provides support
for the construction of essentially arbitrary multiple
inheritance type lattices, without having to commit itself
to a single linguistic mechanism for multiple inheritance, and
without burdening simple single-inheritance problems with the complexity
and implementation burden of linguistic multiple inheritance.

Re: Self-referential types

[Matthew Heaney]

In article <s06ji18vh1s47@corp.supernews.com> , "news.oxy.com" 
<Vladimir_Olensky@oxy.com> wrote:

> As for me I  never used such thing and was not sure  that it makes any sense
> to apply  access attrubute to anything except oject instance.

It *is* an object instance.  The expression T'Access, inside the
declaration of a type, refers to the "current instance," which is of
course an object.

> In other languages there exists "Self" parameter and when it is used in
> class declarations it refers to current class instance.

Same thing, different syntax.

> You might  put a short article regarding this issue to Adapower.
> I am sure it will be very useful.

My plan is to put an article in the Design Patterns archive; David will
cross-post at AdaPower.

Matt

--
Creationists attempt to draw a line between evolutionary biology and the
rest of science by remarking that large-scale evolution cannot be
observed.  This tactic fails.  Large-scale evolution is no more
inaccessible to observation than nuclear reactions or the molecular
composition of water.

Abusing Science: The Case Against Creationism
Philip Kitcher