* Re: Function Calls by Address
1999-09-03 0:00 ` Francois Godme
@ 1999-09-03 0:00 ` Simon Wright
1999-09-03 0:00 ` Robert Dewar
` (5 subsequent siblings)
6 siblings, 0 replies; 50+ messages in thread
From: Simon Wright @ 1999-09-03 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Function Calls by Address
1999-09-03 0:00 ` Francois Godme
1999-09-03 0:00 ` Simon Wright
@ 1999-09-03 0:00 ` Robert Dewar
1999-09-03 0:00 ` Ted Dennison
1999-09-04 0:00 ` Brian Rogoff
1999-09-03 0:00 ` Marin David Condic
` (4 subsequent siblings)
6 siblings, 2 replies; 50+ messages in thread
From: Robert Dewar @ 1999-09-03 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Function Calls by Address
1999-09-03 0:00 ` Robert Dewar
@ 1999-09-03 0:00 ` Ted Dennison
1999-09-04 0:00 ` Jean-Pierre Rosen
1999-09-04 0:00 ` Brian Rogoff
1 sibling, 1 reply; 50+ messages in thread
From: Ted Dennison @ 1999-09-03 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-03 0:00 ` Ted Dennison
@ 1999-09-04 0:00 ` Jean-Pierre Rosen
1999-09-05 0:00 ` Matthew Heaney
1999-09-05 0:00 ` Ehud Lamm
0 siblings, 2 replies; 50+ messages in thread
From: Jean-Pierre Rosen @ 1999-09-04 0:00 UTC (permalink / raw)
[-- 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
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Function Calls by Address
1999-09-04 0:00 ` Jean-Pierre Rosen
@ 1999-09-05 0:00 ` Matthew Heaney
1999-09-05 0:00 ` Ehud Lamm
1 sibling, 0 replies; 50+ messages in thread
From: Matthew Heaney @ 1999-09-05 0:00 UTC (permalink / raw)
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"
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-04 0:00 ` Jean-Pierre Rosen
1999-09-05 0:00 ` Matthew Heaney
@ 1999-09-05 0:00 ` Ehud Lamm
1 sibling, 0 replies; 50+ messages in thread
From: Ehud Lamm @ 1999-09-05 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-03 0:00 ` Robert Dewar
1999-09-03 0:00 ` Ted Dennison
@ 1999-09-04 0:00 ` Brian Rogoff
1999-09-05 0:00 ` Robert Dewar
` (2 more replies)
1 sibling, 3 replies; 50+ messages in thread
From: Brian Rogoff @ 1999-09-04 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Function Calls by Address
1999-09-04 0:00 ` Brian Rogoff
@ 1999-09-05 0:00 ` Robert Dewar
1999-09-05 0:00 ` Robert Dewar
1999-09-05 0:00 ` Robert Dewar
2 siblings, 0 replies; 50+ messages in thread
From: Robert Dewar @ 1999-09-05 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-04 0:00 ` Brian Rogoff
1999-09-05 0:00 ` Robert Dewar
@ 1999-09-05 0:00 ` Robert Dewar
1999-09-05 0:00 ` Robert Dewar
2 siblings, 0 replies; 50+ messages in thread
From: Robert Dewar @ 1999-09-05 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-04 0:00 ` Brian Rogoff
1999-09-05 0:00 ` Robert Dewar
1999-09-05 0:00 ` Robert Dewar
@ 1999-09-05 0:00 ` Robert Dewar
2 siblings, 0 replies; 50+ messages in thread
From: Robert Dewar @ 1999-09-05 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-03 0:00 ` Francois Godme
1999-09-03 0:00 ` Simon Wright
1999-09-03 0:00 ` Robert Dewar
@ 1999-09-03 0:00 ` Marin David Condic
1999-09-14 0:00 ` Robert I. Eachus
1999-09-03 0:00 ` David C. Hoos, Sr.
` (3 subsequent siblings)
6 siblings, 1 reply; 50+ messages in thread
From: Marin David Condic @ 1999-09-03 0:00 UTC (permalink / raw)
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/
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Function Calls by Address
1999-09-03 0:00 ` Marin David Condic
@ 1999-09-14 0:00 ` Robert I. Eachus
[not found] ` <wcc3dwgb7ii.fsf@world.std.com>
0 siblings, 1 reply; 50+ messages in thread
From: Robert I. Eachus @ 1999-09-14 0:00 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-03 0:00 ` Francois Godme
` (2 preceding siblings ...)
1999-09-03 0:00 ` Marin David Condic
@ 1999-09-03 0:00 ` David C. Hoos, Sr.
1999-09-04 0:00 ` Robert Dewar
1999-09-04 0:00 ` Mario Klebsch
` (2 subsequent siblings)
6 siblings, 1 reply; 50+ messages in thread
From: David C. Hoos, Sr. @ 1999-09-03 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Function Calls by Address
1999-09-03 0:00 ` David C. Hoos, Sr.
@ 1999-09-04 0:00 ` Robert Dewar
1999-09-05 0:00 ` Francois Godme
0 siblings, 1 reply; 50+ messages in thread
From: Robert Dewar @ 1999-09-04 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-04 0:00 ` Robert Dewar
@ 1999-09-05 0:00 ` Francois Godme
1999-09-06 0:00 ` Robert Dewar
0 siblings, 1 reply; 50+ messages in thread
From: Francois Godme @ 1999-09-05 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-05 0:00 ` Francois Godme
@ 1999-09-06 0:00 ` Robert Dewar
1999-09-06 0:00 ` Francois Godme
0 siblings, 1 reply; 50+ messages in thread
From: Robert Dewar @ 1999-09-06 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-06 0:00 ` Robert Dewar
@ 1999-09-06 0:00 ` Francois Godme
1999-09-06 0:00 ` Robert Dewar
` (2 more replies)
0 siblings, 3 replies; 50+ messages in thread
From: Francois Godme @ 1999-09-06 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Function Calls by Address
1999-09-06 0:00 ` Francois Godme
@ 1999-09-06 0:00 ` Robert Dewar
1999-09-06 0:00 ` Bob Collins
1999-09-06 0:00 ` Robert Dewar
1999-09-07 0:00 ` Pascal Obry
2 siblings, 1 reply; 50+ messages in thread
From: Robert Dewar @ 1999-09-06 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-06 0:00 ` Robert Dewar
@ 1999-09-06 0:00 ` Bob Collins
1999-09-07 0:00 ` Pascal Obry
0 siblings, 1 reply; 50+ messages in thread
From: Bob Collins @ 1999-09-06 0:00 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-06 0:00 ` Francois Godme
1999-09-06 0:00 ` Robert Dewar
@ 1999-09-06 0:00 ` Robert Dewar
1999-09-07 0:00 ` Pascal Obry
2 siblings, 0 replies; 50+ messages in thread
From: Robert Dewar @ 1999-09-06 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-06 0:00 ` Francois Godme
1999-09-06 0:00 ` Robert Dewar
1999-09-06 0:00 ` Robert Dewar
@ 1999-09-07 0:00 ` Pascal Obry
1999-09-07 0:00 ` Francois Godme
1999-09-08 0:00 ` Francois Godme
2 siblings, 2 replies; 50+ messages in thread
From: Pascal Obry @ 1999-09-07 0:00 UTC (permalink / raw)
[-- 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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-07 0:00 ` Pascal Obry
@ 1999-09-07 0:00 ` Francois Godme
1999-09-08 0:00 ` Francois Godme
1 sibling, 0 replies; 50+ messages in thread
From: Francois Godme @ 1999-09-07 0:00 UTC (permalink / raw)
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?
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-07 0:00 ` Pascal Obry
1999-09-07 0:00 ` Francois Godme
@ 1999-09-08 0:00 ` Francois Godme
1 sibling, 0 replies; 50+ messages in thread
From: Francois Godme @ 1999-09-08 0:00 UTC (permalink / raw)
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,
- ...
- ...
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-03 0:00 ` Francois Godme
` (3 preceding siblings ...)
1999-09-03 0:00 ` David C. Hoos, Sr.
@ 1999-09-04 0:00 ` Mario Klebsch
1999-09-05 0:00 ` Robert Dewar
1999-09-05 0:00 ` Geoff Bull
1999-09-07 0:00 ` Michael F. Yoder
6 siblings, 1 reply; 50+ messages in thread
From: Mario Klebsch @ 1999-09-04 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Function Calls by Address
1999-09-04 0:00 ` Mario Klebsch
@ 1999-09-05 0:00 ` Robert Dewar
1999-09-06 0:00 ` Francois Godme
0 siblings, 1 reply; 50+ messages in thread
From: Robert Dewar @ 1999-09-05 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-05 0:00 ` Robert Dewar
@ 1999-09-06 0:00 ` Francois Godme
1999-09-05 0:00 ` Brian Rogoff
1999-09-06 0:00 ` Robert Dewar
0 siblings, 2 replies; 50+ messages in thread
From: Francois Godme @ 1999-09-06 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-06 0:00 ` Francois Godme
@ 1999-09-05 0:00 ` Brian Rogoff
1999-09-06 0:00 ` Robert Dewar
1 sibling, 0 replies; 50+ messages in thread
From: Brian Rogoff @ 1999-09-05 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-06 0:00 ` Francois Godme
1999-09-05 0:00 ` Brian Rogoff
@ 1999-09-06 0:00 ` Robert Dewar
1999-09-08 0:00 ` Georg Bauhaus
1 sibling, 1 reply; 50+ messages in thread
From: Robert Dewar @ 1999-09-06 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Function Calls by Address
1999-09-06 0:00 ` Robert Dewar
@ 1999-09-08 0:00 ` Georg Bauhaus
0 siblings, 0 replies; 50+ messages in thread
From: Georg Bauhaus @ 1999-09-08 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Function Calls by Address
1999-09-03 0:00 ` Francois Godme
` (4 preceding siblings ...)
1999-09-04 0:00 ` Mario Klebsch
@ 1999-09-05 0:00 ` Geoff Bull
1999-09-07 0:00 ` Michael F. Yoder
6 siblings, 0 replies; 50+ messages in thread
From: Geoff Bull @ 1999-09-05 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: Function Calls by Address
1999-09-03 0:00 ` Francois Godme
` (5 preceding siblings ...)
1999-09-05 0:00 ` Geoff Bull
@ 1999-09-07 0:00 ` Michael F. Yoder
6 siblings, 0 replies; 50+ messages in thread
From: Michael F. Yoder @ 1999-09-07 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 50+ messages in thread