Function Calls by Address

Function Calls by Address

[Craig Jameson]

Does any one know how to make dynamic function calls in Ada83.
I am writing an application using AIX Motif bindings and I 
need to create a dynamic list of functions to be called when
a particular X event is dispatched.  Any ideas on how to 
create and use such a list?  

Thanks, 
Craig Jameson


-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
  Craig Jameson				LOCKHEED MARTIN CORPORATION  
  Senior Software Engineer		Mail Point 823  Cube 754
  Phone : (407)306-3209			12506 Lake Underhill Dr      
  FAX   : (407)306-6973		 	Orlando  FL 32825-5002
  mailto:craigj@escmail.orl.lmco.com	
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Re: Function Calls by Address

[Marin David Condic]

Craig Jameson wrote:

> Does any one know how to make dynamic function calls in Ada83.
> I am writing an application using AIX Motif bindings and I
> need to create a dynamic list of functions to be called when
> a particular X event is dispatched.  Any ideas on how to
> create and use such a list?

If I understand what you are trying to do, I think you want to use
access-to-subprogram types.(See ARM 3.10) This would let you define a
type that lets you get a pointer to a function or procedure matching a
certain calling profile. From there, you'd create your table of
functions to call and fill it with the access values to the functions
you wanted & null otherwise.

Sounds like it could get messy, but I think the reason for allowing
access types to subprograms was specifically for interfacing to
subsystems that want to do callbacks. If that's what you're trying to do
then this is probably the place to start looking.

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

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

Re: Function Calls by Address

[Robert Dewar]

In article <37CADE68.6AF06F5D@escmail.orl.lmco.com>,
  Craig Jameson <craigj@escmail.orl.lmco.com> wrote:
> Does any one know how to make dynamic function calls in Ada83.
> I am writing an application using AIX Motif bindings and I
> need to create a dynamic list of functions to be called when
> a particular X event is dispatched.  Any ideas on how to
> create and use such a list?

There is no way to do this in Ada 83. A given Ada 83 compiler
may have some implementation dependent kludge, e.g. the
pragma Import with address clause trick. Contact your vendor
here, this is not a language question! At the very least you
have to say exactly what compiler you are using on what machine,
and of course it should be noted that in Ada 95, the solution
is straightforward.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Robert Dewar]

In article <37CADE68.6AF06F5D@escmail.orl.lmco.com>,
  Craig Jameson <craigj@escmail.orl.lmco.com> wrote:
> Does any one know how to make dynamic function calls in Ada83.
> I am writing an application using AIX Motif bindings and I
> need to create a dynamic list of functions to be called when
> a particular X event is dispatched.  Any ideas on how to
> create and use such a list?

There is no way to do this in Ada 83. A given Ada 83 compiler
may have some implementation dependent kludge, e.g. the
pragma Import with address clause trick. Contact your vendor
here, this is not a language question! At the very least you
have to say exactly what compiler you are using on what machine,
and of course it should be noted that in Ada 95, the solution
is straightforward.

Robert Dewar
Ada Core Technologies


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Robert Dewar]

In article <37CAEA5C.11A23940@pwfl.com>,
  e108678@pwflcom wrote:
> Craig Jameson wrote:
>
> > Does any one know how to make dynamic function calls in
Ada83.
> > I am writing an application using AIX Motif bindings and I
> > need to create a dynamic list of functions to be called when
> > a particular X event is dispatched.  Any ideas on how to
> > create and use such a list?
>
> If I understand what you are trying to do

OOPS, you don't understand :-) :-)
You missed the all important digits 83 in the above message!

Indeed in Ada 95 it is straightforward, nothing messy about
it (despite your concern), but in Ada 83, there is no solution.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Marin David Condic]

Marin David Condic wrote:

> Craig Jameson wrote:
>
> > Does any one know how to make dynamic function calls in Ada83.

Ooops! I just noticed that you said Ada83. There is no easy way to do this
in Ada83. If you look in LRM 13.5, 13.7 and 13.7.2, you will note that there
is a way to get at the address to a subprogram. Jumping to that address is
likely something you'll have to do with machine instructions or other
implementation dependent ways because I don't think the Ada83 standard ever
specified a standardized way to use the address as a call or goto. If you're
handing off the address to a subsystem that wants to do callbacks, this will
also be very system dependent. Getting the parameter lists correct is
something with which you are entirely on your own. The thing you will need
to look at carefully is your compiler vendor's documentation to see how they
suggest using it. (If you post the compiler/target combo, someone may have
done this already.)

If you can get the 'Address to a subprogram and can figure out how to jump
to that address within the system you're in, it should be relatively easy to
dynamically build a list of the addresses you're interested in and jumping
to them.

An Ada feature that I think is underutilized is the ability to do machine
instruction insertions so that you can do the things normal programming
languages try to stop because they are unsafe or difficult to support. You
might look into machine code insertions as a solution to your problem.
Between the 'Address attribute and a little assembler code you ought to be
able to cobble together a nice isolated chunk of code that lets you do what
you want.

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

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

Re: Function Calls by Address

[Larry Kilgallen]

In article <37CAEF6C.197AA467@pwfl.com>, Marin David Condic <condicma@bogon.pwfl.com> writes:
> Marin David Condic wrote:
> 
>> Craig Jameson wrote:
>>
>> > Does any one know how to make dynamic function calls in Ada83.
> 
> Ooops! I just noticed that you said Ada83. There is no easy way to do this
> in Ada83.

> If you can get the 'Address to a subprogram and can figure out how to jump
> to that address within the system you're in, it should be relatively easy to
> dynamically build a list of the addresses you're interested in and jumping
> to them.

I thought the real problem described was X-windows callbacks,
in which case the Ada program does not have to do the jumping,
just supply the address.  Typically one cannot deal with X-windows
from Ada without a binding to the various X libraries, and those
who wrote the binding will typically have worked out how to feed
the X-windows system on the machine in question.  For DEC Ada on
VMS there are lots of lovely comments in the binding source that
explain the scheme.

Larry Kilgallen

Re: Function Calls by Address

[David Kristola]

In article 6AF06F5D@escmail.orl.lmco.com, Craig Jameson <craigj@escmail.orl.lmco.com> () writes:
>Does any one know how to make dynamic function calls in Ada83.
>I am writing an application using AIX Motif bindings and I 
>need to create a dynamic list of functions to be called when
>a particular X event is dispatched.  Any ideas on how to 
>create and use such a list?  

Many years ago, when i was involved with an Ada83 tool that
had an X Windows interface, we used C wrappers to call the
Ada routines, and passed pointers to the C wrappers to the
callback engine.

More recently, in an embedded system, we used machine code
to branch to a supplied address, and used 'ADDRESS of the
parameterless procedures to set up the callback routines.
This worked in our particular environment (exceptions even
propagated correctly through the indirect subroutine call),
but we had to insure this on our own, since we were going
well outside the definition of the language.



--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Spam: goto.hades@welovespam.com

Re: Function Calls by Address

[Martin Gangkofer]

In article <7qf2mi$g4h$1@nnrp1.deja.com>,
  Robert Dewar <dewar@gnat.com> wrote:
> In article <37CADE68.6AF06F5D@escmail.orl.lmco.com>,
>   Craig Jameson <craigj@escmail.orl.lmco.com> wrote:
> > Does any one know how to make dynamic function calls in Ada83.
> > I am writing an application using AIX Motif bindings and I
> > need to create a dynamic list of functions to be called when
> > a particular X event is dispatched.  Any ideas on how to
> > create and use such a list?
>
> There is no way to do this in Ada 83. A given Ada 83 compiler
> may have some implementation dependent kludge, e.g. the
> pragma Import with address clause trick. Contact your vendor
> here, this is not a language question! At the very least you
> have to say exactly what compiler you are using on what machine,
> and of course it should be noted that in Ada 95, the solution
> is straightforward.
>
> Robert Dewar
> Ada Core Technologies
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>

I think it is wrong to state, that it is impossible even if you plan to
implement callbacks by dynamic procedure call.

The term 'dynamic' is - due to the finite nature of computers we are
working with - only another word for 'unknown static set'. The original
posting already indicates, that some procedure from within a list shall
be called. I suppose, that this list is a known list.

Well, the usual way to handle this kind of problems in Ada.83 is to
replace machine addressing by generation of an abstract addressing
space, i.e. some discrete type together with a an operation selecting
the correct call from a value of this type.
If the task of writing such code apears to huge for you use a database
and some source code generating scripts (e.g. perl).

MtG
--
Martin Gangkofer, System Engineer
ESG Elektroniksystem und -Logistik GmbH, Dept.EF-E
eMail: mgangkof@esg-gmbh.de
Tel:   +49 89 9216 2176


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Matthew Heaney]

In article <37CADE68.6AF06F5D@escmail.orl.lmco.com> , Craig Jameson 
<craigj@escmail.orl.lmco.com>  wrote:

> Does any one know how to make dynamic function calls in Ada83.
> I am writing an application using AIX Motif bindings and I
> need to create a dynamic list of functions to be called when
> a particular X event is dispatched.  Any ideas on how to
> create and use such a list?

We always used to use 'Address.  For example:

package P is

  procedure CB
    (W           : Widget;
     Client_Data : Addr_T;
     Call_Data   : Addr_T);

  pragma Interface (C, CB);
  pragma Interface_Name (CB, "pcb");

  pragma Export (CB, Name => "pcb");

(Or something like that.  You might not even need the pragma Export, because
you're referring to the subprogram by its address, not its name.  But I
don't remember.  Look in the vendor's compiler manuals about being able to
call Ada subprograms from another language.)

You can then say CB'Address, which you pass to the C side.

Make the subprogram is at library-level (though the compiler will probably
tell if it isn't).

Yes, this is vendor-specific, but I did X/Motif stuff in Ada83 for many
years (on VMS and SUN boxes), and never had a problem.

As others have pointed out, support for callbacks was added to the language
for Ada95.  The current debate is over support for some form of downward
closures.

Re: Function Calls by Address

[Simon Wright]

Craig Jameson <craigj@escmail.orl.lmco.com> writes:

> Does any one know how to make dynamic function calls in Ada83.
> I am writing an application using AIX Motif bindings and I 
> need to create a dynamic list of functions to be called when
> a particular X event is dispatched.  Any ideas on how to 
> create and use such a list?  

Craig,

I would have expected you to use the Xt functions for this; see
XtAddCallback(), XtRemoveCallback(). They should be in your
bindings. You can add several callbacks for the same event to the same
widget. I expect you can remove them as you please, too, but I haven't
tried this.

Re: Function Calls by Address

[Francois Godme]

Craig Jameson wrote:

> Does any one know how to make dynamic function calls in Ada83.
> I am writing an application using AIX Motif bindings and I
> need to create a dynamic list of functions to be called when
> a particular X event is dispatched.  Any ideas on how to
> create and use such a list?
>
> Thanks,
> Craig Jameson
>
> --
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   Craig Jameson                         LOCKHEED MARTIN CORPORATION
>   Senior Software Engineer              Mail Point 823  Cube 754
>   Phone : (407)306-3209                 12506 Lake Underhill Dr
>   FAX   : (407)306-6973                 Orlando  FL 32825-5002
>   mailto:craigj@escmail.orl.lmco.com
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Loop around a small C language stub that calls a function passed from
Ada.

Easy, next one :)

Francois Godme

Re: Function Calls by Address

[Robert Dewar]

In article <37CEEFFA.7D73F78D@magic.fr>,
  Francois Godme <fgodme@magic.fr> wrote:

> Loop around a small C language stub that calls a function
> passed from Ada.
>
> Easy, next one :)
>
> Francois Godme


Not so fast! I assume you mean to use 'Address here. This may
work on some implementations, but there is no guarantee that
it will work, and it definitely will NOT work on some
implementations where the Address of a procedure is not a
full context, and it typically will NOT work for nested
procedures with uplevel references.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Francois Godme]

Robert Dewar wrote:

> In article <37CEEFFA.7D73F78D@magic.fr>,
>   Francois Godme <fgodme@magic.fr> wrote:
>
> > Loop around a small C language stub that calls a function
> > passed from Ada.
> >
> > Easy, next one :)
> >
> > Francois Godme
>
> Not so fast! I assume you mean to use 'Address here. This may
> work on some implementations, but there is no guarantee that
> it will work, and it definitely will NOT work on some
> implementations where the Address of a procedure is not a
> full context, and it typically will NOT work for nested
> procedures with uplevel references.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

Yes, it will not work everywhere and not for nested procedures.

I knew about the nested procedures restriction but thought that no one
still uses nested procedures. Personally, I have stopped using them. Why
will I hide a perfectly useful procedure inside another when all I want
is to spare me rewriting over and over the same thing. Are nested
procedures coming from the Pascal heritage where everything was residing
inside the main program? By the same matter, who is still using the
'separate' construct for writing new applications?

Francois Godme

Re: Function Calls by Address

[Robert Dewar]

In article <37CFFEA6.921CBE59@magic.fr>,
  Francois Godme <fgodme@magic.fr> wrote:
> I knew about the nested procedures restriction but thought
> that no one still uses nested procedures.

An amazingly narrow thought. It is true that people who don't
have them (who use languages starting with the letter C) don't
use them, but then COBOL programmers don't use dynamic
allocation :-)

> Personally, I have  stopped using them. Wh will I hide a
> perfectly useful procedure inside another when all I want
> is to spare me rewriting over and over the same thing.

If you think this is all procedures are good for, you are
missing a lot! I usually tell my students that if they see
a large program which does NOT have cases of procedures that
are called only once, it is likely that the design is
incompetent!

> Are nested
> procedures coming from the Pascal heritage where everything
> was residing
> inside the main program?

No, not at all, and if you ask the question, then it means,
as above, that you are missing a lot!

Nested procedures are used when solution of a problem requires
functional decomposition on a local level, and the resulting
procedures that come from that functional decomposition are
relevant only locally, so you do not want to pollute name
spaces. Furthermore, non-local references are a powerful
mechanism for many purposes.

In particular, the lack of thread safety of many run-time
routines in the C library can be ascribed to the excessive use
of global variables that would much better be local variables
referenced non-locally where necessary.

Nested procedures are a very powerful feature of Ada. If you
have stopped using them, you probably never fully understood
how to make good use of this feature.

> By the same matter, who is still using the
> 'separate' construct for writing new applications?

Anyone who understands the power of this capability. It is quite
true that Ada 95 replaces SOME of the need for subunits by
child units, but only some.

During the design of the modules extension for Algol-68 (done
by Hendrick Boom, Charles Lindsey, and Robert Dewar) we
furiously tried to unify the notions of top down and bottom
up decomposition, and finally decided that it was simply not
cleanly possible. That is why the final proposal includes two
separate but related facility.

This is one area where the Ada design drew directly from
the Algol-68 work, so in some sense this Algol-68 design
was the genesis for the subunit notion.

If you never use subunits, then again, you probably have not
fully understood the power of this feature.

Not everyone has to use everything, and indeed it is often the
case that you simply don't learn everything, and manage to live
without things you have not learned.

But don't make the jump of thinking that because you don't see
that particular features are useful, they must be useless. It
is more likely that you are missing something. There was a
pretty fierce attempt to remove all useless features from
both Ada 83 and Ada 95, so if something exists in the design,
it means there was a strong constituency with good arguments for
its inclusion. So if you don't know any good arguments in favor
of a given feature, it does not mean they don't exist, it just
means you are not familiar enough with the particular feature.

Robert Dewar


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Ted Dennison]

In article <7qp8sd$u8i$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <37CFFEA6.921CBE59@magic.fr>,
>   Francois Godme <fgodme@magic.fr> wrote:
> > By the same matter, who is still using the
> > 'separate' construct for writing new applications?
>
> Anyone who understands the power of this capability. It is quite
> true that Ada 95 replaces SOME of the need for subunits by
> child units, but only some.

I'll agree that Francois might have gone a bit overboard. But I must
confess I'm one who never has understood the "power" of separates
either. As near as I can tell, its only power is the ability to split up
cumbersome files into smaller files without having to go through the
pain of properly reencapsulating functionality into new packages. Does
it have other "powers" that I'm missing?

As powers go, I don't think that's enough to gain admittance to the
software engineering Hall of Justice. Perhaps it could be in Mystery
Men, if Invisible Boy gets the flu or something...

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[David C. Hoos, Sr.]

Francois Godme <fgodme@magic.fr> wrote in message
news:37CFFEA6.921CBE59@magic.fr...
> Robert Dewar wrote:
>
> > In article <37CEEFFA.7D73F78D@magic.fr>,
> >   Francois Godme <fgodme@magic.fr> wrote:
> >
<snip>
> I knew about the nested procedures restriction but thought that no one
> still uses nested procedures. Personally, I have stopped using them. Why
> will I hide a perfectly useful procedure inside another when all I want
> is to spare me rewriting over and over the same thing. Are nested
> procedures coming from the Pascal heritage where everything was residing
> inside the main program? By the same matter, who is still using the
> 'separate' construct for writing new applications?

Well... sometimes it's handy to have a procedure that would use a number of
parameters that are just locally declared variables within the caller.
Nesting the procedure saves calling overhead, because being nested it can
be parameterless.

As far as separates go.. it's frequently wise to use separates for target-
dependent code.  I also use them to keep down the size of package body
files -- e.g., for procedures that have long case constructs, or whatever.

Re: Function Calls by Address

[Marin David Condic]

Francois Godme wrote:

> I knew about the nested procedures restriction but thought that no one
> still uses nested procedures. Personally, I have stopped using them. Why
> will I hide a perfectly useful procedure inside another when all I want
> is to spare me rewriting over and over the same thing. Are nested
> procedures coming from the Pascal heritage where everything was residing
> inside the main program? By the same matter, who is still using the
> 'separate' construct for writing new applications?

I think that the use of child units contributes a lot to better overall
code. If nothing else, it helps with configuration management and change
control issues by better isolating where changes occur.

I never liked the "is separate" and I'm not sure I could tell you why. I
wasn't fond of inheriting such a large context which was not immediately
visible in the code I was editing. I didn't like the fact that recompiling
the parent package would cause recompilation of all the separate units
because you effectively hit their specs.

That being said, there are still lots of handy reasons for using nested
procedures. Sometimes you have a small chunk of code which is repeated
frequently, but has no logical cohesion or identifiable function. The nested
procedure shortens up the code without creating an essentially purposeless
separate unit. Often the nesting of statements can be simplified by breaking
up the code into nested procedures. I agree that if a unit is getting into
thousands of lines of code due to nesting procedures, it is likely to be a
bad thing, but you don't want to throw out a very handy language feature
just because excessive use can happen.

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

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

Re: Function Calls by Address

[Simon Wright]

Francois Godme <fgodme@magic.fr> writes:

>                          By the same matter, who is still using the
> 'separate' construct for writing new applications?

We use this; there is a code generator, one part creates the
"structure" -- the packages and some of the bodies -- which is fairly
stable; the other creates the "active" part, which is more volatile
and which is implemented in 'separate' subprograms.

I have certainly used 'separate' in a different context (a nested
package, or perhaps it was a protected body. Anyway, it was again a
question of relative stability.

-- 
Simon Wright                        Work Email: simon.j.wright@gecm.com
Alenia Marconi Systems                         Voice: +44(0)1705-701778
Integrated Systems Division                      FAX: +44(0)1705-701800

Re: Function Calls by Address

[Robert Dewar]

In article <7qp5oo$2un@hobbes.crc.com>,
  "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
> As far as separates go.. it's frequently wise to use separates
for target-
> dependent code.  I also use them to keep down the size of
package body
> files -- e.g., for procedures that have long case constructs,
or whatever.


This is indeed a useful application. Have a look at the files
??emstop.adb in the GNAT sources as an example ...



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Mario Klebsch]

Francois Godme <fgodme@magic.fr> writes:
>I knew about the nested procedures restriction but thought that no one
>still uses nested procedures. Personally, I have stopped using them. Why
>will I hide a perfectly useful procedure inside another when all I want
>is to spare me rewriting over and over the same thing.

Althoug I do not program in Ada (yet), I really like nested procedures.
I learned to use them in PASCAL, and a few Years ago, when I did a Project
in Modula II, i was able to use them, again.

The Idea behind them is, to make everything as local as possible,
w.g. to avoid namespace pollution.

ANd there are a lot of nice things, you only can to that elegant with
nested procedures. Nested procedures have full access to all local
variables of the enclosing procedures. If you want to do it in C, you
have to use static variables and will loose reentrancy.

73, Mario
-- 
Mario Klebsch						mario@klebsch.de

Re: Function Calls by Address

[Brian Rogoff]

On Fri, 3 Sep 1999, Robert Dewar wrote:
> In article <37CFFEA6.921CBE59@magic.fr>,
>   Francois Godme <fgodme@magic.fr> wrote:
> > I knew about the nested procedures restriction but thought
> > that no one still uses nested procedures.
> 
> An amazingly narrow thought. It is true that people who don't
> have them (who use languages starting with the letter C) don't

As a sometime Caml programmer, I assure you that we have them, and that 
they are even more powerful there than in Ada, since we can pass them 
down and even up. Be careful about branding all of us who use languages 
with names beginning with a "C". I hope the Common Lisp and Component 
Pascal folks aren't offended either :-)

-- Brian

Re: Function Calls by Address

[Jean-Pierre Rosen]

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


Ted Dennison <dennison@telepath.com> a �crit dans le message :
7qpd5b$1gg$1@nnrp1.deja.com...
> I'll agree that Francois might have gone a bit overboard. But I must
> confess I'm one who never has understood the "power" of separates
> either. As near as I can tell, its only power is the ability to split up
> cumbersome files into smaller files without having to go through the
> pain of properly reencapsulating functionality into new packages. Does
> it have other "powers" that I'm missing?
>
Pluggable modules. You can write a big library that needs some
functionnality to be adjusted (depending on the OS, or whatever). If the
functionnality is provided as a "separate", you can change it without even
looking into the (big, complicated) library. On some systems, you would'nt
even need to provide the source of the library, so a customer could provide
it's own version, without being able to see your (proprietary) big library.

Why not use a (child) package for that ? If the separate module needs to
access global data from the package body. Note that if you are clever
enough, you won't expose what the separate procedure needs not to see:

package body pack is
    -- data visible to the separate proc goes here
   procedure to_be_adjusted is separate;

   -- data not visible to the separate proc goes here
  ...
end pack;

If you use a child package, then the "data visible" must be put in the
private part of the parent, which may have other drawbacks.

In short: there is certainly no definitive "best solution". The best
recommendation is: "know the tools that are available, know their drawbacks
and benefits, and choose the most appropriate for the task at hand on a case
by case basis".

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

Re: Function Calls by Address

[Robert Dewar]

In article > As a sometime Caml programmer, I assure you that we
have them, and that
> they are even more powerful there than in Ada, since we can
pass them
> down and even up. Be careful about branding all of us who use
languages
> with names beginning with a "C". I hope the Common Lisp and
Component
> Pascal folks aren't offended either :-)

Chuckle, chuckle :-)
To that list we should of course add COBOL, which indeed has
nested procedures :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Robert Dewar]

In article > As a sometime Caml programmer, I assure you that we
have them, and that
> they are even more powerful there than in Ada, since we can
pass them
> down and even up. Be careful about branding all of us who use
languages
> with names beginning with a "C". I hope the Common Lisp and
Component
> Pascal folks aren't offended either :-)

Chuckle, chuckle :-)
To that list we should of course add COBOL, which indeed has
nested procedures :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Robert Dewar]

In article > As a sometime Caml programmer, I assure you that we
have them, and that
> they are even more powerful there than in Ada, since we can
pass them
> down and even up. Be careful about branding all of us who use
languages
> with names beginning with a "C". I hope the Common Lisp and
Component
> Pascal folks aren't offended either :-)

Chuckle, chuckle :-)
To that list we should of course add COBOL, which indeed has
nested procedures :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Robert Dewar]

In article <ar3rq7.7qb.ln@ds9.klebsch.de>,
  mario@klebsch.de (Mario Klebsch) wrote:
> ANd there are a lot of nice things, you only can to that
elegant with
> nested procedures. Nested procedures have full access to all
local
> variables of the enclosing procedures. If you want to do it in
C, you
> have to use static variables and will loose reentrancy.


Right Mario, this is a VERY important point. It is often
the reason for C library routines being non-thread safe.
Unfortunately the fix in these C library routines is
often to add locks to protect these unnecessary global
variables.

As an example, suppose you are writing printf. Well you
certainly do not want to write this as one giant function,
so you write it as multiple functions. Now you *should*
pass around all global variables, such as the buffer into
which characters are being written, but it is awfully tempting
to make this a global variable, with the result that you lose
thread safety. In Ada, you would write printf with nested
subprograms that accessed the buffer pointer as a non-local
uplevel reference (but the variable would be local to printf
itself).

With regard to name space pollution, it is more than just this.
The point is that if you see a nested procedure, you know
immediately that you only have to understand it in the context
of its enclosing procedure, and indeed if you can ignore this
code in the reading you are doing right now, you can immediately
and easily ignore all the nested procedures, knowing that you
have not missed anything.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Matthew Heaney]

In article <7qt4dv$fp7$1@wanadoo.fr> , "Jean-Pierre Rosen" 
<rosen.adalog@wanadoo.fr> wrote:

> If you use a child package, then the "data visible" must be put in the
> private part of the parent, which may have other drawbacks.

I doesn't have to go in the private part of the parent's spec.  It could
almost as easily go in an public part of a private child.  The private child
could be with'd by whichever module needs access to the data.

> In short: there is certainly no definitive "best solution". The best
> recommendation is: "know the tools that are available, know their drawbacks
> and benefits, and choose the most appropriate for the task at hand on a case
> by case basis".

Well said.  I lot of guys give themselves rules about features not to use,
but they are unwittingly reducing the size of the solution space.

--
Matt

It is impossible to feel great confidence in a negative theory which has
always rested its main support on the weak points of its opponent.

Joseph Needham, "A Mechanistic Criticism of Vitalism"

Re: Function Calls by Address

[Geoff Bull]

Francois Godme wrote:

> Yes, it will not work everywhere and not for nested procedures.
> 
> I knew about the nested procedures restriction but thought that no one
> still uses nested procedures. Personally, I have stopped using them. Why
> will I hide a perfectly useful procedure inside another when all I want
> is to spare me rewriting over and over the same thing.

I have been writing a lot of Java, and I really miss nested
procedures. I find there are places where nested procedures
are simply the natural thing to do.

Re: Function Calls by Address

[Francois Godme]

Robert Dewar wrote:

> In article <7qp5oo$2un@hobbes.crc.com>,
>   "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote:
> > As far as separates go.. it's frequently wise to use separates
> for target-
> > dependent code.  I also use them to keep down the size of
> package body
> > files -- e.g., for procedures that have long case constructs,
> or whatever.
>
> This is indeed a useful application. Have a look at the files
> ??emstop.adb in the GNAT sources as an example ...
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

Yes, back in the Ada83 days, this was a good use (you were almost
forced) but now, you can do it in better ways. One way would be to
define an abstract tagged type that abstracts what you want to do and to
implement several concrete subclasses of this abstraction, one for each
target. Only the main subprogram will know on which target it is running
and will pass down to the application the appropriate instance or the
appropriate factory to build instances.

With pragma Linker_Options carefully set, by "with"ing units from the
main to select the factories, you define, at the same time, the link
command.

This does not apply to compiler builders.

Re: Function Calls by Address

[Ehud Lamm]

On Sat, 4 Sep 1999, Jean-Pierre Rosen wrote:
|
|In short: there is certainly no definitive "best solution". The best
|recommendation is: "know the tools that are available, know their drawbacks
|and benefits, and choose the most appropriate for the task at hand on a case
|by case basis".
|

This is good advice. Knowing how to choose right is among the most
important qualities in any profession, esp. in SE.

But:

|Why not use a (child) package for that ? If the separate module needs to
|access global data from the package body. Note that if you are clever
|enough, you won't expose what the separate procedure needs not to see:
|
|package body pack is
|  -- data visible to the separate proc goes here
| procedure to_be_adjusted is separate;
|
| -- data not visible to the separate proc goes here
|...
|end pack;
|

I personally find this kind of idea problematic. This kind of thing is a
problem waiting to happen. Won't someone move lines arround, perhaps to
"tidy up" according to his coding style, thus breaking the code. 
Code that is dependent on exact order of declarations should be used only
when necessary and even than with great care. Of course if the relatedness
of the declarations is obvious the danger is lessened, but in this example
the connection may be subtle. 
I wouldn't go so far as to ban it - but I'd say "know how to choose," and
if you choose to do something like this, do your fellows a favour and
document!

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm  <== My home on the web

Re: Function Calls by Address

[Brian Rogoff]

On Mon, 6 Sep 1999, Francois Godme wrote:
> There are two kinds of nested procedures: the ones which do not make
> uplevel references and the others which do. You gain possible reuses by
> unnesting the former. 

I generally don't nest when there are no uplevel references.

> You gain clarity by rewritting the latter to avoid the uplevel references. 

I find it much clearer when subprograms have few arguments. I speak from
my experience here, as a C programmer :-). The ability to nest
subprograms is a very good thing, for all of the reasons mentioned, and 
because it leads to clearer programs. 

> All the hidden parameters as well as their
> passing modes are then shown. What was previously written has a function
> is now correctly expressed as a procedure if for example one uplevel
> reference was modified.

Correctness has nothing to do with it. Do you consider any side-effecting 
of global (package level) variables in a function incorrect?

-- Brian

Re: Function Calls by Address

[Francois Godme]

Robert Dewar wrote:

> In article <ar3rq7.7qb.ln@ds9.klebsch.de>,
>   mario@klebsch.de (Mario Klebsch) wrote:
> > ANd there are a lot of nice things, you only can to that
> elegant with
> > nested procedures. Nested procedures have full access to all
> local
> > variables of the enclosing procedures. If you want to do it in
> C, you
> > have to use static variables and will loose reentrancy.
>
> Right Mario, this is a VERY important point. It is often
> the reason for C library routines being non-thread safe.
> Unfortunately the fix in these C library routines is
> often to add locks to protect these unnecessary global
> variables.
>
> As an example, suppose you are writing printf. Well you
> certainly do not want to write this as one giant function,
> so you write it as multiple functions. Now you *should*
> pass around all global variables, such as the buffer into
> which characters are being written, but it is awfully tempting
> to make this a global variable, with the result that you lose
> thread safety. In Ada, you would write printf with nested
> subprograms that accessed the buffer pointer as a non-local
> uplevel reference (but the variable would be local to printf
> itself).
>
> With regard to name space pollution, it is more than just this.
> The point is that if you see a nested procedure, you know
> immediately that you only have to understand it in the context
> of its enclosing procedure, and indeed if you can ignore this
> code in the reading you are doing right now, you can immediately
> and easily ignore all the nested procedures, knowing that you
> have not missed anything.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

There are two kinds of nested procedures: the ones which do not make
uplevel references and the others which do. You gain possible reuses by
unnesting the former. You gain clarity by rewritting the latter to avoid
the uplevel references. All the hidden parameters as well as their
passing modes are then shown. What was previously written has a function
is now correctly expressed as a procedure if for example one uplevel
reference was modified.

Re: Function Calls by Address

[Robert Dewar]

In article <37D2E1A7.CAC3F923@magic.fr>,
  Francois Godme <fgodme@magic.fr> wrote:
> Yes, back in the Ada83 days, this was a good use (you were
almost
> forced) but now, you can do it in better ways. One way would
be to
> define an abstract tagged type that abstracts what you want to
do and to
> implement several concrete subclasses of this abstraction, one
for each
> target. Only the main subprogram will know on which target it
is running
> and will pass down to the application the appropriate instance
or the
> appropriate factory to build instances.


I am certain you did NOT follow the advice of the message to
which you are replying, and have a look at ??emstop.adb in
the GNAT sources. The above comments are really not relevant
to the use illustrated there.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Robert Dewar]

In article <37D2F41D.AE1C85F5@magic.fr>,
  Francois Godme <fgodme@magic.fr> wrote:
> There are two kinds of nested procedures: the ones which do
> not make
> uplevel references and the others which do. You gain possible
reuses by
> unnesting the former.

But if you are using procedures as top down refinements, you
do NOT want reuse .. you seem to think of procedures only
in the bottom up library context. That's just one use.
Decomposition by refinement is another important use, and
here locality is important, reuse is not.

> You gain clarity by rewritting the latter to avoid
> the uplevel references. All the hidden parameters as well as
their
> passing modes are then shown.

Once again, you are thinking in terms of procedures only in
the bottom up context. When you write a chunk of code say,
something like:

    if bla bla then
       dum-de-dum-dum ...

You do not sit around thinking, oh-my-gosh, the dum-de-dum-dum
code has naked references to surrounding context. I should make
it into a procedure which should have parameters to show all
the hidden parameters etc etc.

However, if you are following the notions of top down
refinement, you might well say to yourself

hmmm .. dum-de-dum-dum is a bit long and not really at the
same level of abstraction as the surrounding tests etc, the
code will be clearer if I abstract this into a nested procedure
which can be separated out, and give this procedure a nice name

There is no more reason to worry about passing the environment
to this refinement than there is to worry about passing it to
the naked dum-de-dum-dum code in the first place.

There is a whole dimension that you are missing here. I
recommend reading the rationale behind the Algol-68 modules
extension which goes into the need to have separate abstractions
for top down and bottom up programming in detail.

It is true that many programmers tend to think one way or the
other. For a while in the mid 80's it was fashionable to think
ONLY in terms of top down refinement. More recently I see a lot
of programmers who seem to think only bottom up.

The proper approach is to known and understand both approaches,
and to use the appropriate one.

It is definitely true that the programming language has an
effect here. COBOL, with its very light (much lighter than C
or Ada) syntax for local refinements, tends to encourage the
use of the top down approach. Languages like C which do not
allow nested procedures tend to discourage this style.

Ada is somewhere between, the syntax for local procedures is
a bit heavy, so people do not use them as freely as they do
in COBOL (example below), but on a slightly larger scale, they
are definitly put to good use, and the idea that eliminating
all up level references increases clarity of code is very much
mistaken.

The promised COBOL example ...

  Process-Balance.
    if Balance is negative
      perform Send-Bill
    else
      perform Record-Credit
    end if.

  Send-Bill.
    ...

  Record-Credit.
    ...

with a syntax this light for internal refinements, they tend
to be extensively used, one of the features I like best about
COBOL, and indeed COBOL programmers dislike nested if statements
(they are fully implemented Ada style in COBOL), on the grounds
that they are confusing :-) :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Francois Godme]

Robert Dewar wrote:

> In article <37D2E1A7.CAC3F923@magic.fr>,
>   Francois Godme <fgodme@magic.fr> wrote:
> > Yes, back in the Ada83 days, this was a good use (you were
> almost
> > forced) but now, you can do it in better ways. One way would
> be to
> > define an abstract tagged type that abstracts what you want to
> do and to
> > implement several concrete subclasses of this abstraction, one
> for each
> > target. Only the main subprogram will know on which target it
> is running
> > and will pass down to the application the appropriate instance
> or the
> > appropriate factory to build instances.
>
> I am certain you did NOT follow the advice of the message to
> which you are replying, and have a look at ??emstop.adb in
> the GNAT sources. The above comments are really not relevant
> to the use illustrated there.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

Robert, please can you be less enigmatic. I do not see why it is not
relevant.

Is it wrong to think that Machine_State_Operations gathered methods that
apply on a Machine_State, as its own name may imply? Is it wrong to
think that an abstract tagged type could fill the same purpose, if it
was allowed in this context?

By the way, it seems to me that your example only stands as a
justification for the use of the separate construct in a language subset
we don't write programs with, the subset of the Ada language allowed to
write the GNAT runtime.

Re: Function Calls by Address

[Robert Dewar]

In article <37D41767.CEB186F4@magic.fr>,
  Francois Godme <fgodme@magic.fr> wrote:
> Robert Dewar wrote:
>
> Robert, please can you be less enigmatic. I do not see why it
> is not relevant.
>
> Is it wrong to think that Machine_State_Operations gathered
methods that
> apply on a Machine_State, as its own name may imply? Is it
wrong to
> think that an abstract tagged type could fill the same
purpose, if it
> was allowed in this context?

The point of subunits is to encapsulate locally, whether tagged
types are used or not is an orthogonal issue. Personally I would
find the use of tagged types for this particular purpose to be
a case of clobbering a fly with a sledge hammer, I don't see
that it would add anything. But as I say, the issue is one of
encapsulation. This functionality is strictly local to the
body of ada-exceptions, and subunits capture this relationship
in a natural way.

> By the way, it seems to me that your example only stands as a
> justification for the use of the separate construct in a
language subset
> we don't write programs with, the subset of the Ada language
allowed to
> write the GNAT runtime.

Let me know where you learned of this subset. I have no
awareness of any such restrictions :-)

Certainly we are free to use tagged types if we want to in
the runtime, see for example the way the I/O routines are
programmed and the type File_Type is handled.

Robert Dewar


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Robert Dewar]

In article <37D41767.CEB186F4@magic.fr>,
  Francois Godme <fgodme@magic.fr> wrote:
> Is it wrong to think that Machine_State_Operations gathered
methods that
> apply on a Machine_State, as its own name may imply? Is it
wrong to
> think that an abstract tagged type could fill the same
purpose, if it
> was allowed in this context?


To make my previous reply a little clearer.

The issue here is one of modular structure, I do not see
what tagged types have to do with it. So let me address
the two issues separately:

1. Tagged types, why on earth would you use such a heavy
approach here. There is only one instance of machine operations
for a given port of GNAT, so using dispatching to get to these
routines is entirely gratuitous, as is type extension.

There is no point in using tagged types and polymorphism when
a perfectly straightforward abstract data type will do just
as well. For some reason, this simply fact seems to get
forgotten these days.

2. The discussion here is about modular structure. We have two
choices, either of which could be used with or without tagged
types.

We can either use a subunit, or a private child package. I
see the subunit as far neater, because it encapsulates the
functionality just to the package body, whereas the child is
a child of the spec. The child is thus at the same level as
the spec, and this seems to be a violation of abstraction,
not to mention that it results in the gratuitous addition
of an extra separately compiled unit (the useless package
spec).

SO, once again, I think that ??emstop is a very nice example
of how subunits can be used in a neat way, with minimal
syntactic overhead, to achieve exactly what is wanted.

Note that this is a case where the argument is based on
encapsulation alone. That was deliberate. You can of course
make far more convincing examples where the inheritance of
the surrouding environment is critical (ah, but then I forgot
you don't like nested environments :-)

Indeed subunits and nested procedures are quite related from
a structural point of view, in both cases, one of the powerful
features is the implicit inheritance of the surrounding
environment.

Robert Dewar


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Bob Collins]

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

> [Much useful and interesting stuff snipped.]

> SO, once again, I think that ??emstop is a very nice example
> of how subunits can be used in a neat way, with minimal
> syntactic overhead, to achieve exactly what is wanted.

> [More useful and interesting stuff snipped.]

Thwre is only one version of ??emstop.adb in my version of
GNAT 3.11p (MachTen), with null bodies for all the
subprograms. Can you post an example? I am interested in
ideas on handling different hardware configurations with
roughly the same basic set of compilation units.

-- 
Bob Collins     <mailto:b-collins@home.com>

Re: Function Calls by Address

[Michael F. Yoder]

Francois Godme wrote:
>By the same matter, who is still using the
> 'separate' construct for writing new applications?
> 
> Francois Godme

I agree with essentially all the other pro-subunit arguments that have
been posted, and I'd like to add two not yet adduced.

My primary use of 'separate' is to aid the "literate programming"
process: it greatly simplifies exposition with a literate programming
tool that has no macro facility.  (Those familiar with WEB et al. may be
surprised by this, but macros aren't needed for literate programming. 
Macros that go beyond trivial uses are unsafe, hard to debug, and hard
to modify, so this is a good thing IMO.)

Aside from this, I think the top-down, stepwise refinement method is
hard to beat for producing clean, correct programs efficiently.  (Newer
paradigms are not necessarily better paradigms.)  Bottom-up methods
often suffer from the St. Louis archway problem: you build the two
halves of the arch and find they are several feet apart at the top, then
resort to kludgery to fix things.  In the case of the archway, the
solution was fire hoses applied to produce differential thermal
expansion; this had the virtue of not leaving permanent scars, which
isn't always true for software fixups.

Lest this spin off an entirely new thread, I'll note that I more often
use alternating top-down and bottom-up coding than a pure top-down style
(and I sometimes temporarily paint myself into a corner as a result). 
But if I had to choose between doing one or the other strictly, I would
elect the top-down approach.

-- 
Michael F. Yoder

Unscientific man is beset by a deplorable desire to have been right.
The scientist is distinguished by a desire to *be* right. -- W.V. Quine

Re: Function Calls by Address

[Francois Godme]

Pascal Obry wrote:

> Just one more point. The dispatching facilities is usefull when you need
> to handle *differents objects* type with the same binary.

Suppose you have written an application for system X which uses two
features P and Q similar enough so that they can be abstracted. Now, you
want to port your application for system Y for which this feature is not
duplicated.

How do you do then?

Re: Function Calls by Address

[Pascal Obry]

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


Bob Collins <b-collins@home.com> a �crit dans le message :
b-collins-0609991935400001@192.168.0.10...
> In article <7r1cro$9pf$1@nnrp1.deja.com>, Robert Dewar
> <robert_dewar@my-deja.com> wrote:
>
> > [Much useful and interesting stuff snipped.]
>
> > SO, once again, I think that ??emstop is a very nice example
> > of how subunits can be used in a neat way, with minimal
> > syntactic overhead, to achieve exactly what is wanted.
>
> > [More useful and interesting stuff snipped.]
>
> Thwre is only one version of ??emstop.adb in my version of
> GNAT 3.11p (MachTen), with null bodies for all the
> subprograms. Can you post an example? I am interested in
> ideas on handling different hardware configurations with
> roughly the same basic set of compilation units.
>

You could download the GNAT sources for 3.11p.

Pascal.

Re: Function Calls by Address

[Pascal Obry]

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


Francois Godme <fgodme@magic.fr> a �crit dans le message :
37D41767.CEB186F4@magic.fr...
> Robert Dewar wrote:
>
>
> Robert, please can you be less enigmatic. I do not see why it is not
> relevant.
>

Just one more point. The dispatching facilities is usefull when you need
to handle *differents objects* type with the same binary. Here we are
talking
about GNAT runtime routines for one specific paltform. The dispatching
model will:

   - always call the same code anyway
   - makes GNAT slower
   - makes GNAT executable (the compiler executable) bigger

So I do not see why this could apply there...

Pascal.

Re: Function Calls by Address

[Francois Godme]

Pascal Obry wrote:

> Here we are
> talking
> about GNAT runtime routines for one specific paltform. The dispatching
> model will:
>
>    - always call the same code anyway
>    - makes GNAT slower
>    - makes GNAT executable (the compiler executable) bigger
>
> So I do not see why this could apply there...
>
> Pascal.

Suppose that you are writing the GNAT exception manager and that the frame
formats for the C language, the C++ language, the Ada95 language, etc. are
all different. Nevertheless, they are still frames and share some abstract
notions. As the GNAT runtime can be written in the full Ada95 language:),
you could write an abstract tagged type to represent frames. To unwind the
stack, you will call the abstract pop a frame method to force dispatching.

Now, if an application is made only of Ada code then the dispatching model
will:

    - always call the same code anyway,
    - ...
    - ...

Re: Function Calls by Address

[Georg Bauhaus]

Robert Dewar (robert_dewar@my-deja.com) wrote:

By the way, some literate programming systems provide nested
"somewhat separate" "procedures" for C programmers (prameterless,
though:)

int
process_balance(...)

  if (balance < 0) {
    <<send bill>>
  } else {
    <<record credit>>
  }
}
...
<<send a bill>>=
  ...
...
<<record credit>>=
 ...

(That's the noweb or CWEB way)

-# Georg

:   Process-Balance.
:     if Balance is negative
:       perform Send-Bill
:     else
:       perform Record-Credit
:     end if.

:   Send-Bill.
:     ...

:   Record-Credit.
:     ...

: with a syntax this light for internal refinements, they tend
: to be extensively used, one of the features I like best about
: COBOL, and indeed COBOL programmers dislike nested if statements
: (they are fully implemented Ada style in COBOL), on the grounds
: that they are confusing :-) :-)


: Sent via Deja.com http://www.deja.com/
: Share what you know. Learn what you don't.

Re: Function Calls by Address

[Robert I. Eachus]

Marin David Condic wrote:
 
> I think that the use of child units contributes a lot to better overall
> code. If nothing else, it helps with configuration management and change
> control issues by better isolating where changes occur.
> 
> I never liked the "is separate" and I'm not sure I could tell you why. I
> wasn't fond of inheriting such a large context which was not immediately
> visible in the code I was editing. I didn't like the fact that recompiling
> the parent package would cause recompilation of all the separate units
> because you effectively hit their specs...
 
    But that is looking at things upside down.  One of the most powerful
uses of subunits that a subunit can have a context clause.  This allows
you to migrate some or all of the context clauses from the library unit
or body down to the subunits.  Now recompiling that package spec will
only result in needing to recompile some of the subunits, not the
library unit body and all the subunits.

    But it is the semantic view of this, ignoring recompilation times
that makes subunits so powerful.  Instead of one monolithic body with
dozens of with clauses, you have a body and subunits with only a few
withs on each.

    Finally you can use subunits to write programs that cannot be easily
written without them.  The easiest way to see this is to imagine trying
to write a tool to remove subunits from a program.  It cannot be done
textually, and even with ASIS it would be a very difficult problem.
-- 

                                        Robert I. Eachus

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

Re: Function Calls by Address

[Robert A Duff]

"Robert I. Eachus" <eachus@mitre.org> writes:

>     The point is that, without context clauses on subunits, it is easy
> to syntactically remove all instances of the keyword separate from an
> Ada program.
> However, with the with clauses, not only do you have to do at least as
> much
> semantic analysis as is required to remove use clauses, but there are
> programs where you have to do significant restructuring to provide a
> legal elaboration
> order.  (You may also need to tell the compiler what that order is.) 
> This
> problem is, at a minimum NP hard, and it may in fact be impossible to
> determine
> if such an order exists.

You still haven't answered my question about what your imaginary tool is
supposed to transform the subunits into.  I'm guessing that you mean it
should insert the subunits in place of the stubs, and shuffle the
with_clauses around as necessary.  That is, you are not requiring that
the subunits still be separately compiled (ie transformed into child
units).

I don't understand the elaboration order issue.  The rules are that the
elaboration or is *exactly* as if you move all the with_clauses from the
subunits up to the containing library unit.  So that part is easy.

Of course, if you move with_clauses around, you need to do overload
resolution to figure out how to resolve any naming conflicts you've
introduced.  Yeah, that's kind of hard (but certainly no harder than
writing an Ada compiler).

But I *still* don't see how it proves that with_clauses on subunits are
useful or good.  I'm not disputing that they are useful or good -- I'm
just saying I don't see how the difficulty of this imaginary tool has
anything to do with it.  I mean, it's hard to parse C programs because
of the weird way typedefs work -- but that doesn't prove that the weird
way typedefs work is good.  In Ada, it's hard for the compiler to tell
the difference between "and" as an operator symbol, and "and" as a
normal string literal.  (That is, consider a tool that changed all
user-defined operators and their uses into identifier-named functions --
it would be hard to do in the general case.)  But that fact doesn't
prove there's some useful expressive power there -- in fact, in C++ it's
easy to find operator symbols lexically, and I would say that's one
thing about C++ that's *better* than Ada.

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

Re: Function Calls by Address

[Robert I. Eachus]

Robert A Duff wrote:
 
> I don't understand the elaboration order issue.  The rules are that the
> elaboration or is *exactly* as if you move all the with_clauses from the
> subunits up to the containing library unit.  So that part is easy.

     I finally see what you are talking about.  Subunits allow you to
create a program which will raise Program_Error or some other exception
at run-time.  Of course you can use pragma Suppress(Elaboration_Check)
to prevent this where you KNOW that the elaboration rules are too
conservative, but I don't recommend this.  Or you could complete all
your work before the main program is called...  However, in Ada there
are usually many legal compilation orders for such programs--if subunits
are used to minimize the number of with_clauses on any unit.

    Now assume you need to do maintenance on a program that is near the
edge, or more likely you are reusing such software.  If elaboration
checks were done at compile time, you would have a great deal of
difficulty making the changes.  (In other languages you could make the
changes, but with no assurance that the result would run correctly.) 
Almost any change would require recompiling everything.  The net result
would be that programs which do a lot of work during elaboration were
difficult to build and maintain.

    Using subunits can simplify this process greatly, and were often
used that way in Ada 83.  However, as Bob Duff points out, with child
units now available in Ada 95 there is no need to use subunits this
way.  Subunits still can be used to minimize the amount of code to be
recompiled, but compilers are getting faster, and private child units
can often accomplish the same effect.
 
-- 

                                        Robert I. Eachus

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

Re: Function Calls by Address

[Robert Dewar]

In article <wcc7lljb0yn.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> But I *still* don't see how it proves that with_clauses on
subunits are
> useful or good.  I'm not disputing that they are useful or
good -- I'm
> just saying I don't see how the difficulty of this imaginary
tool has
> anything to do with it.

I think you miss the point -- it is the other way round, if
there were a trivial conversion, then it would show that there
was no significant issue of expressive power. The fact that
there is no trivial conversion is *suggestive* of the fact that
there is some important issue of EP, but certainly not proof.
In fact, I strongly agree that this is a critical factor, and
I think the excercise of trying to think about the tool, as
you did in your msg, provides valuable clues as to why this
is so!


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Function Calls by Address

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> I think you miss the point -- it is the other way round, if
> there were a trivial conversion, then it would show that there
> was no significant issue of expressive power. The fact that
> there is no trivial conversion is *suggestive* of the fact that
> there is some important issue of EP, but certainly not proof.

Ah, now I see.  Thank you!

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