Refactoring and Ada

Refactoring and Ada

[Paul Anderson]

Hi!

As part of a government research contract, we are developing a
Refactoring editor for Ada.  I am interested in soliciting opinions
from the group about Refactoring and Ada.

For those that don't know, Refactoring is defined as "a technique to
restructure code in a disciplined way."  It has been associated with
Extreme Programming, but stands on its own as a highly useful
technique.  General information about Refactoring can be found at
http://www.refactoring.com.

I am interested in finding out if there are any Ada projects out there
that actively use refactoring.  If so, what refactorings do you use?
Are they just like the Java ones, or are there features of Ada that
mandate special-purpose refactorings?  What features would you like to
see in a refactoring editor for Ada?

I am especially interested in any use of refactoring in support of
legacy code, either to clean up code that has been automatically
translated to Ada, or to prepare Ada code so that it can be translated
more easily into something else.

Best regards, and thanks in advance for your input.

Paul.

______
Paul Anderson.  GrammaTech, Inc.    Tel: +1 607 273-7340 x18
mailto:paul@grammatech.com  http://www.grammatech.com

Re: Refactoring and Ada

[Nick Roberts]

Paul,

Ada has a co-standard called ASIS, which provides a standardised way for
(Ada) programs to access Ada source code broken down (by a compiler
front-end) into its structural form.

Thus, Ada refactoring tools will typically use ASIS as the mechanism to do
their work. (If not, they will either have to use a standalone lexical
parser, e.g. OpenToken, or a compiler's front-end directly).

So, if you were to do a Internet search on keywords such as "ASIS" and
"OpenToken", you are liekly to get some good leads. The
http://www.adapower.com web site could also be a good source of information.

I suspect most of the classic refactorings, like global rename, will apply
to Ada just as to Java and Smalltalk.

I suspect that, in the case of Ada, refactoring in support of legacy code is
unlikely in practice. This is largely because Ada 95 contains virtually no
incompatibilties with Ada 83, and added no features so valuable that it
would make it desirable to refactor Ada 83 code to use those features.

[ *** WARNING: mind-numbing esoterica follows; no liability for brain damage
can be accepted. *** ]

If you would like me to throw in my own ideas, one fairly elaborate one
occurs to me, to do with providing support for Aspect-Oriented Programming
in Ada. It would work something like as follows.

First, the user specifies a list A of aspects, each having a name N (which
is a valid Ada name). One of these aspects is designated the default Nd.
Each name would either be simple (an identifier) or compound (having a
prefix). The operation is applied to a library package P, and does the
following:

(1) for each (N) of all the aspects in A, write a new private package
specification named P.N, containing an inlined declaration for each
subprogram S declared in the specification of P, each such declaration being
a copy of the declaration of S but excluding out-mode parameters in the case
of the default aspect, and a procedure in all other cases with the same
parameters but excluding the out-mode (and return) parameters;

(2) rewrite the existing body of P with the name P.Nd (but otherwise
unchanged);

(3) for each (N) of the other aspects in A, write a new body named P.N,
which contains a null completion for each subprogram in the specification of
P;

(4) write a new body of P, with a completion for each subprogram in the
specification of P, each such completion containing (only) a call to each
member (N) of A (in the order given) in the form "P.N(parameters)" where the
parameters are a repetition of the formal parameters of the subprogram, and
the result of a function is held in a temporary and returned at the end, if
necessary.

In addition, for each member of the set formed by the closure of the
ancestors of the (compound) names of A, write out an empty private package
specification.

An example might illuminate the idea. Suppose we have a package:

   with Customers;
   package Ice_Cream is
      type Cone is private;
      function Make return Cone;
      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human);
   private
      ... private stuff
   end Ice_Cream;

   package body Ice_Cream is

      function Make return Cone is
      begin
         ... make a cone
      end;

      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human) is
      begin
         ... eat a cone
      end;

   end Ice_Cream;

Now, suppose we wished to divide this into the aspects: Debug.Before; Main;
Debug.After. The refactoring would generate the following compilation units:

   private package Ice_Cream.Debug is end;

   private package Ice_Cream.Debug.Before is
      procedure Make;
      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human);
      pragma Inline(Make,Eat);
   end Ice_Cream.Debug.Before;

   private package Ice_Cream.Main is
      function Make return Cone;
      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human);
      pragma Inline(Make,Eat);
   end Ice_Cream.Main;

   private package body Ice_Cream.Debug.After is
      procedure Make;
      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human);
      pragma Inline(Make,Eat);
   end Ice_Cream.Debug.After;

   package body Ice_Cream.Debug.Before is

      procedure Make is
      begin
         null;
      end;

      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human) is
      begin
         null;
      end;

   end Ice_Cream.Debug.Before;

   package body Ice_Cream.Main is

      function Make return Cone is
      begin
         ... make a cone
      end;

      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human) is
      begin
         ... eat a cone
      end;

   end Ice_Cream.Main;

   package body Ice_Cream.Debug.After is

      procedure Make is
      begin
         null;
      end;

      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human) is
      begin
         null;
      end;

   end Ice_Cream.Debug.After;

The following replacement compilation unit would be generated:

   package body Ice_Cream is

      function Make return Cone is
         Temp: Cone;
      begin
         Ice_Cream.Debug.Before.Make;
         Temp := Ice_Cream.Main.Make;
         Ice_Cream.Debug.After.Make;
         return Temp;
      end;

      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human) is
      begin
         Ice_Cream.Debug.Before.Eat(Item,Person);
         Ice_Cream.Main.Eat(Item,Person);
         Ice_Cream.Debug.After.Eat(Item,Person);
      end;

   end Ice_Cream.Main;

For any other compilation unit written, if the unit already exists, it is
not replaced.

Obviously, the idea is to automatically generate a skeleton that provides
for the separation of the implementation of a library package into a set of
different aspects.

It also would be good to have operations that: added aspects to an
implementation already divided; coalesced several aspects back into one;
coalesced all the aspects back into one body.

I'm sure that any number of similarly specialised and elaborate refactorings
could be useful to some people. I'm also sure that useful manipulations
would not be limited to those which preserve (external) semantics.

--
Nick Roberts



"Paul Anderson" <paul@grammatech.com> wrote in message
news:3C5AB0B7.9D75D49A@grammatech.com...
>
> Hi!
>
> As part of a government research contract, we are developing a
> Refactoring editor for Ada.  I am interested in soliciting opinions
> from the group about Refactoring and Ada.
>
> For those that don't know, Refactoring is defined as "a technique to
> restructure code in a disciplined way."  It has been associated with
> Extreme Programming, but stands on its own as a highly useful
> technique.  General information about Refactoring can be found at
> http://www.refactoring.com.
>
> I am interested in finding out if there are any Ada projects out there
> that actively use refactoring.  If so, what refactorings do you use?
> Are they just like the Java ones, or are there features of Ada that
> mandate special-purpose refactorings?  What features would you like to
> see in a refactoring editor for Ada?
>
> I am especially interested in any use of refactoring in support of
> legacy code, either to clean up code that has been automatically
> translated to Ada, or to prepare Ada code so that it can be translated
> more easily into something else.
>
> Best regards, and thanks in advance for your input.
>
> Paul.
>
> ______
> Paul Anderson.  GrammaTech, Inc.    Tel: +1 607 273-7340 x18
> mailto:paul@grammatech.com  http://www.grammatech.com

Re: Refactoring and Ada

[Pat Rogers]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:a3hi78$18ga0c$1@ID-25716.news.dfncis.de...

> <snip>

> I suspect that, in the case of Ada, refactoring in support of legacy code is
> unlikely in practice. This is largely because Ada 95 contains virtually no
> incompatibilties with Ada 83, and added no features so valuable that it
> would make it desirable to refactor Ada 83 code to use those features.

That last phrase is an amazing assertion!  Surely you don't mean it the way it
looks!

As a counter example, I know of a number of projects that have replaced some of
their tasks with protected objects.  On a much smaller scale of feature, I know
of projects that have removed a great many "renames clauses" with "use type"
clauses.

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: Refactoring and Ada

[Nick Roberts]

"Pat Rogers" <progers@classwide.com> wrote in message
news:V4Y68.326$xE7.126341269@newssvr12.news.prodigy.com...

> > I suspect that, in the case of Ada, refactoring in support of legacy
code is
> > unlikely in practice. This is largely because Ada 95 contains virtually
no
> > incompatibilties with Ada 83, and added no features so valuable that it
> > would make it desirable to refactor Ada 83 code to use those features.
>
> That last phrase is an amazing assertion!  Surely you don't mean it the
way it
> looks!

Yes I did!

> As a counter example, I know of a number of projects that have replaced
some of
> their tasks with protected objects.

I think it's arguable whether that actually counts as refactoring. Do the
semantics really remain the same (as opposed to 'effectively the same')? To
clarify, could the change have been made, safely, by a purely mechanised
algorithm? (I don't think so. And if it could, the algorithm would have to
be fiendishly complex, no?)

> On a much smaller scale of feature, I know
> of projects that have removed a great many "renames clauses" with "use
type"
> clauses.

As ever, I stand to be corrected.

I have never personally heard of any Ada 83 program being re-engineered into
Ada 95 whilst -- and this is the crucial bit -- retaining the same semantics
(not just 'effectively the same', as above). That is to say, often Ada 83
code is converted into Ada 95, and it it may end up doing the same job as
before (and even having the same interface), but always the semantics are
actually changed somehow, however subtly. Most of the new features of Ada 95
have semantics that are different to anything Ada 83 had, so changing from
Ada 83 to Ada 95 tends to necessitate a change of semantics. The changes in
Ada 95 which replaced one (Ada 83) construct with another of (potentially)
equal meaning were few and fairly esoteric (e.g. the Import and Export
pragmas versus the Interface pragma); furthermore, the old construct was
nearly always retained anyway, so there is very rarely a real need to change
the old code. Some Ada 83 programs with identifiers that became reserved
words (e.g. "Requeue") had to be changed. (Enough wittering. You get the
gist ;-)

--
Nick Roberts

Re: Refactoring and Ada

[Robert Dewar]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<a3hvml$183djn$1@ID-25716.news.dfncis.de>...
> I think it's arguable whether that actually counts as 
> refactoring.

> Do the semantics really remain the same

Yes

> could the change have been made,

Yes

> safely, by a purely mechanised algorithm?

Yes,

> (I don't think so. And if it could, the algorithm would 
   have to be fiendishly complex, no?)

No

> I have never personally heard of any Ada 83 program being 
> re-engineered into Ada 95 whilst -- and this is the 
> crucial bit -- retaining the same semantics (not just 
> 'effectively the same', as above).

I find this surprising, since we see it all the time. Nick
I can't guess what Ada environment you inhabit if you never
saw this. It is indeed common for users to take large Ada 83 codes and
reengineer them into Ada 95, using Ada 95
constructs to clean up the code (Pat's use type example),
or to improve efficiency (e.g. replacing "passive" tasks
by protected types). Another example is adding pragnma
Preelaborate where possible to reduce elaboration checking
(that's something that could certainly be automated).


Robert Dewar

Re: Refactoring and Ada

[Nick Roberts]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0202030553.6431291a@posting.google.com...

> "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:<a3hvml$183djn$1@ID-25716.news.dfncis.de>...
> > I think it's arguable whether that actually counts as
> > refactoring.
>
> > Do the semantics really remain the same
>
> Yes
>
> > could the change have been made,
>
> Yes
>
> > safely, by a purely mechanised algorithm?
>
> Yes,
>
> > (I don't think so. And if it could, the algorithm would
>    have to be fiendishly complex, no?)
>
> No

I'm intrigued. Could you show a real-life example demonstrating this please?

> > I have never personally heard of any Ada 83 program being
> > re-engineered into Ada 95 whilst -- and this is the
> > crucial bit -- retaining the same semantics (not just
> > 'effectively the same', as above).
>
> I find this surprising, since we see it all the time. Nick
> I can't guess what Ada environment you inhabit if you never
> saw this. It is indeed common for users to take large Ada 83 codes and
> reengineer them into Ada 95, using Ada 95
> constructs to clean up the code (Pat's use type example),
> or to improve efficiency (e.g. replacing "passive" tasks
> by protected types).

Well, I have never come across an example of this myself. Perhaps that's
simply a consequence of blind chance. Perhaps your experiences, Robert, are
not actually typical of the Ada community in general.

> Another example is adding pragnma
> Preelaborate where possible to reduce elaboration checking
> (that's something that could certainly be automated).

If you're talking about the automated detection of packages which are
eligible to be pre-elaborated, is it not the case that, in pratice, many
packages which are eligible cannot be detected automatically (because it
depends on dynamic behaviour beyond the grasp of static analysis)?

Re: Refactoring and Ada

[Robert Dewar]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<a3k691$18rkho$1@ID-25716.news.dfncis.de>...
> If you're talking about the automated detection of 
> packages which are eligible to be pre-elaborated, is it 
> not the case that, in pratice, many packages which are 
> eligible cannot be detected automatically (because it
> depends on dynamic behaviour beyond the grasp of static 
> analysis)?

Complete disconnect here. The conditions for a package to
be preelaborated are of course a set of static semantic
conditions and are clearly stated in the RM (just look up
the pragma in the RM). I can't guess what your confusion
is here ...

Re: Refactoring and Ada

[Nick Roberts]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0202031817.1e8a3d90@posting.google.com...

> "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:<a3k691$18rkho$1@ID-25716.news.dfncis.de>...

> > If you're talking about the automated detection of
> > packages which are eligible to be pre-elaborated, is it
> > not the case that, in pratice, many packages which are
> > eligible cannot be detected automatically (because it
> > depends on dynamic behaviour beyond the grasp of static
> > analysis)?
>
> Complete disconnect here. The conditions for a package to
> be preelaborated are of course a set of static semantic
> conditions and are clearly stated in the RM (just look up
> the pragma in the RM). I can't guess what your confusion
> is here ...

Sorry, my mistake. Maybe I was thinking about a discussion a while ago on
this newsgroup about Elaborate_All.

It does actually raise a question in my mind: why was pragma Preelaborate
introduced in the first place? Would it not have been reasonable to assume
compilers could automatically determine whether a library unit is
preelaborable? (I guess the answer is "No": I just want to know why.)

--
Nick Roberts

Re: Refactoring and Ada

[Pat Rogers]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:a3mtl6$18ase0$1@ID-25716.news.dfncis.de...

<snip>

> It does actually raise a question in my mind: why was pragma Preelaborate
> introduced in the first place?

It came out of the Ada Run-Time Environment Working Group (ARTEWG) Catalog of
Interface Features and Options (CIFO) for Ada 83.  A member had an embedded
air-to-air missile application that took too long to elaborate -- it was already
off the rail by then, but not quite ready to fly -- hence the pragma.  A number
of Ada 95's real-time facilities can be traced to the CIFO.  Some of it was
overkill, but much was very good.

That doesn't answer your question of why the compiler cannot do it
automatically, but I think the history is interesting.

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: Refactoring and Ada

[Marin David Condic]

It would seem that the answer to that problem would be: "Turn the missile's
computer on & initialize everything before you light the fuse...." but
that's just me. :-)

I've had a number of issues in the past with elaboration for embedded
platforms - in particular with respect to having large static tables
initialized & wanting to put the structures into ROM. The compiler I was
using at the time wanted to keep the static data for itself then try to
write the data to ROM at elaboration. Needless to say, this sucked. I'm
wondering if preelaborate would have fixed that?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Pat Rogers" <progers@classwide.com> wrote in message
news:yZD78.8997$Bf6.3206761629@newssvr11.news.prodigy.com...
>
> It came out of the Ada Run-Time Environment Working Group (ARTEWG) Catalog
of
> Interface Features and Options (CIFO) for Ada 83.  A member had an
embedded
> air-to-air missile application that took too long to elaborate -- it was
already
> off the rail by then, but not quite ready to fly -- hence the pragma.  A
number
> of Ada 95's real-time facilities can be traced to the CIFO.  Some of it
was
> overkill, but much was very good.
>

Re: Refactoring and Ada

[Nick Roberts]

"Pat Rogers" <progers@classwide.com> wrote in message
news:yZD78.8997$Bf6.3206761629@newssvr11.news.prodigy.com...
> "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
> news:a3mtl6$18ase0$1@ID-25716.news.dfncis.de...
>
> <snip>
>
> > It does actually raise a question in my mind: why was pragma
Preelaborate
> > introduced in the first place?
>
> It came out of the Ada Run-Time Environment Working Group (ARTEWG) Catalog
of
> Interface Features and Options (CIFO) for Ada 83.  A member had an
embedded
> air-to-air missile application that took too long to elaborate -- it was
already
> off the rail by then, but not quite ready to fly -- hence the pragma.  A
number
> of Ada 95's real-time facilities can be traced to the CIFO.  Some of it
was
> overkill, but much was very good.
>
> That doesn't answer your question of why the compiler cannot do it
> automatically, but I think the history is interesting.

Yes, extremely interesting!

In fact, I think I can answer my own question, very simply, having thought
about it (for about five minutes). You do indeed want to have explicit
directives saying "this library unit should be [preelaborated|pure]", so
that the compiler will give you a warning if it cannot be (violates one of
the restrictions). Simple. I really *should* think a bit more before opening
my virtual big fat mouth. Sorry.

PS: Many missiles nowadays are alive and active long before firing, showing
their radar or images to the pilot, giving lock-on status, and for all I
know offering philosophical arguments about the rights and wrongs of modern
warfare. (When they go off target, it's nothing to do with cloud cover, it's
a crisis of conscience ;-)

--
Nick Roberts

Re: Refactoring and Ada

[Simon Wright]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> I think it's arguable whether that actually counts as
> refactoring. Do the semantics really remain the same (as opposed to
> 'effectively the same')?

I would be surprised if the refactoring process described in Fowler's
book ended up with code that had precisely the same semantics as the
original. Passes the same test suite, yes, but that's not the same.

>                          To clarify, could the change have been
> made, safely, by a purely mechanised algorithm? (I don't think
> so. And if it could, the algorithm would have to be fiendishly
> complex, no?)

Ditto any reasonable refactoring process?

Re: Refactoring and Ada

[Richard Riehle]

Pat Rogers wrote:

>
> On a much smaller scale of feature, I know
> of projects that have removed a great many "renames clauses" with "use type"
> clauses.

I still prefer renames clauses when only one or two operators  need direct
visibility.    Use type can be as dangerous as the full use clause under
some circumstances.

Richard Riehle

Re: Refactoring and Ada

[David C. Hoos, Sr.]

----- Original Message ----- 
From: "Richard Riehle" <richard@adaworks.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: February 03, 2002 10:32 PM
Subject: Re: Refactoring and Ada
<snip>
> I still prefer renames clauses when only one or two operators  need direct
> visibility.    Use type can be as dangerous as the full use clause under
> some circumstances.
> 
Could you give an example of such a circumstance, Richard?

Re: Refactoring and Ada

[Richard Riehle]

"David C. Hoos, Sr." wrote:

> ----- Original Message -----
> From: "Richard Riehle" <richard@adaworks.com>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: February 03, 2002 10:32 PM
> Subject: Re: Refactoring and Ada
> <snip>
> > I still prefer renames clauses when only one or two operators  need direct
> > visibility.    Use type can be as dangerous as the full use clause under
> > some circumstances.
> >
> Could you give an example of such a circumstance, Richard?

My concern is that use type makes all the operators visible for a
given type.   I realize the compiler can resolve the overloading
issues, so that is not so much of a problem.

There are at least two concerns with use type.  One is the lack of
documentation/traceability when there are multiple types in an
implementation.   The other is the potential for making an error
during maintenance, or even during development.

If, we with three packages, Goofy, Mickey, and Minnie, each of which
has type defined as Bone, Cheese, and Crackers, respectively we could
make all the operators directly visible with,

            use type Goofy.Bone;
            use type Mickey.Cheese;
            use type Minnie.Crackers;

Throughout my algorithmic code, I might be applying operators to objects
of these types without the lucidity afforded by dot notation I would routinely
use for operations.  Since all operators are directly visible for all types
named in my use type clause,  there is some potential for confusion on the
part of a programmer who has never seen this program before.

No only that.   It turns out that the only arithmetic operators I want to allow
for objects of type Goofy are addition and subtraction.   The only comparison
operators I am using are equality and greater-than.   It would be a disaster, in

the given program if a maintenance programmer were to test for less-than when
I wanted greater-than.    By coding my declarations so only those operators
appropriate to my program are directly visible (i.e., through renaming), I can
exert more precise control over the future of that code.

I am sure you can see where I am going with this.   Certainly, in those cases
where
I really want all the operators to be directly visible, use type has some
virtue.  For
systems where safety is a concern and where one can take advantage of Ada's
control over directly visibility, I think renaming is still a virtuous option.

I suppose I am old fashioned, but I still like the package design in which the
appropriate operators for a type are explicitly coded, either directly or
through a renames, in a nested package so the client of that package can do
something such as use Goofy.Operators.   This has the effect of making only
those operators directly visible that are necessary for the client.   I think it

also has the effect of making the design more clear, the client units safer,
and the code more traceable.

Someone once said that "Every political systems contains within it the seeds of
its
own destruction."   The same can be said of good ideas added to programming
languages.  I rather doubt there is a Beaujolais effect hidden in the use type
clause,
but I think there can be other problems now and then.   We need to consider the
full
range of options available to us when deciding how to approach visibility issues

in Ada.     The very fact that we have more than one option for managing
visibility
is one of the great benefits of using Ada in the first place.

Richard Riehle

Re: Refactoring and Ada

[Robert A Duff]

Richard Riehle <richard@adaworks.com> writes:

>...It would be a disaster, in
> the given program if a maintenance programmer were to test for less-than when
> I wanted greater-than.

The renaming trick can actually *cause* that problem:

    function "and"(X, Y: T) return T renames Mumble."and";
    function "or"(X, Y: T) return T renames Mumble."and";

Oops.  A cut-and-paste bug.

The problem is that renaming is too powerful for this purpose: renaming
allows you to change the name of the thing, which you don't want to do
9 times out of 10.  In this case, you just wanted to import the thing,
without actually renaming it.  And the reader won't notice this bug
easily, because there are thousands of lines of these boring renamings;
the reader thinks, "yeah, yeah, yeah, I already know what that says,
I need not read it carefully".

- Bob

Re: Refactoring and Ada

[Robert Dewar]

Richard Riehle <richard@adaworks.com> wrote in message news:<3C5E0ED6.E2D52BD3@adaworks.com>...
> Pat Rogers wrote:
> 
> >
> I still prefer renames clauses when only one or two
> operators  need direct
> visibility.    Use type can be as dangerous as the full 
> use clause under some circumstances.


I find this bad advice, so I would appreciate some further
evidence for this rather remarkable claim.

By the way, I talked to a never-ever-use-use user of Ada
the other day who was appalled to discover that even if
you don't use USE clauses, you can have a case where you
write

       a := f (x);

where there were no other occurrences of f in the same
source file, no USE clauses, and the textual declaration
of f was in another unit.

This is of course standard in both Ada 83 and Ada 95 (if
you don't know how it arises, and always assumed that avoiding use
clauses guaranteed that this could not happen,
you have always been fooling yourself :-)

I often find that people think that avoiding use clauses
avoids this, and requires full qualification. In fact in 
the above example, suppose the only other occurrence of
f is in package p, then it is the case that trying to
qualify by writing

       a := p.f (x);

is not just unnecessary, but in fact illegal. 

Implicit declarations often surprise people :-)

Re: Refactoring and Ada

[Pascal Obry]

dewar@gnat.com (Robert Dewar) writes:

> By the way, I talked to a never-ever-use-use user of Ada
> the other day who was appalled to discover that even if
> you don't use USE clauses, you can have a case where you
> write
> 
>        a := f (x);
> 
> where there were no other occurrences of f in the same
> source file, no USE clauses, and the textual declaration
> of f was in another unit.

You mean if x has a type which is derived from another one in a different
package. So f is an inherited function. Right ? Or is there another case ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Refactoring and Ada

[Robert Dewar]

Pascal Obry <p.obry@wanadoo.fr> wrote in message news:<un0yp84ka.fsf@wanadoo.fr>...
> You mean if x has a type which is derived from another 
> one in a different package. So f is an inherited 
> function. Right ? Or is there another case ?

Ah Pascal, you should have allowed people to puzzle over
this a bit longer, you would be surprised how many people
are confused by this.

Re: Refactoring and Ada

[Richard Riehle]

Robert Dewar wrote:

> Richard Riehle <richard@adaworks.com> wrote in message news:<3C5E0ED6.E2D52BD3@adaworks.com>...
> > Pat Rogers wrote:
> >
> > >
> > I still prefer renames clauses when only one or two
> > operators  need direct
> > visibility.    Use type can be as dangerous as the full
> > use clause under some circumstances.
>
> I find this bad advice, so I would appreciate some further
> evidence for this rather remarkable claim.

I have already posted my reasons for this in another message in
this thread.   My use of the word, "dangerous" may be a bit of
an exaggeration, but I do think renames is sometimes a better
option than use type -- not always -- but as my other posts
suggests, sometimes.

I am happy to have both options available.

Richard Riehle

Re: Refactoring and Ada

[Robert A Duff]

Richard Riehle <richard@adaworks.com> writes:

> I have already posted my reasons for this in another message in
> this thread.   My use of the word, "dangerous" may be a bit of
> an exaggeration, but I do think renames is sometimes a better
> option than use type -- not always -- but as my other posts
> suggests, sometimes.

For what it's worth, the language design team wanted to make the
behavior of "use type" happen without saying *anything*.  Tucker
invented "use type" as a compromise: many were worried about the upward
incompatibility.

- Bob

Re: Refactoring and Ada

[Robert A Duff]

dewar@gnat.com (Robert Dewar) writes:

> Implicit declarations often surprise people :-)

Oh!  I thought you were talking about a child package or subunit that
can see stuff in its parent.

- Bob

Re: Refactoring and Ada

[Dr. Michael Paus]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

Robert Dewar wrote:

> By the way, I talked to a never-ever-use-use user of Ada
> the other day who was appalled to discover that even if
> you don't use USE clauses, you can have a case where you
> write
> 
>        a := f (x);
> 
> where there were no other occurrences of f in the same
> source file, no USE clauses, and the textual declaration
> of f was in another unit.
> 
> This is of course standard in both Ada 83 and Ada 95 (if
> you don't know how it arises, and always assumed that avoiding use
> clauses guaranteed that this could not happen,
> you have always been fooling yourself :-)
> 
> I often find that people think that avoiding use clauses
> avoids this, and requires full qualification. In fact in
> the above example, suppose the only other occurrence of
> f is in package p, then it is the case that trying to
> qualify by writing
> 
>        a := p.f (x);
> 
> is not just unnecessary, but in fact illegal.

If I understand your example correctly, it reflects a problem
which I recently had to fix in program written by someone else.
We had the requirement not to use use and so the call of f had
to be qualified as in your example above. The compiler complained
about this of course and can you imagine what the programmer did
in order to fix the problem? The type of x (B_Type) was derived from
some other type (let's say A_Type). So the programmer wrote:

       a := p.f (p.A_Type(x));

The compiler was happy and in this particular case the program
even did what it was assumed to do. The hidden bug in this
statement is a maintenance time-bomb which would not have occurred
if use had been used.

Michael

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Visitenkarte f�r Dr. Michael Paus --]
[-- Type: text/x-vcard; charset=us-ascii; name="paus.vcf", Size: 332 bytes --]

begin:vcard 
n:Paus;Michael
tel;cell:0177-2238312
tel;fax:+49-(0)711-765-4095
tel;home:+49-(0)711-765-1493
tel;work:+49-(0)711-765-4094
x-mozilla-html:FALSE
url:www.ib-paus.com
org:Ingenieurb�ro Dr. Paus
adr:;;Sch�naicher Str. 3;Stuttgart;;70597;Germany
version:2.1
email;internet:paus@ib-paus.com
fn:Dr. Michael Paus
end:vcard

Re: Refactoring and Ada

[Pat Rogers]

"Dr. Michael Paus" <paus@ib-paus.com> wrote in message
news:3C623E98.646B7C0E@ib-paus.com...
> Robert Dewar wrote:
>
> > By the way, I talked to a never-ever-use-use user of Ada
> > the other day who was appalled to discover that even if
> > you don't use USE clauses, you can have a case where you
> > write
> >
> >        a := f (x);
> >
> > where there were no other occurrences of f in the same
> > source file, no USE clauses, and the textual declaration
> > of f was in another unit.
> >
> > This is of course standard in both Ada 83 and Ada 95 (if
> > you don't know how it arises, and always assumed that avoiding use
> > clauses guaranteed that this could not happen,
> > you have always been fooling yourself :-)
> >
> > I often find that people think that avoiding use clauses
> > avoids this, and requires full qualification. In fact in
> > the above example, suppose the only other occurrence of
> > f is in package p, then it is the case that trying to
> > qualify by writing
> >
> >        a := p.f (x);
> >
> > is not just unnecessary, but in fact illegal.
>
> If I understand your example correctly, it reflects a problem
> which I recently had to fix in program written by someone else.
> We had the requirement not to use use and so the call of f had
> to be qualified as in your example above.

That's a good example of the effect of blindly following bad rules, since the
"don't use use-clauses rule" doesn't even apply here.

> The compiler complained
> about this of course and can you imagine what the programmer did
> in order to fix the problem?  The type of x (B_Type) was derived from
> some other type (let's say A_Type). So the programmer wrote:
>
>        a := p.f (p.A_Type(x));
>
> The compiler was happy and in this particular case the program
> even did what it was assumed to do. The hidden bug in this
> statement is a maintenance time-bomb which would not have occurred
> if use had been used.

No, it is not a matter of use clauses, in terms of *language rules* they are not
at play here.  That is explicitly a call to the parent operation, and it should
not have passed the code review.    It did not do what it was assumed to do, for
that matter -- it called the parent operation, which must have not been
overridden since it seemed to do the right thing.

They should have written it something like this, to satisfy whomever:

package P is
   type T is range 1 .. 10;
   procedure Q( This : out T );
end P;


with P;
procedure R is
   type T2 is new P.T;
   X : T2;
begin
   R.Q( X );    -- note the name of the unit enclosing the derivation
end R;


---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: Refactoring and Ada

[Robert Dewar]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<a3hi78$18ga0c$1@ID-25716.news.dfncis.de>...
> Paul,
> 
> Ada has a co-standard called ASIS

I think it is just possible that Paul may have heard
of ASIS before :-) :-) :-)

> I suspect that, in the case of Ada, refactoring in 
> support of legacy code is unlikely in practice. This is 
> largely because Ada 95 contains virtually no
> incompatibilties with Ada 83, and added no features so 
> valuable that it would make it desirable to refactor Ada 
> 83 code to use those features.

A peculiar statement, since it represents such little
awareness of what actually goes on the field. In fact we
see many large users who are migrating large Ada 83 applications to
Ada 95, and I would guess exactly the
opposite that automated code transformations (I find the
term refactoring pompous :-) for, e.g. replacing certain
stylized uses of tasks in Ada 83 with protected types to
be potentially one of the most useful forms of this
technology. Certainly we have seen people write ASIS tools
to assist in transformations of this type.

Re: Refactoring and Ada

[Nick Roberts]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:5ee5b646.0202030548.5c471636@posting.google.com...

> "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
news:<a3hi78$18ga0c$1@ID-25716.news.dfncis.de>...
> > Paul,
> >
> > Ada has a co-standard called ASIS
>
> I think it is just possible that Paul may have heard
> of ASIS before :-) :-) :-)

I had no clue that Paul was so closely involved in ASIS. It was not an
attempt at humour, and I apologise for any misdirection or offence that may
have been given.

I might recall the well-known phenomenon that Internet forms of
communication lack many key 'cues' that we take for granted with other forms
of communication, and this can lead to strange instances of confusion at
times. On a Usenet newsgroup, the phrasing of a question can innocently (but
misleadingly) make the reader think the asker is not familiar with the
newsgroup's subject at all.

> > I suspect that, in the case of Ada, refactoring in
> > support of legacy code is unlikely in practice. This is
> > largely because Ada 95 contains virtually no
> > incompatibilties with Ada 83, and added no features so
> > valuable that it would make it desirable to refactor Ada
> > 83 code to use those features.
>
> A peculiar statement, since it represents such little
> awareness of what actually goes on the field. In fact we
> see many large users who are migrating large Ada 83 applications to
> Ada 95, and I would guess exactly the
> opposite that automated code transformations (I find the
> term refactoring pompous :-) for, e.g. replacing certain
> stylized uses of tasks in Ada 83 with protected types to
> be potentially one of the most useful forms of this
> technology. Certainly we have seen people write ASIS tools
> to assist in transformations of this type.

Robert, this comment seems to demonstrate your lack of understanding of the
difference between refactoring and automated code transformations in
general. I suspect that, actually, the task-to-protected-object
transformations you mention are only the latter.

--
Nick Roberts

Re: Refactoring and Ada

[Robert Dewar]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message news:<a3k692$18rkho$2@ID-25716.news.dfncis.de>...
 
> Robert, this comment seems to demonstrate your lack of 
> understanding of the difference between refactoring and 
> automated code transformations in general. I suspect 
> that, actually, the task-to-protected-object
> transformations you mention are only the latter.


To me, automated code transformation is very broad (exemplified for
example by the work of Robert Paige
on formal differentiation of algorithms) and certainly encompass what
has been relatively recently dubbed "refactoring". You must have
something narrower in mind
when you read the phrase. Look up Robert's work to get
an idea of what I have in mind (or look up my paper on
transformational derivation of a complex garbage collection
algorithm :-)

Re: Refactoring and Ada

[Paul Anderson]

Nick Roberts wrote:
> 
> "Robert Dewar" <dewar@gnat.com> wrote in message
> news:5ee5b646.0202030548.5c471636@posting.google.com...
> 
> > "Nick Roberts" <nickroberts@adaos.worldonline.co.uk> wrote in message
> news:<a3hi78$18ga0c$1@ID-25716.news.dfncis.de>...
> > > Paul,
> > >
> > > Ada has a co-standard called ASIS
> >
> > I think it is just possible that Paul may have heard
> > of ASIS before :-) :-) :-)
> 
> I had no clue that Paul was so closely involved in ASIS. It was not an
> attempt at humour, and I apologise for any misdirection or offence that may
> have been given.

Actually, I have not been closely involved in ASIS, except to
observe from the sidelines.  And I wouldn't have considered
your response either a misdirection or offensive in any case.
(I would chimed in earlier, except that I just got
back to work having fallen off a ladder at the weekend!)

The tool we plan to create will use ASIS, although not 
as the primary mechanism for transforming the code.  For that,
we will be using our Synthesizer Generator technology.

> If you would like me to throw in my own ideas, one fairly elaborate one
> occurs to me, to do with providing support for Aspect-Oriented Programming
> in Ada. It would work something like as follows.
> ...snipped...
 
It hadn't occurred to me that one could get the effect of
an AOP-like tool by using specialized refactorings in the
way you describe.  It is a useful suggestion, although such 
a transformation is probably quite a bit more complicated 
than most of the transformations in the refactoring catalogs.

Paul

______
Paul Anderson.  GrammaTech, Inc.    Tel: +1 607 273-7340 x18
mailto:paul@grammatech.com  http://www.grammatech.com

Re: Refactoring and Ada

[Volkert]

Paul Anderson <paul@grammatech.com> wrote in message news:<3C5AB0B7.9D75D49A@grammatech.com>...
>As part of a government research contract, we are developing a
>Refactoring editor for Ada.  I am interested in soliciting opinions
>from the group about Refactoring and Ada.
the idea is great! Especially the idea of doing the sematical 
preserving transformations with support of a tool. In my eyes, 
this all seems quite complex for Ada, but all Ada programers 
would like to see such a tool. 

>I am interested in finding out if there are any Ada projects out there
>that actively use refactoring.  If so, what refactorings do you use?
>Are they just like the Java ones, or are there features of Ada that
>mandate special-purpose refactorings?  What features would you like to
>see in a refactoring editor for Ada?
All the stuff like schema refactorings (consitant renaming and moving 
of packages, types, procedures, inherit, push_down/push up 
primitive operations, ...), function-to-procedure translation,
pattern integration ... but to my best knowledge, i don't know any 
documented refactorings for Ada in the quality of Martin Fowlers 
Refactoring-Book! 

Several month ago i asked in a german ada mailing list for support
to initiate an Ada Refactoring Tool. No interest. One person from 
R*ti*al mentioned, that their ApexTool can do most the refactoring 
stuff. I think, i was completely misunderstood about this topic.

To do more sophisticated refactorings in Ada you need a very good
a metamodel along with a set of transformation rules. A long
long way ... ASIS may be a good starting point, but makes in not
possible manipulate the Abstract Syntax Tree directly ...

Volkert Barr

--
barr@cs.tu-berlin.de
www.cs.tu-berlin.de/~barr

Re: Refactoring and Ada (tool I'd like to have...)

[David Emery]

A long time ago (in a galaxy far, far away :-), at one of the SIGAda
Future APSE workshops, Tucker Taft, Susan Dart (then at SEI) and I
formed a little group where we looked at "practical tools we wish we
had."  Before we knew the term 'refactoring', we proposed a tool
that would facilitate the movement of types and operations across
packages.  We called it the "hoister"...

Here's a scenario:  Assume a layered architecture, and package P has
a private type with a hidden component C, which comes from package Q.
Now for whatever good reason, we realize that we need to make component
C and its type visible.  So we'd like to "hoist" declarations from Q
and put them into P.  We'd like a tool that would automagically adjust
calls to operations in P and Q.  Some operations the tool could fix
itself, and others it would need to refer to the human engineer.

This is the kind of stuff that I think would be very valuable for
any programming language with an encapsulation mechanism, not just Ada.

         dave

Re: Refactoring and Ada

[Martin Dowie]

> I am especially interested in any use of refactoring in support of
> legacy code, either to clean up code that has been automatically
> translated to Ada, or to prepare Ada code so that it can be translated
> more easily into something else.

How about removing the 'confirming enumeration rep specs' that
are no longer necessary in Ada95?

e.g.
from:

    type An_Enumeration is (Foo, Bar);
    for  An_Enumeration is (Foo => 0, Bar => 1);

to:

    type An_Enumeration is (Foo, Bar);

Re: Refactoring and Ada

[Ted Dennison]

"Martin Dowie" <martin.dowie@nospam.baesystems.com> wrote in message news:<3c639940@pull.gecm.com>...
> How about removing the 'confirming enumeration rep specs' that
> are no longer necessary in Ada95?
> 
> e.g.
> from:
> 
>     type An_Enumeration is (Foo, Bar);
>     for  An_Enumeration is (Foo => 0, Bar => 1);

They weren't necessary in Ada 83 either were they?

Re: Refactoring and Ada

[Pat Rogers]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:4519e058.0202080714.1bf916bb@posting.google.com...
> "Martin Dowie" <martin.dowie@nospam.baesystems.com> wrote in message
news:<3c639940@pull.gecm.com>...
> > How about removing the 'confirming enumeration rep specs' that
> > are no longer necessary in Ada95?
> >
> > e.g.
> > from:
> >
> >     type An_Enumeration is (Foo, Bar);
> >     for  An_Enumeration is (Foo => 0, Bar => 1);
>
> They weren't necessary in Ada 83 either were they?

The issue in Ada 83 was that one didn't know what the underlying representation
would actually be, and of course sometimes that mattered.  If you really wanted
to be sure of the correspondence then you had to write the clause and hope that
the compiler would recognize them as merely confirming (for the sake of
performance).

Supposedly DEC Ada did some optimizations that involved scaling the underlying
representation for use elsewhere but I never found out if it was true.

Priorities were the same way -- you had to specify all of them if you cared
about any of them, because there was no way of knowing what they would be
otherwise.

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

OT : Re: Refactoring and Ada

[martin.m.dowie]

"Pat Rogers" <progers@classwide.com> wrote in message
news:WuS88.35716$LO2.710829202@newssvr12.news.prodigy.com...
> Priorities were the same way -- you had to specify all of them if you
cared
> about any of them, because there was no way of knowing what they would be
> otherwise.

Hi Pat!

I haven't seen your name around for a while - any plans to expand on
the UML->Ada95 converted you provided for "UML Studio"?

Re: Re: Refactoring and Ada

[Pat Rogers]

"martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
news:lJS88.8828$as2.1570670@news6-win.server.ntlworld.com...
> "Pat Rogers" <progers@classwide.com> wrote in message
> news:WuS88.35716$LO2.710829202@newssvr12.news.prodigy.com...
> > Priorities were the same way -- you had to specify all of them if you
> cared
> > about any of them, because there was no way of knowing what they would be
> > otherwise.
>
> Hi Pat!
>
> I haven't seen your name around for a while - any plans to expand on
> the UML->Ada95 converted you provided for "UML Studio"?

Not at the moment -- too many other things to do first.  At some point though it
would be nice to generate tasking from the diagrams...

Re: Re: Refactoring and Ada

[martin.m.dowie]

> > I haven't seen your name around for a while - any plans to expand on
> > the UML->Ada95 converted you provided for "UML Studio"?
>
> Not at the moment -- too many other things to do first.  At some point
though it
> would be nice to generate tasking from the diagrams...

Yeah - with an option for 'native' or 'ravenscar' :-)

I have been toying with the scripts to try and cope with transforming C++
names that are invalid in Ada into something that would be ok - then I could
import C++ code into UML classes and produce Ada from those. Do
you have any info. on the scripting language used? I'm flying blind here!

Re: Re: Refactoring and Ada

[Pat Rogers]

"martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
news:h1f98.25714$H37.3045173@news2-win.server.ntlworld.com...
> > > I haven't seen your name around for a while - any plans to expand on
> > > the UML->Ada95 converted you provided for "UML Studio"?
> >
> > Not at the moment -- too many other things to do first.  At some point
> though it
> > would be nice to generate tasking from the diagrams...
>
> Yeah - with an option for 'native' or 'ravenscar' :-)

Nice idea!

> I have been toying with the scripts to try and cope with transforming C++
> names that are invalid in Ada into something that would be ok - then I could
> import C++ code into UML classes and produce Ada from those. Do
> you have any info. on the scripting language used? I'm flying blind here!

It's a close cousin to Lisp.  I already have a function in there that makes Ada
names (converting interior blanks into underscores, etc.) from the diagram
elements, perhaps that would be the place to start. But it doesn't look for
leading underscores, a la C++.  Look for a function named 'MakeAdaName'.

Re: Re: Refactoring and Ada

[Martin Dowie]

> > Yeah - with an option for 'native' or 'ravenscar' :-)
>
> Nice idea!
>
> > I have been toying with the scripts to try and cope with transforming
C++
> > names that are invalid in Ada into something that would be ok - then I
could
> > import C++ code into UML classes and produce Ada from those. Do
> > you have any info. on the scripting language used? I'm flying blind
here!
>
> It's a close cousin to Lisp.  I already have a function in there that
makes Ada
> names (converting interior blanks into underscores, etc.) from the diagram
> elements, perhaps that would be the place to start. But it doesn't look
for
> leading underscores, a la C++.  Look for a function named 'MakeAdaName'.

Thanks, yes, that's exactly where I've been playing about. As well as
leading underscores, there are trailing underscores to consider and also
'what do you change it to?' I doubt just removing either underscore would be
good enough as (bizarrely) there may be another field with that name! A
known and _very_ random pre/post fix could be added I suppose... not 100%
bullet proof but with suitable 'information text' the user could decide
what to do

Re: Refactoring and Ada

[martin.m.dowie]

> > How about removing the 'confirming enumeration rep specs' that
> > are no longer necessary in Ada95?
[snip]
>
> They weren't necessary in Ada 83 either were they?

My understanding was that there was no requirement for a compiler
to select a contiguous range of values from 0. So while I never actually
came across a compiler that didn't do this, for the sake of portability
they were always added where we cared about the underlying rep.

Thankfully, we don't have to add this 'noise' anymore :-) but there
must be thousands of lines of code like this around cluttering up code.
From memory Robert Dewar once mentioned that these statements
were actually dangerous (my word not his!) in Ada95. Presumably as a
compiler may mistake them for some sort of 'special case' and produce
some less than optimal code.

Re: Refactoring and Ada

[Pat Rogers]

"martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
news:UHS88.8818$as2.1569475@news6-win.server.ntlworld.com...
> > > How about removing the 'confirming enumeration rep specs' that
> > > are no longer necessary in Ada95?
> [snip]
> >
> > They weren't necessary in Ada 83 either were they?
>
> My understanding was that there was no requirement for a compiler
> to select a contiguous range of values from 0. So while I never actually
> came across a compiler that didn't do this, for the sake of portability
> they were always added where we cared about the underlying rep.
>
> Thankfully, we don't have to add this 'noise' anymore :-) but there
> must be thousands of lines of code like this around cluttering up code.
> From memory Robert Dewar once mentioned that these statements
> were actually dangerous (my word not his!) in Ada95. Presumably as a
> compiler may mistake them for some sort of 'special case' and produce
> some less than optimal code.

The issue is indeed performance.   (The special case to be recognized by the
compiler is that the clause is in fact a confirming rep clause.)  The semantics
have to be maintained -- eg, array indexing and for-loop iterations -- but the
compiler will produce comparably inefficient code unless the special case is
recognized.  (Most do.)  Think about how array element address calculation would
work using arbitrarily ascending values for the indexes, and the problem becomes
evident.

---
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com          Real-Time/OO Languages
progers@classwide.com               Hard Deadline Schedulability Analysis
(281)648-3165                                 Software Fault Tolerance

Re: Refactoring and Ada

[martin.m.dowie]

> The issue is indeed performance.   (The special case to be recognized by
the
> compiler is that the clause is in fact a confirming rep clause.)  The
semantics
> have to be maintained -- eg, array indexing and for-loop iterations -- but
the
> compiler will produce comparably inefficient code unless the special case
is
> recognized.  (Most do.)  Think about how array element address calculation
would
> work using arbitrarily ascending values for the indexes, and the problem
becomes
> evident.

Thought as much - not exactly hard to spot though you would think!

Re: Refactoring and Ada

[Pat Rogers]

"martin.m.dowie" <martin.m.dowie@ntlworld.com> wrote in message
news:23f98.25730$H37.3045922@news2-win.server.ntlworld.com...
> > The issue is indeed performance.   (The special case to be recognized by
> the
> > compiler is that the clause is in fact a confirming rep clause.)  The
> semantics
> > have to be maintained -- eg, array indexing and for-loop iterations -- but
> the
> > compiler will produce comparably inefficient code unless the special case
> is
> > recognized.  (Most do.)  Think about how array element address calculation
> would
> > work using arbitrarily ascending values for the indexes, and the problem
> becomes
> > evident.
>
> Thought as much - not exactly hard to spot though you would think!

Right.

Re: Refactoring and Ada

[Marc A. Criley]

Ted Dennison wrote:
> 
> "Martin Dowie" <martin.dowie@nospam.baesystems.com> wrote in message news:<3c639940@pull.gecm.com>...
> > How about removing the 'confirming enumeration rep specs' that
> > are no longer necessary in Ada95?
> >
> > e.g.
> > from:
> >
> >     type An_Enumeration is (Foo, Bar);
> >     for  An_Enumeration is (Foo => 0, Bar => 1);
> 
> They weren't necessary in Ada 83 either were they?

I saw myriad instances of these specification in the code from certain
projects.  And the thing is, they were rarely in situations where the
underlying representation was of any interest, the enumerations were
being used as nothing more than enumerations.  The only thing I could
figure was that it was paranoia from some of the early Ada adopters.

Marc A. Criley
Consultant
Quadrus Corporation
www.quadruscorp.com

Re: Refactoring and Ada

[tmoran]

>And the thing is, they were rarely in situations where the underlying
>representation was of any interest, ...  The only thing I could figure
>was that it was paranoia from some of the early Ada adopters.
  A lesson for language designers?
  When cake mixes in boxes first came out they sold poorly.  The
directions said "add water and beat" and housewives felt useless.
Then someone came out with a version where the housewife had to add an
egg.  That felt more like making a cake and resulted in much greater
sales.  Perhaps early Ada adopters also needed such a proprietary
sense of accomplishment?

Re: Refactoring and Ada

[Marin David Condic]

I'd agree that all too often folks would slap a rep clause on something
where the internal representation didn't matter. But often it was done for
something reasonably approximating a good reason:

"I'm not sure how this type may be used as the system grows. Perhaps we'll
be putting it into external messages or files and it will be important to
insure that we know/control the representation..."

"Sure, we know it goes 0, 1, 2... for now, but we're getting it from some
other source and we have to deal with the possibility of a different
representation later..."

"*I* know that the compiler is giving us 0, 1, 2... and *you* know the
compiler is giving us 0, 1, 2..., but the standard doesn't *guarantee* that
this must be the case so what if some perverted, sick, twisted compiler
writer changes his mind with a later version of the compiler? (or a
different brand, or a later standard...)"

Maybe it bordered on paranoia - but paranoia is just a kind of awareness &
awareness is just a form of love. :-) Its a good thing that Ada95 promised
to provide what one would reasonably expect from an enumeration.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Marc A. Criley" <mcqada95@earthlink.net> wrote in message
news:3C65BFF4.F15A07D0@earthlink.net...
>
> I saw myriad instances of these specification in the code from certain
> projects.  And the thing is, they were rarely in situations where the
> underlying representation was of any interest, the enumerations were
> being used as nothing more than enumerations.  The only thing I could
> figure was that it was paranoia from some of the early Ada adopters.
>

Re: Refactoring and Ada

[Simon Wright]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> I'd agree that all too often folks would slap a rep clause on
> something where the internal representation didn't matter. But often
> it was done for something reasonably approximating a good reason:
> 
> "I'm not sure how this type may be used as the system grows. Perhaps
> we'll be putting it into external messages or files and it will be
> important to insure that we know/control the representation..."

I would derive a new type for external use and put the representation
clauses on that:

   package Rep is

      type Int is (A, B);

      for Int use (A => 0, B => 1);  --  confirming, of course

      type Ext is new Int;

      for Ext use (A => 16#aa#, B => 16#bb#);

   end Rep;

Re: Refactoring and Ada

[Marin David Condic]

Sure, solutions do exist. Its just that people might often have used a rep
clause where it wasn't strictly necessary because they were thinking of some
future situation where having the rep clause may have been important. It may
not be a *great* reason - but it is possible that there *was* a reason -
other than total ignorance. :-)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Simon Wright" <simon@pushface.org> wrote in message
news:x7veljqldd6.fsf@smaug.pushface.org...
>
> I would derive a new type for external use and put the representation
> clauses on that:
>
>    package Rep is
>
>       type Int is (A, B);
>
>       for Int use (A => 0, B => 1);  --  confirming, of course
>
>       type Ext is new Int;
>
>       for Ext use (A => 16#aa#, B => 16#bb#);
>
>    end Rep;
>

Re: Refactoring and Ada

[Matthew Heaney]

"Simon Wright" <simon@pushface.org> wrote in message
news:x7veljqldd6.fsf@smaug.pushface.org...
> I would derive a new type for external use and put the representation
> clauses on that:

I don't recommend you use representation clauses for enumeration types.  You
should forget this language feature even exists.  Just use integer constants
explicitly.

Re: Refactoring and Ada

[Larry Kilgallen]

In article <u6qrqp4dlso46f@corp.supernews.com>, "Matthew Heaney" <mheaney@on2.com> writes:
> 
> "Simon Wright" <simon@pushface.org> wrote in message
> news:x7veljqldd6.fsf@smaug.pushface.org...
>> I would derive a new type for external use and put the representation
>> clauses on that:
> 
> I don't recommend you use representation clauses for enumeration types.  You
> should forget this language feature even exists.  Just use integer constants
> explicitly.

Why ?

The inability to store an arbitrary numeric value into a location
whose type is enumerated is one of Ada's greatest strengths.

Re: Refactoring and Ada

[Matthew Heaney]

"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:DRxVLK5K93Eq@eisner.encompasserve.org...
> In article <u6qrqp4dlso46f@corp.supernews.com>, "Matthew Heaney"
<mheaney@on2.com> writes:
> > I don't recommend you use representation clauses for enumeration types.
You
> > should forget this language feature even exists.  Just use integer
constants
> > explicitly.
>
> Why ?
>
> The inability to store an arbitrary numeric value into a location
> whose type is enumerated is one of Ada's greatest strengths.

Here's why:

type ET is (A, B);
for ET use (A => 0, B => 1000000);

A : array (ET) of Integer;

How much storage does array A consume?

Here's another reason:

E : aliased ET;
for E'Size use 8;

read (fd, E'Address, 1);

case E is ...;

What happens when you read junk off the interface?

Below is a post from Tucker on this very subject (courtesy of google):
From: stt@houdini.camb.inmet.com (Tucker Taft)
Subject: Re: Beware: Rep spec on an enumeration type causes code explosion
Date: 1997/12/09
Message-ID: <EKxx9n.Ly1.0.-s@inmet.camb.inmet.com>#1/1
Sender: news@inmet.camb.inmet.com (USENET news)
References: <gwinn-0812971210080001@dh5055133.res.ray.com>
X-Nntp-Posting-Host: houdini.camb.inmet.com
Organization: Intermetrics, Inc.
Newsgroups: comp.lang.ada



Joe Gwinn (gwinn@res.ray.com) wrote:
: In article <EKrsrr.LD7.0.-s@inmet.camb.inmet.com>,
: stt@houdini.camb.inmet.com (Tucker Taft) wrote:

: ...
: > As far as enumeration types, as others have pointed out, the Ada 95
: > standard requires that the internal codes for enumeration types are
: > contiguous and start at zero, so you are not in any danger if you leave
: > out your "confirming" representation clauses.  It would be nice if
: > our front end recognized "confirming" enumeration representation
: > clauses, but as usual, there are many possible "optimizations"
: > and this one never made it to the top of the list.
: > One might argue that this is not really an optimization, but
: > it does require special code to recognize, and so represents
: > yet another "special case" that you have to decide the priority
: > of recognizing.

: The key issue was that we had no way of knowing the dire consequences of
: this innocent looking bit of standard Ada, until we had gone a fair
: distance down that wrong road.

If you ask anyone who knows me well, you will know that I consider
the enumeration representation clause anything but "innocent looking" ;-).
For what it is worth, we will soon be releasing a new front end
that recognizes the special case of a confirming enumeration
representation clause.

[ASIDE:

Although the ability to specify the representation of an enumeration
type initially sounds perfectly reasonable, the fundamental problem is that
Ada also allows such "holey" enumeration types to be used as the
type for a for-loop index, an array index, an entry family index,
or the 'Succ/'Pred attributes.  This results in surprising implicit
inefficiencies, something that violates one of the general Ada
language design principles.  Your enumeration rep clause simply reconfirmed
the default representation, but suppose it didn't?  You would be
stuck with the overhead you managed to eliminate by simply commenting
out the rep clause.  Of course, the compiler could recognize various
other specials cases, such as contiguous representation starting at
something other than zero, or evenly distributed "holey" representation
(e.g., even numbers only), or simply not "too" sparse, or ...

Pretty soon handling these enumeration representation clauses
the way the "innocent" user would "expect" becomes a major artificial
intelligence challenge.  During the Ada 9X design process, when we
found one of our new language ideas evoving into this kind of complex
AI pattern matching problem for the compiler, we knew we were on the
wrong track.  The user should be designing the algorithms, using
the basic primitives of the language.  The primitives shouldn't themselves
be at such a level that the compiler is effectively trying to take over
part of the programming problem.

Note that in C and C++, allowing the user to specify the values for
enumeration literals creates no similar problem, because there is
no operation that depends on the logical "position" of an enumeration
literal.  All semantics of enumeration values in C/C++ depends on the
underlying "code," not the position.

So in retrospect, I believe enumeration representation
clauses in Ada are a mistake.  If a user wants to name
particular values, they should simply use named integer
constants, or perhaps better, named private-type constants.  They can build
up various maps of their own if they want to translate to/from some kind
of "holey" representation from/to a contiguous representation.

END OF ASIDE]

: ... One wonders what other surprises lay in
: wait.

In general, the Ada language design philosophy eschewed "innocent"
looking features that were in fact expensive at run-time.
However, in the specific case of enumeration representation clauses,
this useful language design philosophy was not completely followed.
Other cases I know of are interactions between finalization,
exception handling, and abort, where the combination of features
forces some or all of these three to incur more run-time overhead
than you might expect.

One "innocent" looking construct I once found was:

   (others => Default_Value(Segment))

used to initialize a segment of a load module to some default value.
This called the function Default_Value once for each byte of the
segment, and the segment was often 100K bytes or more.

: ...

: Joe Gwinn

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Refactoring and Ada

[Larry Kilgallen]

In article <u750go7j0d1v7e@corp.supernews.com>, "Matthew Heaney" <mheaney@on2.com> writes:
> 
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> news:DRxVLK5K93Eq@eisner.encompasserve.org...
>> In article <u6qrqp4dlso46f@corp.supernews.com>, "Matthew Heaney"
> <mheaney@on2.com> writes:
>> > I don't recommend you use representation clauses for enumeration types.
> You
>> > should forget this language feature even exists.  Just use integer
> constants
>> > explicitly.
>>
>> Why ?
>>
>> The inability to store an arbitrary numeric value into a location
>> whose type is enumerated is one of Ada's greatest strengths.

> Here's another reason:
> 
> E : aliased ET;
> for E'Size use 8;
> 
> read (fd, E'Address, 1);
> 
> case E is ...;
> 
> What happens when you read junk off the interface?

Doesn't 'Valid detect that ?

Re: Refactoring and Ada

[Richard Riehle]

Larry Kilgallen wrote:

> > What happens when you read junk off the interface?
>
> Doesn't 'Valid detect that ?

It turns out that 'Valid is not as useful as many of us thought it was. For
example,  the result of an erroneous result from unchecked conversion,
which we originally thought was harmless if we checked it ourselves
with 'Valid before using it is a problem.   Consider the following,

               type X is ... ;
               type Y is ... ;

               function Convert is new Ada.Unchecked_Conversion
                                         (Source => Y, Target => X);


                X := Convert (Y);     -- suppose X is erroneous or not valid
                if X'Valid then ...      -- We used to think this was OK.
                                                 -- Some compilers fail on this because of an
interpretation
                                                 -- of the ALRM rules.

 At present, one must wonder about the usefulness of 'Valid.

Richard Riehle

Re: Refactoring and Ada

[Mark Biggar]

Richard Riehle wrote:
> 
> Larry Kilgallen wrote:
> 
> > > What happens when you read junk off the interface?
> >
> > Doesn't 'Valid detect that ?
> 
> It turns out that 'Valid is not as useful as many of us thought it was. For
> example,  the result of an erroneous result from unchecked conversion,
> which we originally thought was harmless if we checked it ourselves
> with 'Valid before using it is a problem.   Consider the following,
> 
>                type X is ... ;
>                type Y is ... ;
> 
>                function Convert is new Ada.Unchecked_Conversion
>                                          (Source => Y, Target => X);
> 
>                 X := Convert (Y);     -- suppose X is erroneous or not valid
>                 if X'Valid then ...      -- We used to think this was OK.
>                                                  -- Some compilers fail on this because of an
> interpretation
>                                                  -- of the ALRM rules.
> 
>  At present, one must wonder about the usefulness of 'Valid.

There is an AI with a binding interpretation that was included in the
TC that says that at least for scalar types the above code is
not errorious and must work as expected.

SO any compiler that fail on the above are non-compliant.

--
Mark Biggar
mark.a.biggar@attbi.com

Re: Refactoring and Ada

[Pat Rogers]

"Richard Riehle" <richard@adaworks.com> wrote in message
news:3C7324BF.996E182B@adaworks.com...
<snip>
> It turns out that 'Valid is not as useful as many of us thought it was. For
> example,  the result of an erroneous result from unchecked conversion,
> which we originally thought was harmless if we checked it ourselves
> with 'Valid before using it is a problem.   Consider the following,
>
>                type X is ... ;
>                type Y is ... ;
>
>                function Convert is new Ada.Unchecked_Conversion
>                                          (Source => Y, Target => X);
>
>
>                 X := Convert (Y);     -- suppose X is erroneous or not valid
>                 if X'Valid then ...      -- We used to think this was OK.
>                                                  -- Some compilers fail on
this because of an
> interpretation
>                                                  -- of the ALRM rules.
>
>  At present, one must wonder about the usefulness of 'Valid.

What's the exegesis for this?

Re: Refactoring and Ada

[Matthew Heaney]

"Pat Rogers" <progers@classwide.com> wrote in message
news:crKc8.703$OD1.124126259@newssvr11.news.prodigy.com...
> "Richard Riehle" <richard@adaworks.com> wrote in message
> news:3C7324BF.996E182B@adaworks.com...
> >  At present, one must wonder about the usefulness of 'Valid.
>
> What's the exegesis for this?

It's superfluous.  If you don't use enumeration representation clauses, the
need for 'Valid disappears.

Don't use enumeration representation clauses.  Use named integer constants
instead.

Just treat enumeration representation clauses as an obsolescent feature of
the language.  Don't use them for any new code.

Don't use enumeration representation clauses.  Don't use 'Valid.

Re: Refactoring and Ada

[Pat Rogers]

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:u77m1kircnen46@corp.supernews.com...
>
> "Pat Rogers" <progers@classwide.com> wrote in message
> news:crKc8.703$OD1.124126259@newssvr11.news.prodigy.com...
> > "Richard Riehle" <richard@adaworks.com> wrote in message
> > news:3C7324BF.996E182B@adaworks.com...
> > >  At present, one must wonder about the usefulness of 'Valid.
> >
> > What's the exegesis for this?
>
> It's superfluous.  If you don't use enumeration representation clauses, the
> need for 'Valid disappears.
>
> Don't use enumeration representation clauses.  Use named integer constants
> instead.

Agreed.

> Don't use enumeration representation clauses.  Don't use 'Valid.

Saying not to use 'Valid is too much, IMHO.  Sometimes one has to get scalar
values -- not just enumerals -- from external sources, and there 'Valid can be
useful.

No, I was asking for the exegesis in terms of the RM for Richard's much more
sweeping "comdemnation" of the attribute.  ("Condemnation" is too strong here,
but you get the idea.)

Re: Refactoring and Ada

[Matthew Heaney]

"Pat Rogers" <progers@classwide.com> wrote in message
news:ZTQc8.51466$lT5.3914605627@newssvr30.news.prodigy.com...
> Saying not to use 'Valid is too much, IMHO.  Sometimes one has to get
scalar
> values -- not just enumerals -- from external sources, and there 'Valid
can be
> useful.

What kinds of scalar values are you talking about?  Integers?  Floats?
Fixed point?

You should never read data from an external source into a variable whose
type doesn't include all possible values for its precision.  Therefore,
'Valid is still useless.

Re: Refactoring and Ada

[Pat Rogers]

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:u77p6fp1hcta76@corp.supernews.com...
>
> "Pat Rogers" <progers@classwide.com> wrote in message
> news:ZTQc8.51466$lT5.3914605627@newssvr30.news.prodigy.com...
> > Saying not to use 'Valid is too much, IMHO.  Sometimes one has to get
> scalar
> > values -- not just enumerals -- from external sources, and there 'Valid
> can be
> > useful.
>
> What kinds of scalar values are you talking about?  Integers?  Floats?
> Fixed point?
>
> You should never read data from an external source into a variable whose
> type doesn't include all possible values for its precision.

Can you explain why you think that?

> Therefore, 'Valid is still useless.


I'm not yet convinced...

Re: Refactoring and Ada

[Robert Dewar]

"Matthew Heaney" <mheaney@on2.com> wrote in message news:<u77p6fp1hcta76@corp.supernews.com>...

> You should never read data from an external source into a 
> variable whose type doesn't include all possible values 
> for its precision.  Therefore, 'Valid is still useless


That's complete nonsense. Indeed whenever ANYONE on this
newsgroup decrees a feature in Ada to be useless. They probably are
missing important understanding. After all that person is saying in
effect "the people who designed and reviewed Ada 95 are idiots, they
put in a feature that is useless, but I am cleverer than all of them
and I know it is useless". In fact 'Valid is very useful in many
situations.

Re: Refactoring and Ada

[Randy Brukardt]

>No, I was asking for the exegesis in terms of the RM for Richard's much
more
>sweeping "comdemnation" of the attribute.  ("Condemnation" is too
strong here,
>but you get the idea.)

Reading AI-167 might help some
(http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00167.TXT?rev=1.5).
But this AI is still under construction (it is not, and never has been,
approved, contrary to the statement of someone else here), and
undoubtably will change.

We (the ARG) spent a couple of hours discussing this at the recent ARG
meeting (which Richard attended), but I'm not sure that we're really any
closer to a resolution. The main problem is that the obvious solutions
have an unacceptable performance cost for applications that don't put
invalid values through Unchecked_Conversion.

The problem rule is 13.9.1(12), which makes the CALL to
Unchecked_Conversion erroneous if the result is invalid. And this rule
is intended (I forget why, Bob?).

This was the last item discussed on Monday, so the desire to go to
dinner may have pushed us to a resolution that won't hold up.

The minutes of the meeting will have more information, but they won't
able available for a while yet.

                    Randy Brukardt
                    ARG Editor

Re: Refactoring and Ada

[Pat Rogers]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:u78hac6o7iku15@corp.supernews.com...
> >No, I was asking for the exegesis in terms of the RM for Richard's much
> more
> >sweeping "comdemnation" of the attribute.  ("Condemnation" is too
> strong here,
> >but you get the idea.)
>
> Reading AI-167 might help some
> (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00167.TXT?rev=1.5).
> But this AI is still under construction (it is not, and never has been,
> approved, contrary to the statement of someone else here), and
> undoubtably will change.

Thanks, though, anyway -- interesting reading.

> We (the ARG) spent a couple of hours discussing this at the recent ARG
> meeting (which Richard attended), but I'm not sure that we're really any
> closer to a resolution. The main problem is that the obvious solutions
> have an unacceptable performance cost for applications that don't put
> invalid values through Unchecked_Conversion.
>
> The problem rule is 13.9.1(12), which makes the CALL to
> Unchecked_Conversion erroneous if the result is invalid. And this rule
> is intended (I forget why, Bob?).

OK, I didn't get that -- the fact that the *call* is erroenous in that
situation.

> This was the last item discussed on Monday, so the desire to go to
> dinner may have pushed us to a resolution that won't hold up.

I'm familiar with the related "concensus by exhaustion".  :-)


Pat

Re: Refactoring and Ada

[Pat Rogers]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:u78hac6o7iku15@corp.supernews.com...
> >No, I was asking for the exegesis in terms of the RM for Richard's much
> more sweeping "comdemnation" of the attribute.  ("Condemnation" is too
> strong here, but you get the idea.)
>
> Reading AI-167 might help some
> (http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00167.TXT?rev=1.5).
> But this AI is still under construction (it is not, and never has been,
> approved, contrary to the statement of someone else here), and
> undoubtably will change.
<snip>
> The problem rule is 13.9.1(12), which makes the CALL to
> Unchecked_Conversion erroneous if the result is invalid. And this rule
> is intended (I forget why, Bob?).

Thanks (again) for the pointer to the AI in progress.  Clearly there is a
problem for unchecked conversion in this case.

However, unchecked conversion isn't the only way to get the value to which
'Valid is applied.  For example, via RM 13.9.2(11):

  P : aliased Positive;

  K : Integer;
  for K'Address use P'Address;

begin
  K := 0;
  if P'Valid then ...

or, for that matter, via System.Address_To_Access_Conversions (for Integer in
this example).

The OP's saying that 'Valid is useless isn't justified by the problem with
unchecked conversion, IMHO.

What am I missing?

Pat

Re: Refactoring and Ada

[Randy Brukardt]

> or, for that matter, via System.Address_To_Access_Conversions
> (for Integer in this example).

Or, pragma Import of a C object or subprogram. Or reading from a stream.
(The intended uses of the attribute).

> The OP's saying that 'Valid is useless isn't justified by the problem
with
> unchecked conversion, IMHO.

I agree with this. 'Valid is (almost) useless combined with UC, but that
is true whether or not UC is erroneous -- in most cases (other than
[very] sparse enums and float values) it is trivial to check before
applying UC. So it isn't needed in those cases. That can't be done in
the other cases - C or a file could contain anything.

> What am I missing?

Nothing that I see. The ARG discussion was narrowly focused around
'Valid and UC -- perhaps not everyone realized that.

   Randy Brukardt.

Re: Refactoring and Ada

[Robert Dewar]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<u7ddjt7jko763b@corp.supernews.com>...
> I agree with this. 'Valid is (almost) useless combined 
> with UC, but that is true whether or not UC is erroneous
> in most cases (other than [very] sparse enums and float 
> values) it is trivial to check before
> applying UC. 

Yes, of course you mention the two cases in which UC/'Valid
is most useful (sparse enums, and floats). And I will
say it again, I recommend you choose a compiler that properly supports
this in the obviuosly intended manner.

Remember that if you insist on writing only code that is
absolutely 100% guaranteed to run on all compilers according to a
strict reading of the RM, you can't write
anything at all (consider for example

RM 1.1.3(3) which allows arbitrary programs to be rejected
on the grounds that they are too large.

RM 1.1.3(6) which allows compilers to reject anything that
in the sole opinion of the implementor is deemed 
"impractical" to implement (certainly $ cost is a possible
reason for example of something being impractical, since
there is no attempt to give the word any meaning other than
its ordinary meaning in english).

So it is always the case that you have to choose a compiler
that takes a reasonable pragmatic approach to everything,
where YOU define what reasonable means!

I know well this argument about UC and 'Valid, I consider
it specious :-)

Re: Refactoring and Ada

[Randy Brukardt]

Robert Dewar wrote in message
<5ee5b646.0202231504.5903c583@posting.google.com>...

>So it is always the case that you have to choose a compiler
>that takes a reasonable pragmatic approach to everything,
>where YOU define what reasonable means!
>
>I know well this argument about UC and 'Valid, I consider
>it specious :-)

Well, this seems to be a slippery slope argument; essentially you are
saying that it is OK to write erroneous code as long as your compiler
"does the right thing". That seems to me to be a bad precedent; we want
to make as easy as possible for people to write code that is portable
and depends on compiler support only in well-defined ways. RM 1.1.3(3
and 6) allow programs to be rejected, but those are clearly indicated
problems; if a compiler does the "wrong" thing with erroneous code,
there is not going to be any indication to the developer.

                Randy.

Re: Refactoring and Ada

[Robert Dewar]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<u7ddjt7jko763b@corp.supernews.com>...


OK, if you want my 2cents on the UC issue in more detail
here it is. Yes, of course in general functions have to
be allowed to behave erroneously in this case. Consider
for example the case of a signalling NaN returned on a
machine where you are forced to put FPT results into an
FPT register.

However, UC to me is only defined as a function for the
convenience of the LRM. It is not a real function, and we
would be shocked to find a compiler that actually called
a function body using the standard calling sequence. 
Instead what we expect to see is very specialized intrinsic
code that makes sure that UC is well behaved in this kind
of regard.

To argue detailed semantics of UC assuming it is an ordinary function
is a mistake in my opinion. Indeed one
wonder whether it would not have been better to avoid
modeling UC as a function, and perhaps instead use an
attribute

   Integer'Unchecked_Conversion (X);

to make it quite clear that this is special. I also consider the above
to be quite noisy enough (the with
and instantiations are often a bit TOO much of a good thing).

Hmm! nothing to stop an implementation putting this in and
documenting its semantics as 100% operational (with a note
that you can use this attribute and ignore the ARG :-)

Re: Refactoring and Ada

[Robert Dewar]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<u78hac6o7iku15@corp.supernews.com>...
> The problem rule is 13.9.1(12), which makes the CALL to
> Unchecked_Conversion erroneous if the result is invalid. 
> And this rule is intended (I forget why, Bob?).

Well I am sure the folks at the ARG enjoy having language
lawyer debates, but I think they would better spend their
time going back to the much more useful topic of angels on
a pinhead.

I stick to my guns here. Any compiler that does not allow
the sequence that Richard Riehle showed in his example of
UC followed by 'Valid is broken.

Re: Refactoring and Ada

[Robert Dewar]

Richard Riehle <richard@adaworks.com> wrote in message news:<3C7324BF.996E182B@adaworks.com>...
> Larry Kilgallen wrote:
> 
> > > What happens when you read junk off the interface?
> >
> > Doesn't 'Valid detect that ?
> 
> It turns out that 'Valid is not as useful as many of us 
> thought it was. Fo example,  the result of an erroneous 
> result from unchecked conversion

What do you mean  by "an erroneous result" from unchecked conversion.
The word erroneous does not appear in RM section 13.9.

Now it is true that UC is implementation defined, and one
can imagine an unusable implementation that "defines" the
action of some UC's to be the equivalent of erroneous, but
if you find such a compiler I suggest you file it in the
circular file, since it is working hard to be useless.

> which we originally 
> thought was harmless if we checked it ourselves
> with 'Valid before using it is a problem.   Consider the 
> following,
> 
>                type X is ... ;
>                type Y is ... ;
> 
>                function Convert is new 
>                  Ada.Unchecked_Conversion
>                    (Source => Y, Target => X);
> 
> 
>                 X := Convert (Y);     -- suppose X is 
>                        erroneous or not valid

First of all, a value can never be erroneous, this is sloppy
terminology. Only a program execution can be
erroneous, and certainly one does NOT expect the above to
be erroneous on any reasonable compiler. A compiler would
have to explicitly document this as erroneous, and it would
be treading on thin ice, since the idea of implementation defined is
to exclude erroneous behavior. Yes a language
lawyer can argue that erroneousity is included in the range of
possible impl defined values, but that's no excuse for
a compiler to malfunction this way. There are many many
ways in which compilers can be made unusable, this is one
of them, and there is no reason to put up with it.


>                 if X'Valid then ...      -- We used to 
>                   think this was OK.

It's just fine

>                                                  -- Some 
> compilers fail on this because of an
> interpretation of the ALRM rules.

There is no interpretation involved here, this is a matter
of implementation defined behavior.

>  At present, one must wonder about the usefulness of 
> 'Valid.


That's like finding a compiler that does all multiplications by
repeated addition and then wondering about the utility of the *
operator in Ada.

On a decent compiler, the above works fine, and is a useful
(and commonly used) use of 'Valid.

Re: Refactoring and Ada

[Nick Roberts]

On 23 Feb 2002 14:55:29 -0800, dewar@gnat.com (Robert Dewar) strongly
typed:

>Richard Riehle <richard@adaworks.com> wrote in message 
>news:<3C7324BF.996E182B@adaworks.com>...
>>...
>>  At present, one must wonder about the usefulness of 
>> 'Valid.
>
>That's like finding a compiler that does all multiplications by
>repeated addition and then wondering about the utility of the *
>operator in Ada.
>
>On a decent compiler, the above [use of 'Valid] works fine, and
>is a useful (and commonly used) use of 'Valid.

Hear hear!

-- 
Nick Roberts

Re: Refactoring and Ada

[Christoph Grein]

> > By the way, I talked to a never-ever-use-use user of Ada
> > the other day who was appalled to discover that even if
> > you don't use USE clauses, you can have a case where you
> > write
> > 
> >        a := f (x);
> > 
> > where there were no other occurrences of f in the same
> > source file, no USE clauses, and the textual declaration
> > of f was in another unit [call it p].
> 
> You mean if x has a type which is derived from another one in a different
> package. So f is an inherited function. Right ? Or is there another case ?

Of course there are other cases (child packages), but there qualifying p.f would 
be legal. With inheritance, p.f is illegal as Robert said.

Re: Refactoring and Ada

[Christoph Grein]

> > I often find that people think that avoiding use clauses
> > avoids this, and requires full qualification. In fact in
> > the above example, suppose the only other occurrence of
> > f is in package p, then it is the case that trying to
> > qualify by writing
> > 
> >        a := p.f (x);
> > 
> > is not just unnecessary, but in fact illegal.
> 
> If I understand your example correctly, it reflects a problem
> which I recently had to fix in program written by someone else.
> We had the requirement not to use use and so the call of f had
> to be qualified as in your example above. The compiler complained
> about this of course and can you imagine what the programmer did
> in order to fix the problem? The type of x (B_Type) was derived from
> some other type (let's say A_Type). So the programmer wrote:
> 
>        a := p.f (p.A_Type(x));
> 

Silliness is indeed unbounded. The person requiring qualification of
of the call of f should have been sent to purgatory immediately.

The programmer should have declined to do this and explain the reason
why.

> The compiler was happy and in this particular case the program
> even did what it was assumed to do. The hidden bug in this
> statement is a maintenance time-bomb which would not have occurred
> if use had been used.

But I do not see how "use" comes into the picture here.

> Michael

Re: Refactoring and Ada

[Dr. Michael Paus]

Christoph Grein wrote:
> 
> > > I often find that people think that avoiding use clauses
> > > avoids this, and requires full qualification. In fact in
> > > the above example, suppose the only other occurrence of
> > > f is in package p, then it is the case that trying to
> > > qualify by writing
> > >
> > >        a := p.f (x);
> > >
> > > is not just unnecessary, but in fact illegal.
> >
> > If I understand your example correctly, it reflects a problem
> > which I recently had to fix in program written by someone else.
> > We had the requirement not to use use and so the call of f had
> > to be qualified as in your example above. The compiler complained
> > about this of course and can you imagine what the programmer did
> > in order to fix the problem? The type of x (B_Type) was derived from
> > some other type (let's say A_Type). So the programmer wrote:
> >
> >        a := p.f (p.A_Type(x));
> >
> 
> Silliness is indeed unbounded. The person requiring qualification of
> of the call of f should have been sent to purgatory immediately.
> 
> The programmer should have declined to do this and explain the reason
> why.
> 
> > The compiler was happy and in this particular case the program
> > even did what it was assumed to do. The hidden bug in this
> > statement is a maintenance time-bomb which would not have occurred
> > if use had been used.
> 
> But I do not see how "use" comes into the picture here.

Quite simple. When use clauses are allowed to be used, then the programmer
would have used the package where the type of x is defined and then he
would have just written:

          a := f(x);

In this case the compiler would choose the right package and function
compatibel with x. It was the false attempt to qualify the call of f
which lead to the described problem. And the first mistake was cured
by an even bigger mistake (the type cast).

I personally do not like qualification of primitive operations anyway.
If I access an element s of a tagged type B_Type (as in the example before)
defined in a package G, I write
      declare
         x : G.B_Type;
      begin
         a := x.s;
      end;
and nobody would feal that there is any need for more qualification and
so I do not see why it should then be usefull to qualify a call to a
primitive operation. If Ada had adopted the C++ or Java notation in this
case the function call would be written as
         a := x.f;
and just because you have to write
         a := f(x);
in Ada95 does not justify a qualification. If I really want to know where
this function is defined it is sufficient to look at the declaration of x so
that you know where the type is defined and you have to go on and search
for the place where the parent type of B_Type is defined because in case
of an inherited function it is not physically located in the package that
you have to use for the qualification.

But of course like everything this is a matter of taste and I do not want
to start another flame war on the use of use.

Michael

Re: Refactoring and Ada

[Robert Dewar]

"Dr. Michael Paus" <paus@ib-paus.com> wrote in message news:<3C62C7EC.4ACBC1@ib-paus.com>...
> If I really want to know where this function is defined 
> it is sufficient to look at the declaration of x so
> that you know where the type is defined and you have to
> go on and search for the place where the parent type of 
> B_Type is defined because in case of an inherited 
> function it is not physically located in the package that 
> you have to use for the qualification.

I trust that your tools short circuit the process you
describe above and allow you to easily get from the occurrence to the
declaration (it seems to me that such
tools are really very useful indeed in large Ada programs).
I know that in the past some Ada systems have not had this
capability (and indeed the painful nature of searching for
declarations in such systems is part--but certainly not 
all-- of the reason for the odd use-allergy that strikes 
many Ada programmers), but these days I think most Ada
systems DO have that capability,

Re: Refactoring and Ada

[Dr. Michael Paus]

Robert Dewar schrieb:
> 
> "Dr. Michael Paus" <paus@ib-paus.com> wrote in message news:<3C62C7EC.4ACBC1@ib-paus.com>...
> > If I really want to know where this function is defined
> > it is sufficient to look at the declaration of x so
> > that you know where the type is defined and you have to
> > go on and search for the place where the parent type of
> > B_Type is defined because in case of an inherited
> > function it is not physically located in the package that
> > you have to use for the qualification.
> 
> I trust that your tools short circuit the process you
> describe above and allow you to easily get from the occurrence to the
> declaration (it seems to me that such
> tools are really very useful indeed in large Ada programs).
> I know that in the past some Ada systems have not had this
> capability (and indeed the painful nature of searching for
> declarations in such systems is part--but certainly not
> all-- of the reason for the odd use-allergy that strikes
> many Ada programmers), but these days I think most Ada
> systems DO have that capability,

Well, even if you do not have a powerful IDE, gnathtml is
for free and gives you most of the support you need here.

Michael

Re: Refactoring and Ada

[Christoph Grein]

> > It turns out that 'Valid is not as useful as many of us thought it was. For
> > example,  the result of an erroneous result from unchecked conversion,
> > which we originally thought was harmless if we checked it ourselves
> > with 'Valid before using it is a problem.   Consider the following,
> > 
> >                type X is ... ;
> >                type Y is ... ;
> > 
> >                function Convert is new Ada.Unchecked_Conversion
> >                                          (Source => Y, Target => X);
> > 
> >                 X := Convert (Y);     -- suppose X is erroneous or not valid
> >                 if X'Valid then ...      -- We used to think this was OK.
> >                                                  -- Some compilers fail on 
this because of an
> > interpretation
> >                                                  -- of the ALRM rules.
> > 
> >  At present, one must wonder about the usefulness of 'Valid.
> 
> There is an AI with a binding interpretation that was included in the
> TC that says that at least for scalar types the above code is
> not errorious and must work as expected.
> 
> SO any compiler that fail on the above are non-compliant.

I've got  the AARM with COR.1:2000 in front of me. There are no changes in 13.9, 
13.9.1, 13.9.2.
Thus a compiler failing to handle the above correctly has always been buggy.

Note that 'Valid exists for scalar objects only.