newbie Q: storage management

newbie Q: storage management

[Kaz Kylheku]

I've looked at the ISO standard and the relevant FAQ's and tutorials, but I
still need some discussion or clarification about the management of objects
obtained via ``new'', because what I have read so far seemed rather vague in
one respect.

Whose responsibility is it to destroy these objects? The Ada 95 standard
says that an implementation is permitted to implement garbage collection,
but not required to do so.

I know that it is possible to instantiate a generic freeing function for
explicitly destroying objects. But why is there is this lack of symmetry in the
language?  On the one hand, you have a slick ``new''-expression to create
objects, but the complementary deletion operation is totally obscured. Does
this mean that explicit freeing of objects via an instance of
Unchecked_Deallocation is discouraged (due to the potential creation of
dangling references)? Is it the reponsibility of the language implementation to
automagically detect when an object is no longer reachable and do the
appropriate deallocation, even if garbage is not collected?

Re: newbie Q: storage management

[Samuel A. Mize]

Kaz Kylheku wrote:
> 
> I've looked at the ISO standard and the relevant FAQ's and tutorials, but I
> still need some discussion or clarification about the management of objects
> obtained via ``new'', because what I have read so far seemed rather vague in
> one respect.
> 
> Whose responsibility is it to destroy these objects? The Ada 95 standard
> says that an implementation is permitted to implement garbage collection,
> but not required to do so.

It's the programmer's responsibility to destroy individual objects with
Unchecked_Deallocation.

What this does is implementation dependent -- if memory reclamation is required,
it's the responsibility of the programmer (or code reuser) to ensure that the
implementation (that is, by the compiler and run-time system) reclaims memory
as necessary.


> I know that it is possible to instantiate a generic freeing function for
> explicitly destroying objects. But why is there is this lack of symmetry in the
> language?  On the one hand, you have a slick ``new''-expression to create
> objects, but the complementary deletion operation is totally obscured.

The language designers did not want to require memory reclamation, let alone
garbage collection, because there are important application domains where these
are avoided.  Many embedded systems builders avoid using dynamic memory, and the
needs of such developers were a major design driver for Ada.

If reclamation were in the language, embedded systems builders could just avoid
it, but compilers targeted to the embedded-system market would still have to
include it to be validated.  This adds cost and complexity to the compiler,
and adds size to the run-time code that gets loaded along with the user code.

(Embedded systems avoid dynamic memory because a real-time critical system, like
a terrain-following radar, can't afford to pause for half a second to collect
garbage, let alone fail because it ran out of memory.)


>Does
> this mean that explicit freeing of objects via an instance of
> Unchecked_Deallocation is discouraged (due to the potential creation of
> dangling references)?

No.  It just means you should know what you're doing in two areas:
1) Make sure the logic of your code avoids using dangling references.
2) If memory reclamation is important for your application, make sure that
   the implementation supports it.
3) If your program is large or long-lived enough for memory leakage to be
   a problem, make sure you deallocate objects when done with them.  (In
   this case, (2) definitely applies.)


Note that dynamic storage is often useful WITHOUT reclamation.  For instance,
if you read some kind of dictionary into your program from a file, you might
put it into a linked list so you aren't tied to a specific table size, even
though you will never delete any of the terms.


>Is it the reponsibility of the language implementation to
> automagically detect when an object is no longer reachable and do the
> appropriate deallocation, even if garbage is not collected?

Nope.  You can chew up the entire system's memory with this program:

  procedure Just_Kill_Me is
    type integer_access is access integer;
    x: integer_access;
  begin
    loop
       x := new integer;
    end loop;
  end Just_Kill_Me;

Is this the best language-design tradeoff?  well, yes and no, respectively.
It depends on what you want to use the language for, and how you want to
use it.

Sam Mize

-- Samuel Mize           (817) 619-8622               "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: newbie Q: storage management

[kaz]

In article <336754A0.41C6@magellan.bgm.link.com>,
Samuel A. Mize <smize@magellan.bgm.link.com> wrote:

>It's the programmer's responsibility to destroy individual objects with
>Unchecked_Deallocation.

Okay, that's basically what I wanted to know. Thank you (and others) very much.

>Note that dynamic storage is often useful WITHOUT reclamation.  For instance,
>if you read some kind of dictionary into your program from a file, you might
>put it into a linked list so you aren't tied to a specific table size, even
>though you will never delete any of the terms.

Yes, this is true. Another common example is compilers which never deallocate
their symbol table data structures, syntax trees and the like. It's not
uncommon to not even implement deletion operations from such structures.
The idea is that the compiler is short lived, and works on reasonably
small sets of data.

>>Is it the reponsibility of the language implementation to
>> automagically detect when an object is no longer reachable and do the
>> appropriate deallocation, even if garbage is not collected?
>
>Nope.  You can chew up the entire system's memory with this program:
>
>  procedure Just_Kill_Me is
>    type integer_access is access integer;
>    x: integer_access;
>  begin
>    loop
>       x := new integer;
>    end loop;
>  end Just_Kill_Me;
>
>Is this the best language-design tradeoff?  well, yes and no, respectively.
>It depends on what you want to use the language for, and how you want to
>use it.

Isn't it funny how deletion is usually more complicated than creation? I mean
in general. Pick a data structure at random, and chances are that its deletion
algorithm is more difficult than insertion. In file systems, deletion of files
seems to pose more problems than file creation.  (Consider, e.g., that SunOS
updates inodes synchronously when deleting files, to forestall the possibility
of irrecoverable corruption, but when creating files it does not act this way).
Inserting into a binary search tree, balanced or not, is a heck of a lot easier
than deleting.  And even in simple linked lists, removal of nodes can be harder
than insertion.

In some way it makes perfect sense that Ada doesn't provide a handy ``delete''
to accompany the ``new'', since a lot more care is required when an object
is being deleted than when it's being created.

Re: newbie Q: storage management

[Jon S Anthony]

In article <336754A0.41C6@magellan.bgm.link.com> "Samuel A. Mize" <smize@magellan.bgm.link.com> writes:

> What this does is implementation dependent -- if memory reclamation
> is required, it's the responsibility of the programmer (or code
> reuser) to ensure that the implementation (that is, by the compiler
> and run-time system) reclaims memory as necessary.

How can this be the responsibility of the application programmer?
Also, the effects of UC are pretty well laid out in 13.11.2 and while
reclamation is implementation dependent (?!?!) I would think any
implementation not providing it for the standard storage pool would be
sorely broken.  Unusably broken.


> If reclamation were in the language, embedded systems builders could
> just avoid it, but compilers targeted to the embedded-system market
> would still have to include it to be validated.  This adds cost and
> complexity to the compiler, and adds size to the run-time code that
> gets loaded along with the user code.

I suppose you would really be against GC.  I don't know why people
keep saying this.  How is this in any way different from any other
specialized needs annex sort of thing???  Just cast it in those sorts
of terms.  If you didn't want to supply it don't implement that annex
and you wouldn't validate against that annex.  Shrug.  Those who
didn't want it wouldn't care.  I don't see the problem.  I know Robert
thinks this is "gratuitous rubbish", but at this point, I think it is
fairly clear that the wider community takes GC to be at least as
fundamental and important a thing as distributed objects or
interfacing to COBOL - both of which made it into annexes.  In fact,
it seems rather more fundamental as both of these can be handled in
readily available language independent ways (via CORBA, for example).


> >Does
> > this mean that explicit freeing of objects via an instance of
> > Unchecked_Deallocation is discouraged (due to the potential creation of
> > dangling references)?
> 
> No.  It just means you should know what you're doing in two areas:

Well, I disagree.  I think it _does_ have an _intentional_ negative
connotation for the very reason (and some others) that Kaz points out.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: newbie Q: storage management

[Samuel A. Mize]

Jon S Anthony wrote:
> In article <336754A0.41C6@magellan.bgm.link.com> "Samuel A. Mize" <smize@magellan.bgm.link.com> writes:

Please note that I was trying explain the reasoning behind unchecked
deallocation, which was designed for Ada 83, not Ada 95.  If that
was unclear, I apologize.  The design decision was carried over into
Ada 95 by (1) the vocal minority who fear dynamic memory usage,
(2) the requirement for upward compatibility, and (3) inertia.  (See
also below about "special needs annexes" before flaming.)

As Jon write in another post:
> Basically, this asymmetry is there because the designers did not think
> they could "require" GC (at least at the level of the high expectation
> of it for things like Lisp, Eiffel, ST, etc.) because many of the
> target areas of use would not need (or even require _not_ having) GC.

That's it exactly.  I was just trying to fill in some of the
ideas behind people requiring _not_ having GC, in the 1977-1983
time frame.


Regarding unchecked deallocation, Jon quoted me:
> > What this does is implementation dependent -- if memory reclamation
> > is required, it's the responsibility of the programmer (or code
> > reuser) to ensure that the implementation (that is, by the compiler
> > and run-time system) reclaims memory as necessary.
> 
> How can this be the responsibility of the application programmer?

The same way it's the programmer's responsibility to make sure
that the implementation supports the Distributed Annex when writing
code that requires it.

More specifically, I guess, it's the responsibility of whoever
procures the compiler.

The point is just that there isn't an onus on all implementations
to reclaim memory when it's freed.


> Also, the effects of UC are pretty well laid out in 13.11.2 and while
> reclamation is implementation dependent (?!?!) I would think any
> implementation not providing it for the standard storage pool would be
> sorely broken.  Unusably broken.

True for most applications.  The requirements were written so that a
vocal minority could get validated compilers.  (In all fairness,
they were the supposed target group for the language, originally.
Ada rapidly evolved to serve a larger audience.)

For Ada 95, 13.11.2(10) says that after unchecked deallocation
"their storage can be reused for other purposes" but this stops
short of explicitly requiring it to be made available for later
dynamic allocation.  If it required reclamation, 13.11.2(17) would
be meaningless.  ("For a standard storage pool, Free should actually
reclaim the storage." -- but implementation advice, not a
requirement.)

So, we two and the standard agree that a non-reclaiming implementation
would be marginal at best.  But, it could validate, and would be useful
-- even critical -- to a small minority.


> > If reclamation were in the language, embedded systems builders could
> > just avoid it, but compilers targeted to the embedded-system market
> > would still have to include it to be validated.  This adds cost and
> > complexity to the compiler, and adds size to the run-time code that
> > gets loaded along with the user code.
...
> I suppose you would really be against GC.

No, not at all.  The poster asked about the reasons for a decision,
and I explained them as best I understood the reasoning of the
language designer (I don't see Mr. Ichbiah posting here, or I'd
let him speak for himself).

I tried to indicate that it was not necessarily a consenus in the
computing community, but I didn't state that explicitly.


>I don't know why people
> keep saying this.  How is this in any way different from any other
> specialized needs annex sort of thing???


I was talking about the original design decision, which was made
for Ada 83, when things were either included or not.  I forgot our
general c.l.a rule that "Ada" refers to Ada 95.

The specialized needs annexes are a great boon, and there are
several I'd like to see defined.  Maybe there could be created a
working group for interim/proposed annexes.  They need to be
written down, debated, and tested out, just like Ada 95 was.
Many of the problems that Ada 95 fixes would never have gotten
INTO Ada 83 if it had gone through the test/eval cycle they used
for Ada 95.  (Thanks, Mr. Taft!)

For all I know, maybe there IS such a group at the ANSI or ISO
level.  Anyone know, or know how to start such a thing?  If not,
is anyone else interested in a project to consider different
language extension proposals (formally or informally)?

The only decent argument I've seen against a GC annex is that it
would have to either select a single approach and denigrate all
others, or else provide such a generalized interface as to be a
pointless standard.  I DON'T AGREE OR DISAGREE WITH THIS, since
I know too little about garbage collection research.  The best
refutation would be a strawman of the package(s) and/or the
rules that the annex would provide.

I suspect it mostly didn't get an annex because the pro-GC forces
were sociologically unable to force the issue.


> I suppose you would really be against GC.
...
> I know Robert
> thinks this is "gratuitous rubbish",

Hi, my name is Samuel Mize.  I work for Hughes Training, Inc.  I
have a Masters in Computer Science from Kansas State University
(which included sofware engineering, practical development
methods, and both useful and esoteric theory -- but that's
another thread entirely).

Robert Dewar and I often agree, sometimes disagree, and are
certainly not the same person.

If I unintentionally hit buttons on you that are sensitive
from discussions with him, I apologize.


> > >Does
> > > this mean that explicit freeing of objects via an instance of
> > > Unchecked_Deallocation is discouraged (due to the potential >>>creation of
> > > dangling references)?
> >
> > No.  It just means you should know what you're doing in two areas:
> 
> Well, I disagree.  I think it _does_ have an _intentional_ negative
> connotation for the very reason (and some others) that Kaz points out.

Well, connotations always depend, to some extent, on the reader.
Certainly some of the people involved in the language design process
(83 and 95) would agree with you.

To me, the connotation is "be careful."  It's the difference
between a fellow professional warning you to be careful, and a
mother screaming at a four-year-old to be careful.  (Some of the
language committee are real mothers. :-)


> /Jon

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
In another message the same poster writes:

> I'm working on a set of GC subsystems providing a range of generic GC
> variants which will allow you to create various collectors (various
> versions of mark-sweep, mark-compact, copying, generational,
> concurrent, treadmill, etc.) for your supplied type(s).
> ...
> I can't say for sure when all this will be ready, but probably some
> time this summer.

I very much look forward to seeing it.  Is this going to be freely
available (perhaps copyleft), shareware, a product, or what?

Sam Mize

-- Samuel Mize           (817) 619-8622               "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: newbie Q: storage management

[Jon S Anthony]

In article <336A065B.41C6@magellan.bgm.link.com> "Samuel A. Mize" <smize@magellan.bgm.link.com> writes:

> (2) the requirement for upward compatibility, and (3) inertia.  (See

I think your point (3) is very apropos.


> > How can this be the responsibility of the application programmer?
> 
> The same way it's the programmer's responsibility to make sure
> that the implementation supports the Distributed Annex when writing
> code that requires it.
...
> The point is just that there isn't an onus on all implementations
> to reclaim memory when it's freed.

Just like for DSA, et.al.  Sounds familiar.


> So, we two and the standard agree that a non-reclaiming implementation
> would be marginal at best.  But, it could validate, and would be useful
> -- even critical -- to a small minority.

Check.


> > I suppose you would really be against GC.
> 
> No, not at all.  The poster asked about the reasons for a decision,

That's good to hear!


> and I explained them as best I understood the reasoning of the
> language designer (I don't see Mr. Ichbiah posting here, or I'd
> let him speak for himself).

;^)


> The specialized needs annexes are a great boon, and there are
> several I'd like to see defined.  Maybe there could be created a
> working group for interim/proposed annexes.  They need to be
> written down, debated, and tested out, just like Ada 95 was.

I agree and as I've said before, I think this sort of idea is very
good.  Others strongly disagree.


> The only decent argument I've seen against a GC annex is that it
> would have to either select a single approach and denigrate all
> others, or else provide such a generalized interface as to be a
> pointless standard.  I DON'T AGREE OR DISAGREE WITH THIS, since
> I know too little about garbage collection research.  The best
> refutation would be a strawman of the package(s) and/or the
> rules that the annex would provide.

The "single approach" argument is definitely wrong.  The "too general"
argument is in error too as this can be handled with a subsystem
approach (similar to Interfaces).  I am working on this _sort_ of
thing now, which would support working versions now within the
language (i.e., w/o compiler support).  OTOH, any reasonable
description for an annex here would have to assume compiler support
and that changes what the stuff looks like.


> I suspect it mostly didn't get an annex because the pro-GC forces
> were sociologically unable to force the issue.

I'm pretty sure something like this is true.


> > I know Robert
> > thinks this is "gratuitous rubbish",
> 
> Hi, my name is Samuel Mize.  I work for Hughes Training, Inc.  I

I was not refering to you by "Robert" here! :-) Though I can see how
you would think that given the way it was written...  I was actually
refering to what Robert wrote in another thread a while back.


> If I unintentionally hit buttons on you that are sensitive
> from discussions with him, I apologize.

Nope.  Not at all.  I just have a different perspective.


> Well, connotations always depend, to some extent, on the reader.

Definitely true.  A good point to bring out.


> To me, the connotation is "be careful."  It's the difference
> between a fellow professional warning you to be careful, and a
> mother screaming at a four-year-old to be careful.  (Some of the
> language committee are real mothers. :-)

So to speak  :-) :-)


> > I'm working on a set of GC subsystems providing a range of generic GC
> > variants which will allow you to create various collectors (various
> > versions of mark-sweep, mark-compact, copying, generational,
> > concurrent, treadmill, etc.) for your supplied type(s).
> > ...
> > I can't say for sure when all this will be ready, but probably some
> > time this summer.
> 
> I very much look forward to seeing it.  Is this going to be freely
> available (perhaps copyleft), shareware, a product, or what?

Excellent.  That's a very good question.  In general I think it would
be good if this stuff were widely and readily available, and that it
is seen as usable in other products.  That eliminates "standard" GPL
and indicates that it should also be supported.  I'm not sure yet what
the "right" thing to do is.


/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: newbie Q: storage management

[Robert Dewar]

Samuel Mize said

<<Please note that I was trying explain the reasoning behind unchecked
deallocation, which was designed for Ada 83, not Ada 95.  If that
was unclear, I apologize.  The design decision was carried over into
Ada 95 by (1) the vocal minority who fear dynamic memory usage,
(2) the requirement for upward compatibility, and (3) inertia.  (See
also below about "special needs annexes" before flaming.)>>



Actually this is quite wrong. Samuel, you were not there, and so you
are guessing, and you are guessing wrong!

In fact the viability of garbage collection in a language at the level
of Ada is far from established. We have no good proof by example that
it is feasible. Real java compilers, as opposed to safe Java
interpretors, may give such proof. One very large item of concern is
that if you have a language that provides system level features that
let you mess at a low level, it is all too easy to cause damage
to critical structures that GC depends on, and bugs caused in this
way can be diabolical to track down.

I speak from experience here, during my work on SPITBOL, we occasionally
ran into such bugs (I have been playing with GC for a long time, see
my paper in 1977 Software Practice and Experience, and also Steve
Burov's thesis, from 1978, on garbage collection in Algol-68).

Algol-68 might have given some demonstration that GC could be widely used,
if A68 itself had been widely used. Certainly in England, where A68 was
widely used, all sorts of applications ended up successfully using GC.

But the fact of the matter is that the great majority of people are
unconvinced, and I was certainly not able to convince the Ada 95
committee to evenm consider GC, even in the context of the information
systems annex as an optional feature.

There was indeed a vocal minority on this issue, but it was a very small
minority (1, me) and it was on the other side. The great majority, namely
everyone else, was opposed to going beyond the Ada 83 design point, i.e.
allowing GC, but not insisting on it.

Right now, the best thing, rather than flaming away on CLA, would be
for advocates of GC to implement GC in GNAT and desmonstrate that
it works fine.

(Hint: use the Modula-3 work as a starting point)

Certainly no one could have suggested removing the explicit deallocation
from Ada 95, that would have been a truly silly suggestion, which would
not have been given 2 seconds of attention.

What could have been done was to say some warm words about GC, and define
the semantics of Storage_Error in the presence of GC a little more precisely,
but even that was not acceptable to the great majority.

Re: newbie Q: storage management

[Jon S Anthony]

In article <dewar.862662302@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> In fact the viability of garbage collection in a language at the level
> of Ada is far from established. We have no good proof by example that
> it is feasible. Real java compilers, as opposed to safe Java

Why doesn't Eiffel count as such?  Or do you consider it significantly
higher level than Ada?  Or that it is not a successful example?  What
would count as success?

> that if you have a language that provides system level features that
> let you mess at a low level, it is all too easy to cause damage
> to critical structures that GC depends on, and bugs caused in this
> way can be diabolical to track down.

True.  But Eiffel navigates these treacherous waters in directly
supporting C interaction even with the GC on.  Of course, you could
believe (see above) that Eiffel is simply a failure here.


> Certainly no one could have suggested removing the explicit deallocation
> from Ada 95, that would have been a truly silly suggestion, which would
> not have been given 2 seconds of attention.

Absolutely.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: newbie Q: storage management

[Robert Dewar]

Jon asks

<<Why doesn't Eiffel count as such?  Or do you consider it significantly
higher level than Ada?  Or that it is not a successful example?  What
would count as success?>>

I was talking about languages that are in wide use. Obviously there are
examples of general GC in languages of this class that precede Eiffel by
a long time. The most obvious example is Algol-68 (note the date that is
now 30 years ago!), which was widely used in England (the RRE implementation
on ICL machines was viable and used for many real applications), but still
I would not consider Algol-68, or Eiffel, or Modula-3 to be languages that
have achieved mainstream status. 

Probably the most interesting thing about Java as a language (perhaps the
only really interesting thing from a language point of view), is its
commitment to garbage collection. But despite the Sun-induced hype, we
cannot consider Java to be mainstream yet (as far as I know, there is not
one single major Java application on the market -- Corel is the nearest I
know of, but the disastrously inefficient beta that is available is hardly
convincing). Still in terms of perception (a tribute to the effectiveness
of the Sun PR machine) Java already is mainstream. I think that if and
when we have real Java compilers (GC is always easier in safe interpretors)
and when we have major Java applications which demonstrate satsifactory
performance, then GC will have arrived at a new level of acceptance.

Going back to Eiffel. Yes, I agree that from a technical point of view,
the point is also made by Eiffel. If we had extensive examples of the
use of Eiffel for low level systems applications involving lots of low
level interfacing stuff, then this would also be convincing, but right
now, Eiffel does not show up on the radar screen of widely used languages
(see for example the survey posted by JPR recently, and also the survey
quoted recently by Bill Gates for PC development -- it is interesting to
note that Java does not appear in the JPR survey, but does in the Gates
survey -- at 9%, although Bill is quite skeptical as to whether this
number is real or not, since he guesses that most users of Java on the
PC are still experimenting and fiddling and not really doing major
development (the major development language on the PC is of course
Visual Basic, which owns well over half the market).

Re: newbie Q: storage management

[Samuel A. Mize]

Robert Dewar wrote:
> 
> Samuel Mize said
> 
> <<Please note that I was trying explain the reasoning behind unchecked
> deallocation, which was designed for Ada 83, not Ada 95.  If that
> was unclear, I apologize.  The design decision was carried over into
> Ada 95 by (1) the vocal minority who fear dynamic memory usage,
> (2) the requirement for upward compatibility, and (3) inertia.  (See
> also below about "special needs annexes" before flaming.)>>
> 
> Actually this is quite wrong. Samuel, you were not there, and so you
> are guessing, and you are guessing wrong!

Perhaps true.  However,
> <<Please note that I was trying explain the reasoning behind unchecked
> deallocation,

specifically why it's harder to use than "new" and is not defined to
actually do anything.  I wasn't referring, in this paragraph, to
garbage collection.  Unfortunately, I put a side point about GC into
my post before continuing my main thrust, and this misled you.  Sorry.

Your discussions about the design reasons behind these points
(requiring a generic instantiation of U_D, not requiring U_D to
do anything) have been very helpful.  Thank you.

Sam Mize

-- Samuel Mize           (817) 619-8622               "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: newbie Q: storage management

[Robert Dewar]

iSamuel said

<<The only decent argument I've seen against a GC annex is that it
would have to either select a single approach and denigrate all
others, or else provide such a generalized interface as to be a
pointless standard.  I DON'T AGREE OR DISAGREE WITH THIS, since
I know too little about garbage collection research.  The best
refutation would be a strawman of the package(s) and/or the
rules that the annex would provide.

I suspect it mostly didn't get an annex because the pro-GC forces
were sociologically unable to force the issue.>>


Samuel, you don't understand the dynamics behind the special needs
annexes. They are VERY conservatively chosen, and are supposed to
represent only items on which there was a clear consensus that for
certain application areas, the annex facilities were clearly an
absolute necessity, and it was important that if such facilities
were provided, then they should be provided in a common way.

In the GC case, there was no such consensus. The general impression was
that it was unlikely that many Ada compilers would implement GC, and
in any case there was certainly NO consensus on what facillities should
be required of compilers that might try.

I would be VERY much opposed to trying to standardize this facility
at this stage, we simply don't know enough, and even those who favor
GC strongly have VERY different ideas about what facilities should be
provided.

As I said before, don't put your efforts into an ANSI committee, put them
into an actual implementation. It is certainly doable, as has been
demonstrated by the GCC port of Modula-3 -- yes it's just a research
project that was never fully finished, but it got far enough to be an
effective proof of feasibility.

If there was a GNAT with garbage collectoin that turned out to be usable
and widely used, that would have more effect than anything said here on
the progress towards routine use of GC in Ada environments.

Re: newbie Q: storage management

[Samuel A. Mize]

The only thing I don't understand about this posting is why you think
it contradicts mine.  The technical argument is that there is no
consensus on whether GC is needed or what kind should be specified.  GC
advocates don't agree with that, but were unable to convince everyone
else during the revision process.  The best approach now for GC advocates
would be to do one or more straw-man implementations.

The only difference that I see is that you are stating that the right
decision was made, while I was trying to stay value-neutral in this
one posting. 

Just for the record, I don't think an annex would have been appropriate.
I'd like to see some kind of working group -- formal or not -- to
coordinate people working on possible new language extensions.  For
one thing, it would give such language-change advocates a better focus
for their work than c.l.a postings, and anyone interested could visit
their web site and stay in touch.

Anyone know of such an effort?  Anyone else interested?

Sam Mize



Robert Dewar wrote:
> 
> iSamuel said
> 
> <<The only decent argument I've seen against a GC annex is that it
> would have to either select a single approach and denigrate all
> others, or else provide such a generalized interface as to be a
> pointless standard.  I DON'T AGREE OR DISAGREE WITH THIS, since
> I know too little about garbage collection research.  The best
> refutation would be a strawman of the package(s) and/or the
> rules that the annex would provide.
> 
> I suspect it mostly didn't get an annex because the pro-GC forces
> were sociologically unable to force the issue.>>
> 
> Samuel, you don't understand the dynamics behind the special needs
> annexes. They are VERY conservatively chosen, and are supposed to
> represent only items on which there was a clear consensus that for
> certain application areas, the annex facilities were clearly an
> absolute necessity, and it was important that if such facilities
> were provided, then they should be provided in a common way.
> 
> In the GC case, there was no such consensus. The general impression was
> that it was unlikely that many Ada compilers would implement GC, and
> in any case there was certainly NO consensus on what facillities should
> be required of compilers that might try.
> 
> I would be VERY much opposed to trying to standardize this facility
> at this stage, we simply don't know enough, and even those who favor
> GC strongly have VERY different ideas about what facilities should be
> provided.
> 
> As I said before, don't put your efforts into an ANSI committee, put them
> into an actual implementation. It is certainly doable, as has been
> demonstrated by the GCC port of Modula-3 -- yes it's just a research
> project that was never fully finished, but it got far enough to be an
> effective proof of feasibility.
> 
> If there was a GNAT with garbage collectoin that turned out to be usable
> and widely used, that would have more effect than anything said here on
> the progress towards routine use of GC in Ada environments.

-- Samuel Mize           (817) 619-8622               "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: newbie Q: storage management

[Michael F Brenner]

> I'd like to see some kind of working group -- formal or not -- to
> coordinate people working on possible new language extensions.  For
> one thing, it would give such language-change advocates a better focus
> for their work than c.l.a postings, and anyone interested could visit
> their web site and stay in touch.
> 
> Anyone know of such an effort?  Anyone else interested?
> 
> Sam Mize

Such a group surely exists (or existed) because they voted on Ada-95.
However, that group does not necessarily represent all of the opinions
in the Ada community. In particular, that group opposes the majority
of the community in the topics of code efficiency, first class objects,
and the horribleness of the text_io restrictions. In addition, that
group opposes the minority of the community in other topics such as
efficient conversions between unsigned and signed types, efficiency of
doing unchecked_conversion without any object code generation, type
conversions with no code generation, restrictions preventing certain
time and space optimizations, and whether code efficiency should 
be discussed at all.
 
We all appreciate the work that group has done in continuing the language.
However, the decisions of that group were not perfect. Those decisions 
would have been better had some people with the opposing views been 
consulted. For example, Java would not have been necessary had Ada-95
adapted packages as first class objects (permitting arrays of packages). 
Even as second class objects, permitting passing packages to generics,
Java would have petered out in favor of Ada-95. 

The process needs improvement to the point where new people and new ideas 
get more of a chance to be injected. This is essential for the next step
Ada is about to take in specifying optical and hardware processes where
the code generated is circuits, ASICs, hardware implemented finite state
machines, and semi-optical computational systems. 

There IS a place in the REAL GROUP for representing alternative
opinions on issues such as these.

Another reason to open up the group to more people is that this group feels
that certain problems have been solved, according to recent posts. However,
some people in the community do not have access to the reasons why they
think they have been solved. In recent posts, I have been told that there
are machine- and compiler-independent ways within Ada-95 to 
   - put bits into a byte
   - do stream_IO
   - select alternate bodies for packages
     (for example, 1000 device drivers with the same visible part,
     of which one is selected as part of a computer program)

But I do not know how to accomplish these things in a machine- and
compiler-independent manner, using the pragmas, attributes, and features
of the Ada-95 language in the ISO standard. Therefore, either I am
ignorant in these three areas, or the standard needs specific examples
in these three areas, or the language needs to be fixed to do these
important things portably. 

Just my opinion, since you asked. 

Assuaging sour grapes :-) [was: newbie Q: storage management]

[John G. Volan]

Michael F Brenner wrote:

> Another reason to open up the group to more people is that this group feels
> that certain problems have been solved, according to recent posts.

I said the problems you described _might_ have been solved, but without
something more than the sketchy description you gave, it's hard to tell.

> However,
> some people in the community do not have access to the reasons why they
> think they have been solved. In recent posts, I have been told that there
> are machine- and compiler-independent ways within Ada-95 to
>    - put bits into a byte
>    - do stream_IO
>    - select alternate bodies for packages
>      (for example, 1000 device drivers with the same visible part,
>      of which one is selected as part of a computer program)

I asked you to show a fleshed-out example of this this last problem so I
or others could perhaps help you, but so far I haven't seen it.  But let
me take a guess at it any way:

    --------------------------------------------------------------------
    package Drivers is

      type Driver_Type is abstract tagged limited private;
      type Driver_Access_Type is access all Driver_Type'Class;

      procedure Some_Primitive_Operation_Every_Driver_Must_Support
        (Driver : in out Driver_Type;
         ... -- other parameters)
      is abstract;

      procedure Some_Other_Primitive_Operation_Every_Driver_Must_Support
        (Driver : in out Driver_Type;
         ... -- other parameters)
      is abstract;

      ... -- etc.

      procedure Some_Reusable_Algorithm_That_Should_Work_With_Any_Driver
        (Driver : in out Driver_Type'Class; -- classwide, not inherited
         ... -- other parameters);
      -- not abstract, actually implemented here in terms of
      -- the primitives (could be written anywhere actually)

      ...

    end Drivers;
    --------------------------------------------------------------------
    package Drivers.Mark_1 is

      type Mark_1_Driver_Type is new Driver_Type with private;

      procedure Some_Primitive_Operation_Every_Driver_Must_Support
        (Mark_1_Driver : in out Mark_1_Driver_Type;
         ... -- other parameters);

      procedure Some_Other_Primitive_Operation_Every_Driver_Must_Support
        (Mark_1_Driver : in out Mark_1_Driver_Type;
         ... -- other parameters);

      ... -- etc.

    end Drivers.Mark_1;
    --------------------------------------------------------------------
    ... repeat 1000 times
    --------------------------------------------------------------------
    package Drivers.Mark_1000 is

      type Mark_1000_Driver_Type is new Driver_Type with private;

      procedure Some_Primitive_Operation_Every_Driver_Must_Support
        (Mark_1000_Driver : in out Mark_1000_Driver_Type;
         ... -- other parameters);

      procedure Some_Other_Primitive_Operation_Every_Driver_Must_Support
        (Mark_1000_Driver : in out Mark_1000_Driver_Type;
         ... -- other parameters);

      ... -- etc.

    end Drivers.Mark_1000;
    --------------------------------------------------------------------
    with Drivers.Mark_123;
    ... -- and some other stuff
    procedure Tuesdays_Driver_Application is

      -- On Tuesday, we chose the Mark-123 driver implementation:
      Tuesdays_Driver : Drivers.Mark_123.Mark_123_Driver_Type;

      ... and some other stuff

    begin
      ...
      Drivers.Some_Reusable_Algorithm_That_Should_Work_With_Any_Driver
	(Driver => Tuesdays_Driver,
         ...);
      ...
    end Tuesdays_Driver_Application;
    --------------------------------------------------------------------
    with Drivers.Mark_456;
    ... -- and some other stuff
    procedure Wednesdays_Driver_Application is

      -- On Wednesday, we chose the Mark-456 driver implementation:
      Wednesdays_Driver : Drivers.Mark_456.Mark_456_Driver_Type;

      ... and some other stuff

    begin
      ...
      Drivers.Some_Reusable_Algorithm_That_Should_Work_With_Any_Driver
	(Driver => Wednesdays_Driver,
         ...);
      ...
    end Wednesdays_Driver_Application;
    --------------------------------------------------------------------
    with Drivers.Mark_1;
    ... -- repeat 1000 times
    with Drivers.Mark_1000;
    package Drivers.Selection is

      Mark_1_Driver    : aliased Drivers.Mark_1.Mark_1_Driver_Type;
      ... -- repeat 1000 times
      Mark_1000_Driver : aliased
Drivers.Mark_1000.Mark_1000_Driver_Type;

      type Driver_Index_Type is range 1 .. 1000;
      -- if your driver implementations have better names than "Mark n",
      -- then perhaps this could be an enumerated type called
      -- "Driver_Name_Type"

      type Driver_Selection_Type is
        array (Driver_Index_Type) of Driver_Access_Type;
        -- array of classwide pointers

      Driver_Selection : constant Driver_Selection_Type :=
        (1    => Mark_1_Driver'Access,
         2    => Mark_2_Driver'Access,
         ... -- repeat 1000 times
         999  => Mark_999_Driver'Access,
         1000 => Mark_1000_Driver'Access);

    end Drivers.Selection;
    --------------------------------------------------------------------
    with Drivers.Selection;
    ... -- and some other stuff
    package Dynamic_Interactive_Driver_Selection_Application is

      Driver_Index : Drivers.Selection.Driver_Index_Type;

      ... -- and some other stuff

    begin

      ... -- query the user for the Driver_Index,
          -- maybe using Ada.Text_IO

      Drivers.Some_Reusable_Algorithm_That_Should_Work_With_Any_Driver
	(Driver => Drivers.Selection.Driver_Selection(Driver_Index).all,
         ... );

      ... -- maybe this is all in a loop, so the user can actually
      ... -- change the driver selection as the program progresses

    end Dynamic_Interactive_Driver_Selection_Application;

Okay, so now you have a heterogeneous array of drivers, each with a
different implementation, but all implementing the same abstract
interface.  You can even dynamically select the driver at run time! What
would arrays of packages give you that this doesn't?  If you want an
array of "first-class objects" why not just use ... an array of first
class objects! :-)

Side note: If you were going to try and solve a problem like this in
some other object-oriented programming language (e.g., C++, Eiffel,
Smalltalk ...), the solution would pretty much follow the same design
pattern: You'd have a bunch of concrete-implementation subclasses
inheriting from some abstract class. Your client code would base its
(reusable) algorithms solely on the primitive interface provided by the
abstract class, working with a "classwide" view of the instance object
(in C++ you'd have to be dealing with a reference (&) or a pointer (*)
to an instance of your base class).

The only downside I can see to this design pattern is that the use of
classwide programming means that you get dynamic dispatching, which adds
a bit of overhead -- but from your sketchy description, it sounded like
you needed to be able to select the implementation at run time anyway.

> But I do not know how to accomplish these things in a machine- and
> compiler-independent manner, using the pragmas, attributes, and features
> of the Ada-95 language in the ISO standard. Therefore, either I am
> ignorant in these three areas, or the standard needs specific examples
> in these three areas, or the language needs to be fixed to do these
> important things portably.

A standards document such as the Ada95 Reference Manual can't be all
things to all people.  Its job is to formally specify the language, not
necessarily to provide a readable tutorial for its use.  There are other
places you ought to try for such tutorial help, including asking for
help on comp.lang.ada.  But please work _with_ the folks here.  We're
generally a friendly bunch, not at all the shadowy cabal of language
politicos you seem to be painting us as ... :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Assuaging sour grapes :-) [was: newbie Q: storage management]

[Kevin Cline]

"John G. Volan" <johnvolan@sprintmail.com> wrote:

>Michael F Brenner wrote:
>
>> Another reason to open up the group to more people is that this group feels
>> that certain problems have been solved, according to recent posts.
>
>I said the problems you described _might_ have been solved, but without
>something more than the sketchy description you gave, it's hard to tell.
>
>> However,
>> some people in the community do not have access to the reasons why they
>> think they have been solved. In recent posts, I have been told that there
>> are machine- and compiler-independent ways within Ada-95 to
>>    - put bits into a byte
>>    - do stream_IO
>>    - select alternate bodies for packages
>>      (for example, 1000 device drivers with the same visible part,
>>      of which one is selected as part of a computer program)
>
>I asked you to show a fleshed-out example of this this last problem so I
>or others could perhaps help you, but so far I haven't seen it.  But let
>me take a guess at it any way:
>
>    --------------------------------------------------------------------
>    package Drivers is

I think you missed the point, which is to dynamically load a package body at
run-time, not build one enormous executable containing all 1000 device
drivers.  On most systems, dynamically loaded libraries can be built from C or
C++ code.  The library source code is portable, although the commands to build
the library from source vary from system to system.  

Re: Assuaging sour grapes :-) [was: newbie Q: storage management]

[John G. Volan]

Kevin Cline wrote:
> 
> I think you missed the point, which is to dynamically load a package body at
> run-time, not build one enormous executable containing all 1000 device
> drivers.

Okay, I stand corrected.  

> On most systems, dynamically loaded libraries can be built from C or
> C++ code.  The library source code is portable, although the commands to build
> the library from source vary from system to system.

How is Ada95 different here? Isn't it possible to create DLL's from
Ada95 source code, too?  (For instance, using Aonix ObjectAda?) And even
if current implementations of Ada95 don't happen to generate DLLs, isn't
it at least feasible in principle?

My question remains: What would "arrays of packages as first- or second-
class objects" give you?  It seems to me that there's nothing in C or
C++ that makes it easier to dynamically load different versions of the
same package/class.  It's still an extra-linguistic mechanism: It
requires configuration management mechanisms outside the programming
language level.

Or am I still missing something...?

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Assuaging sour grapes :-) [was: newbie Q: storage management]

[John G. Volan]

Sorry, I need to make a few clarifications:

John G. Volan wrote:
> 
> Kevin Cline wrote:
> >
> > On most systems, dynamically loaded libraries can be built from C or
> > C++ code.  The library source code is portable, although the commands to build
> > the library from source vary from system to system.
> 
> How is Ada95 different here? Isn't it possible to create DLL's from
> Ada95 source code, too?  (For instance, using Aonix ObjectAda?) And even
> if current implementations of Ada95 don't happen to generate DLLs, isn't
> it at least feasible in principle?

I should have said: "Isn't it feasible in principle using the _current_
definition of Ada95, without need for a language change?"  ObjectAda for
instance supports pragmas Import and Export with Convention=>DLL,
couldn't other compilers just do the same?

I see the portability issue: Without a standard definition of "dynamic
linkage", different implementors could come up with different solutions;
the best we could hope for is for informal agreement between vendors to
support a de-facto standard.

Then there's portability across platforms: Isn't dynamic linkage an
operating-system dependent thing?  Can you take a DLL written in C or
C++ on WindowsNT and port it, and the applications that use it,
immediately to any Unix box?  If so, that's interesting, what would
hinder us from doing the same with Ada95?  On the other hand, if dynamic
linkage mechanisms are OS-specific, how can we possibly invent something
at the language-level that magically gives us portability?

Maybe it's already been done: Consider Java, and Ada95=>JVM compilers
like ObjectAda or AppletMagic. A JVM program isn't "linked" per se;
class files get loaded as they are needed.  However, I don't know
whether a given JVM execution can re-load a different class file to
replace an already-loaded class.

> My question remains: What would "arrays of packages as first- or second-
> class objects" give you?  It seems to me that there's nothing in C or
> C++ that makes it easier to dynamically load different versions of the
> same package/class.  It's still an extra-linguistic mechanism: It
> requires configuration management mechanisms outside the programming
> language level.
> 
> Or am I still missing something...?
------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: Assuaging sour grapes :-) [was: newbie Q: storage management]

[Robert Dewar]

John Volan says

<<I should have said: "Isn't it feasible in principle using the _current_
definition of Ada95, without need for a language change?"  ObjectAda for
instance supports pragmas Import and Export with Convention=>DLL,
couldn't other compilers just do the same?>>

Certainly it seems a good idea to try to standardize these things across
compilers where possible, but it is a lot of effort to do so (the ARA
is one forum for achieving this, and we have had some small successes --
like the agreement on pragma C_Pass_By_Copy). The difficulty is of
course that there is a delicate balance between getting agreements and
getting good solutions (the C_Pass_By_COpy solution is a kludge, and
not a very nice one, but you have to be pragmatic, and Aonix had cut
their release with this approach, so we changed GNAT to be compatible,
even though we all were not terribly convniced it was the best solution
(it's a tough problem -- the ARG is STILL discussing how to best handle
it with no approach to an agreement -- and sometimes a kludge is better
than a wonderful solution never reached :-)

But going back to the COnvention=>DLL, I am not sure that I would
immediately want to follow this. I prefer a technical solution where
you can build DLL's without having to say anything special at the language
level -- right now in GNAT you don't need to say anything special to
build a DLL. Furthermore there are differences in what can be put in
DLL's, for example, in GNAT there is no difficulty in putting tasks
in a DLL. But I really don't know much about the details at all -- just
enough to suspect that we don't really know the best way of approaching
this problem, and it may be premature to try to standardize.

Re: Assuaging sour grapes :-) [was: newbie Q: storage management]

[Jon S Anthony]

In article <33708E99.2186@sprintmail.com> "John G. Volan" <johnvolan@sprintmail.com> writes:

> How is Ada95 different here?

It's not.

> Isn't it possible to create DLL's from Ada95 source code, too?  (For

Yes.  If it happens it must be possible...

> instance, using Aonix ObjectAda?)

Yes.

> My question remains: What would "arrays of packages as first- or second-
> class objects" give you? 

I have no idea...

> It seems to me that there's nothing in C or C++ that makes it easier
> to dynamically load different versions of the same package/class.

That's because there isn't anything.


> It's still an extra-linguistic mechanism:

For statically typed languages, yes.

> It requires configuration management mechanisms outside the
> programming language level.

In the OS loader, linker, ..., stuff.


> Or am I still missing something...?

I don't think so.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Assuaging sour grapes :-) [was: newbie Q: storage management]

[Jon S Anthony]

In article <52F0EC12E20AA44E.5796B5986C85CB4B.8C3BF60EE8ED6C1C@library-proxy.airnews.net> clines@delete_this.airmail.net (Kevin Cline) writes:

> I think you missed the point, which is to dynamically load a package
> body at run-time, not build one enormous executable containing all
> 1000 device drivers.  On most systems, dynamically loaded libraries
> can be built from C or C++ code.  The library source code is
> portable, although the commands to build the library from source
> vary from system to system.

This confuses two totally different issues.  1. routine packing per
code module and 2. DLLs.  In the case of 2, Ada compilers (certainly
ObjectAda and GNAT) can build DLLs so this is just irrelevant.  As for
1., that sounds like a design issue.

Another thing that might be lurking in the background is true
incrementally linked modules/routines, where new bits are linked in
dynamically as new references are generated on the fly.  In most
scenarios, this is only plausible with true dynamic languages, in
certain other cases it is a quality of service issue of the OS.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Assuaging sour grapes :-) [was: newbie Q: storage management]

[Stephen Posey]

"John G. Volan" <johnvolan@sprintmail.com> wrote:

>Michael F Brenner wrote:

>> Another reason to open up the group to more people is that this group feels
>> that certain problems have been solved, according to recent posts.

>I said the problems you described _might_ have been solved, but without
>something more than the sketchy description you gave, it's hard to tell.

[deleted, VERY instructive abstract interface example, thank you]


>A standards document such as the Ada95 Reference Manual can't be all
>things to all people.  Its job is to formally specify the language, not
>necessarily to provide a readable tutorial for its use.  There are other
>places you ought to try for such tutorial help, including asking for
>help on comp.lang.ada.  But please work _with_ the folks here.  We're
>generally a friendly bunch, not at all the shadowy cabal of language
>politicos you seem to be painting us as ... :-)

Awwww man! :-(  I've always wanted to be part of a shadowy cabal; you
mean I have to go to some other List to join one? Rats.

Best chuckle I've had in weeks, thanks.

>------------------------------------------------------------------------
>Internet.Usenet.Put_Signature 
>  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
>   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
>   Disclaimer => "These opinions were never defined, so using them " & 
>     "would be erroneous...or is that just nondeterministic now? :-) ");
>------------------------------------------------------------------------

Regards,

Stephen Posey
slposey@concentric.net

Re: Dynamic binding of packages

[Nick Roberts]

John G. Volan <johnvolan@sprintmail.com> wrote in article
<336FDF8B.73AF@sprintmail.com> a lengthy example of using a tagged type to
provide multiple implementations of a single interface.

The use of tagged types ('classes' in C++ and most other languages) in this
way is well known, and your example illustrates the principle nicely. In
many situations, this approach works fine, and often has further
advantages, too.

However - and I am going to ask you to trust me on this (unless you really
want me post a truly humungous example ;-) - for certain real-life
situations, it is just too clumsy, because the binding - the connection
between interface and implementation - is centred around a type rather than
a package.

This type-centred abstraction means that all abstract elements of the
interface has to be in terms of subprograms with that type as its parameter
(or one of its parameters). So, one loses the direct use of all the many
other language elements Ada allows in a package specification. This is not
a fundamental problem, it is just a problem of convenience. But, the
inconvenience is sometimes so great as to constitute a barrier.

So, I would still argue that (perhaps in a future revision) the Ada
language needs a standard mechanism for the dynamic binding of packages.

Nick.

Re: Dynamic binding of packages

[John G. Volan]

Nick Roberts wrote:
> 
> However - and I am going to ask you to trust me on this (unless you really
> want me post a truly humungous example ;-) - for certain real-life
> situations, it is just too clumsy, because the binding - the connection
> between interface and implementation - is centred around a type rather than
> a package.

I suppose I can understand this in principle, but you and Michael
Brenner have piqued my curiosity. I'd really like to see a practical
example, humungous or not (or at least a representative strawman, if
you're sensitive about intellectual property). As you can probably tell,
I am not hesitant when it comes to humungous examples... :-) Take this
off-line and e-mail me if you must, although I think it still might be
instructive for others on c.l.a.

> This type-centred abstraction means that all abstract elements of the
> interface has to be in terms of subprograms with that type as its parameter
> (or one of its parameters). So, one loses the direct use of all the many
> other language elements Ada allows in a package specification. This is not
> a fundamental problem, it is just a problem of convenience. But, the
> inconvenience is sometimes so great as to constitute a barrier.

This is interesting. You may have something here (then again, you might
not). I'm not sure I grasp what "other language elements" you're trying
to tie into, or how. Exceptions? Generics?  Are you trying to take
static meta-data normally compiled away under the Ada model and make it
available to be dynamically manipulated at run-time? Might be
interesting to see exatly what you have in mind ... and you might yet be
persuaded that the language can already do it, and it's really just a
matter of choosing the right design pattern ...

> So, I would still argue that (perhaps in a future revision) the Ada
> language needs a standard mechanism for the dynamic binding of packages.

Or it could just be a compiler-implementation choice already allowed by
the current language specification, but not yet explored by (most)
current compiler vendors. (Once again, note the case of Ada95=>JVM
compilers and the dynamic loading of *.class files into a JVM applet.)
But it's hard to judge this without ... (drum roll) ... a specific
example! (ba-dump-dump)

:-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: newbie Q: storage management

[Robert Dewar]

Michael says:

<<Such a group surely exists (or existed) because they voted on Ada-95.
  However, that group does not necessarily represent all of the opinions
  in the Ada community. In particular, that group opposes the majority
  of the community in the topics of code efficiency, first class objects,
  and the horribleness of the text_io restrictions. In addition, that
  group opposes the minority of the community in other topics such as
  efficient conversions between unsigned and signed types, efficiency of
  doing unchecked_conversion without any object code generation, type
  conversions with no code generation, restrictions preventing certain
  time and space optimizations, and whether code efficiency should
  be discussed at all.>>

Well what Michael means here is that the group does not agree with him,
on some things, and that is especially interesting in view of the fact
that I never saw any contributions from him on the comment list (perhaps
he does not even know about it :-) But Michael is way off in thinking
that somehow this was a narrow process -- Michael do a little more
research on how the process worked and continues to work before you
make such statements -- as I say, you seem, somewhat surprisingly,
unaware of the comments operation! Hundreds of Ada users and experts
around the world participated actively in the design effort, which
was extraordinary open. And what was remarkable is that the ISO
standards group basically agreed on all decisions.

So, as I have said before, if you think that the group "opposes the
majority of the community in the topics of .... [put anything you
like here], you are talking nonsense. Please do not confuse the
opinions of a small number of enthusiasts on CLA with the majority
opinion of the Ada community (most serious Ada programmers I know
do not even bother to read CLA, they have better things to do with
their time, like writing Ada programs :-)

As for the group opposing things like efficient conversions etc, there you
have huge misunderstandings, common among those who have not been involved
in language design.

let's just take one of your examples "unchecked conversion without
any object code generation". It is completely impossible to discuss
this in a language standard. That is because no formal meaning can
be given to "object code generation".

Furthermore, it is technical nonsense. Of *course* you have to generate
code for unchecked conversion in some cases. For example, consider:

   type x is array (1 .. 3) of Boolean;
   for x'size use 3;

   type m is mod 2 ** 3;

   function f is new unchecked_conversion (x, m);

   v1 : x;
   v2 : m;

   v2 := f (v2);

On a big-endian machine you will VERY likely find a shift generated, since
it is natural to store x in the left 3 bits of a word or byte, and x in
the right 3 bits. If we took literally your demand of no code generation
then f would always yield a result of all zero bits -- not exactly what
the programmer intended. Similarly unchecked conversion may very well
involve sign or zero extension, and to insist otherwise might badly
damage the efficiency of code.

Code efficiency is of course discussed all the time in a language design
(an example is the very delicate discussions of the boudaries between
bounded errors and erroneous execution, for example

     x := a * b;

should the multiplication be bounded to at worst cause a program error
or store a wrong value? On most machines, an answer of yes is harmless,
but on some machines, the cheapest way to do the multiplication if b has
a small range is a jump table, and an undefended jump table could cause
a wild jump.

I realize that it is frustrating to practioners looking at things in 
simplistic terms that the Ada RM does no somehow guarantee that conforming
compilers are efficient, but it is simply not possible to achieve this.
Everyone wants efficient compilers, but it has to be the market place
that achieves this. Formal conformance measures are useless for addressing
this issue.

Sure we could have added some implementation advice in chapter 1

Advice. All Ada compilers should attempt to be as efficient as possible.

But even by the standards of some of the most meaningless statements in
the RM, this would hit a new low of uselessness, and achieve nothing.

<<We all appreciate the work that group has done in continuing the language.
  However, the decisions of that group were not perfect. Those decisions
  would have been better had some people with the opposing views been
  consulted. For example, Java would not have been necessary had Ada-95
  adapted packages as first class objects (permitting arrays of packages).
  Even as second class objects, permitting passing packages to generics,
  Java would have petered out in favor of Ada-95.>>

Of *course* people with opposing views were consulted. In fact there was
a big effort to consult anuyone willing to spend time, and Intermetrics
did a great job of organizing and disseminating the literally thousands
of messages they received commenting on the design.

As for the idea that putting package types in would have made Java
unnecessary, that's one of the more peculiar technical claims I have
seen on CLA. First of all, Java is not about being necessary, Java
is about all sorts of commercial considerations (not least of which
is for Sun to figure out how to compete with Microsoft). 

Even if you do take the naive view that languages appear and disappear
and prosper and fail solely based on their technical merits, your
proposition makes no sense. One of the main points about Java is that
it is a reaction to C++ being too large and too complex. The idea that
Ada could compete effectively and somehow have prevented Java from
appearing by making itself even larger and even more complex is truly
peculiar. 

Furthermore, I don't even see what you are getting at here. Ada effectively
spans the functionality of Java, especially if you include Annex E
semantics without any fancy additions.

As you should know, the issue of package types is an old one in the Ada
community. The Intel compiler actually implemented package types (but
was in other respects non-conforming, and was never validated, so it
was not an existence proof that it was possible to make this extension
cleanly). As I have mentioned before there was essentially one champion
for this idea (Tony Luckham), and true, he felt as you did that it was
a critical issue, but he was unable to convince anyone.

Now if you think you are right, and cannot convince anyone, there are two
ways you can react.

  (a) I am right, everyone else is wrong
  (b) I guess the idea must be wrong, or at least I don't know how to
        present it, so if I don't understand it well enough to convnice
        others, I must have some misunderstandings myself -- back to the
        drawing board.

I always prefer (b) here, and indeed there are decisions where I argued
strongly but was in a very small minority, and so abandoned the effort
on exactly grouns (b). My examples of this are:

    o  requiring GC, whatever that means, in the IS annex
    o  allowing double underscores in identifiers
    o  allowing in out parameters for subprograms

Some of you on the list will react to one or more of these points by saying
"RIGHT ON, HOW COULD THOSE IDIOTS NOT AGREE WITH YOU", but the fact of the
matter is that all three of these issues was extensively discussed by
people who know what they are talking about, and the decisions came down
decisevly on the other side, so I accept them as the clear collective
wisdom of a very wide community.

Little side note:

<<Even as second class objects, permitting passing packages to generics,
  Java would have petered out in favor of Ada-95.>>

Since any packages can be made generic, and obviousy packages to be
passed to generics must share the same signature, I do not see why
generic formal packages do not meet this requirement. Perhaps you
have not really studied this feature in detail -- it seems very
lightly used, considering its power -- it really brings the whole
notion of signatures to the Ada world.

<<Another reason to open up the group to more people is that this group feels
  that certain problems have been solved, according to recent posts. However,
  some people in the community do not have access to the reasons why they
  think they have been solved. In recent posts, I have been told that there
  are machine- and compiler-independent ways within Ada-95 to
   - put bits into a byte
   - do stream_IO
   - select alternate bodies for packages
     (for example, 1000 device drivers with the same visible part,
     of which one is selected as part of a computer program)>>

Yes, all these problems are solvable, but you can't expect people to 
neccessarily take the effort to educate you on how to solve these
problems. No one owes you that! I actually find these three examples
rather thin, I would expect any professional knowledgable Ada programmer
to be able to achieve these three goals, and certainly if you took a
commercial Ada course, such as those offered by Aonix, Ada Core Technologies,
and many others, you would learn how.

  Very briefly: putting bits into a byte is easily accomplished using rep
  clauses. The RM should be clear, if not you need to seek tutoring at a
  simpler level, e.g. from text books.

  Stream_IO is a fundamental feature of Ada 95, I don't understand what
  might be unclear here.

  The selection of alternative bodies is certainly outside the language
  proper, which only specifies the semantics of a program once assembled.

But within any implementation, there are easy solutions to this. In GNAT
you could use separate directories or the Source_File_Name pragma to
achieve this effect, or you could use GLADE (Annex E), and select the
partition structure to reflect the bodies that you want.

I do see a bit of a conflict here. There is a big gap between a self help
group which tries to teach one another simple things like this, and a
group that is knowledgable enough to usefully discuss language design 
issues. 

When new people first look at Ada, and start to learn it a bit at a time,
they naturally tread over well worn paths, but if you want to seriously
contribute to language design, you need to do some significant homework,
and realize that informal chats on CLA very rarely do more than touch
the surface of problems. Some of the materials to study are

   The old and new Rationale
   The old and new AI's
   The Implementor's guide for Ada 83
   Various Language Study Notes
   Geoff Mendall's books on Ada 83
   Norman Cohen's old and new books on Ada
   The original requirements documents
   The Ada 9X requirements document
   The Ada 9X mapping documents (all of them -- there are several,
     representing enlightening information on the progress of the design)
   The Ada 9X User requirements document
   The formal resolutions of WG9
   etc.

Yes, a lot of material, but there is a LOT of background you need here to
have the right perspective to understand how your suggestions fit into the
big picture (not to mention into the requirements of the majority of the
community)..

P.S. There was for a while a language study group associated with SIG Ada,
whose purpose was to provide additional input to the language design
process. It never was very successful in that goal, partly because a lot
of the people involved did not have the kind of depth of knowledge
necessarily to put together coherent proposals, but on the other hand,
I think a lot of people found it instructive and interesting. As I said,
in that kind of context, a lot of people spend a lot of time treading
over well worn paths and not discovering anything new, but on the other
hand discovering things for yourself is an excellent way of learning,
even if you find you are not thinking original thoughts after all :-)

Robert

Re: newbie Q: storage management

[Robert I. Eachus]

   Robert Dewar said:

  > P.S. There was for a while a language study group associated with
  > SIG Ada, whose purpose was to provide additional input to the
  > language design process. It never was very successful in that
  > goal, partly because a lot of the people involved did not have the
  > kind of depth of knowledge necessarily to put together coherent
  > proposals, but on the other hand, I think a lot of people found it
  > instructive and interesting.

   The one legacy I know of in Ada 95 from the ALIWG is the mechanism
for associating data with exception instances.  I think some other
ideas the originally surfaced in the ALIWG also made it in, but via
CIFO and the real-time working group so those ideas had, at the least,
mixed parentage.

--

					Robert I. Eachus

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

Re: newbie Q: storage management

[Robert Dewar]

Robert Eachus said

<<   The one legacy I know of in Ada 95 from the ALIWG is the mechanism
for associating data with exception instances.  I think some other
ideas the originally surfaced in the ALIWG also made it in, but via
CIFO and the real-time working group so those ideas had, at the least,
mixed parentage.>>


Hmmm! This idea is very old, and has been discussed for a long time, and
indeed, the original design for Ada 9X was much more elaborate, and more
clearly inspired by the C++ design for exceptions than from anything from
the ALIWG. In addition, the issue was mentioned in at least one of the
formal revision requests. I guess Tuck will have to comment on whether
Robert Eachus' statement above is correct. I doubt any ideas "originally
surfaced" anywhere that anyone can remember. Almost any idea in PL at this
stage has ancestral roots that can be traced back. There are verey few
features in Ada 95 that cannot trace back their ancestry to pretty ancient
languages and ideas :-)

Re: newbie Q: storage management

[Jeff Carter]

Michael F Brenner wrote:
...
> think they have been solved. In recent posts, I have been told that there
> are machine- and compiler-independent ways within Ada-95 to
>    - put bits into a byte
>    - do stream_IO
>    - select alternate bodies for packages
>      (for example, 1000 device drivers with the same visible part,
>      of which one is selected as part of a computer program)
> 
> But I do not know how to accomplish these things in a machine- and
> compiler-independent manner, using the pragmas, attributes, and features
> of the Ada-95 language in the ISO standard. Therefore, either I am
...

1. See the operations of modular types.
2. See the packages Ada.Streams and Ada.Streams.Stream_Io.
3. I don't understand what you're asking about.

-- 
Jeff Carter  PGP:1024/440FBE21
Auntie-spam reply to; try ( carter @ innocon . com )
"Now go away, or I shall taunt you a second time."
Monty Python & the Holy Grail

Re: newbie Q: storage management

[Robert Dewar]

Sam said

<<The only thing I don't understand about this posting is why you think
it contradicts mine.  The technical argument is that there is no
consensus on whether GC is needed or what kind should be specified.  GC
advocates don't agree with that, but were unable to convince everyone
else during the revision process.  The best approach now for GC advocates
would be to do one or more straw-man implementations.>>


Actually it is not true that "GC advocates don't agree with that". There
is definitely no consensus among GC advocates as to what a GC annex
might look like. Opinions range from "no annex is needed, because nothing
needs to be said in the RM -- this is an implementation issue, not 
something subject to formal specification" to "we need lots of interfaces
for user control over the GC stuff".

I would not talk about straw-man implementations, I would talk about
real usable implementations. It is much more important that something
be real and usable, than it is that it be in the standard. If someone
did a nice GC implementation for GNAT, and people started using it,
then a lot of the problem is solved. True, not all Ada 95 compilers
would have the feature but

(a) There are lots of useful things that one Ada implementation has that
another does not have that lead one to choose one implementation over
another. For example, if you are using Ada 95 on NT, and you want a
GUI builder to come with it, you may well choose Aonix. If you need the
information systems annex, you may well choose GNAT. The latter example,
the special needs annex, is particularly appropriate, since at best you
could get an SN annex for GC, and that would not in any case guarantee
that it would be on all compilers.

(b) If GC was really useful, then other vendors would be encouraged to do it.

The thing to remember here is that the major function of the special needs
annexes is to ensure that if there is a feature that will be implemented
by multiple vendors, then it should be implemented identically.

In other words, the really strong argument for a GC annex would be if
you now saw a situation in which lots of Ada 95 vendors were rushing to
implement GC in an incompatible manner. I don't see that happening yet :-)

Re: newbie Q: storage management

[Robert A Duff]

In article <dewar.862915787@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>In other words, the really strong argument for a GC annex would be if
>you now saw a situation in which lots of Ada 95 vendors were rushing to
>implement GC in an incompatible manner. I don't see that happening yet :-)

I agree with Robert here.  Look at the Real Time Annex: The idea was
that most of the Ada 83 vendors (or at least most of the ones who were
going after the real-time market) were providing more-or-less the same
functionality, but in incompatible ways.  The reason the RT annex was
invented, was to encourage compatibility.

In general, it is *not* the purpose a language standard to force
implementers to produce good products.  The purpose is to ensure
uniformity across implementations.  After all, the whole Ada standard is
completely optional -- if you want, you can write a compiler for an
Ada-like language that you think is "better" than Ada in some way.  Or
you can write a compiler for a subset of Ada.  The standard doesn't
force you to support all the features of Ada -- your customers with
money to spend are the ones doing the forcing.

So it would be inappropriate, and ineffective, to have a GC Annex that
somehow said "Thou shalt have GC" (even if one could produce a
precise-enough definition of what it means to "have GC").  The only
purpose of a GC annex would be to standardize whatever hooks there are
(such as procedures for turning it off and on, specifying how many
generations you want, and so forth).  But even within the GC community,
there are strong disagreements about what such hooks ought to look like
-- some people don't like generational GC, so what's that hook supposed
to mean?

- Bob

Re: newbie Q: storage management

[Jon S Anthony]

In article <E9rMAn.93B@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> In article <dewar.862915787@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> >In other words, the really strong argument for a GC annex would be if
> >you now saw a situation in which lots of Ada 95 vendors were rushing to
> >implement GC in an incompatible manner. I don't see that happening yet :-)
> 
> I agree with Robert here.  Look at the Real Time Annex: The idea was
> that most of the Ada 83 vendors (or at least most of the ones who were
> going after the real-time market) were providing more-or-less the same
> functionality, but in incompatible ways.  The reason the RT annex was
> invented, was to encourage compatibility.

This certainly makes good sense - at least from one perspective.


> In general, it is *not* the purpose a language standard to force
> implementers to produce good products.  The purpose is to ensure

Again, this makes good sense - at least up to a point.  But as you say
"in general".  Why even have generics?  Why have tasking?  Why have
packages?  All in a single language?  Certainly there are requirements
floating around here that were more than simply standardizing all the
implementations that were supposedly doing the same sort of thing in
some one language but just in incompatible ways.  Clearly there are
various things having to do with "good" that are not implementation
dependent.

How about the DSA?  How many Ada83 vendors were falling over
themselves trying to implement various distributed object scenarios??
Was there anyone doing this?  None of the ones I'm aware were.


> you can write a compiler for a subset of Ada.  The standard doesn't
> force you to support all the features of Ada -- your customers with
> money to spend are the ones doing the forcing.

Yes, this is definitely true.  But, you also have to recognize that if
something is not specifically called out, most people won't even think
it is _possible_.  So, it would not even occur to them that they could
request it.  How many customers do you think would even think of
asking for something like the DSA from their _compiler vendor_ if it
weren't called out as it is??


> purpose of a GC annex would be to standardize whatever hooks there are
> (such as procedures for turning it off and on, specifying how many
> generations you want, and so forth).  But even within the GC community,
> there are strong disagreements about what such hooks ought to look like
> -- some people don't like generational GC, so what's that hook supposed
> to mean?

True enough.  One obvious way out of this for Ada is the generalized
version of what Robert called out as a "compromise": a subsystem of
generics which offered several variants.  A single global GC handling
all dynamic memory issues isn't really needed.  In fact, this is an
area where Ada could do something a little different by offering the
ability to have multiple collectors per application targetting the
specific needs of specific types (or classes of types).  This is the
sort of thing that I've been working on.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: newbie Q: storage management

[John G. Volan]

Jon S Anthony wrote:
> 
> One obvious way out of this for Ada is the generalized
> version of what Robert called out as a "compromise": a subsystem of
> generics which offered several variants.  A single global GC handling
> all dynamic memory issues isn't really needed.  In fact, this is an
> area where Ada could do something a little different by offering the
> ability to have multiple collectors per application targetting the
> specific needs of specific types (or classes of types).  This is the
> sort of thing that I've been working on.

I'm very keen to see how true GC (not conservative GC) could be
shoehorned into Ada95 (other than by compiling to the Java virtual
machine).  One difficulty I'm having is seeing how Storage_Pools would
actually help.  It seems to me that, before you can collect the dead
objects in a given pool, you have to be able to locate and identify
every access value that currently points into that pool.  This might be
feasible, for instance, if access types behaved as if they were derived
from Controlled. But all that System.Storage_Pools seems to provide is a
way to define _how_ the designated objects are allocated and deallocated
-- but not _when_.

Looking forward to being edified... :-)

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: newbie Q: storage management

[Jon S Anthony]

In article <33720AA5.2E59@sprintmail.com> "John G. Volan" <johnvolan@sprintmail.com> writes:

> > One obvious way out of this for Ada is the generalized
> > version of what Robert called out as a "compromise": a subsystem of
> > generics which offered several variants.  A single global GC handling
> > all dynamic memory issues isn't really needed.  In fact, this is an
> > area where Ada could do something a little different by offering the
> > ability to have multiple collectors per application targetting the
> > specific needs of specific types (or classes of types).  This is the
> > sort of thing that I've been working on.
> 
> I'm very keen to see how true GC (not conservative GC) could be
> shoehorned into Ada95 (other than by compiling to the Java virtual
> machine).

Well, if you have compiler support this really should not be that much
of an issue.  Conservative collectors really live in a "hostile" world
where there is no compiler support and not much other information
either (no type information, for example).


> One difficulty I'm having is seeing how Storage_Pools would
> actually help.

Well, they help a bit in the internals and in allowing constraints to
be put on their access values.


> It seems to me that, before you can collect the dead objects in a
> given pool, you have to be able to locate and identify every access
> value that currently points into that pool.

Yup - you certainly do.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: newbie Q: storage management

[John G. Volan]

Jon S Anthony wrote:
> 
> In article <33720AA5.2E59@sprintmail.com> "John G. Volan" <johnvolan@sprintmail.com> writes:
> 
> > I'm very keen to see how true GC (not conservative GC) could be
> > shoehorned into Ada95 (other than by compiling to the Java virtual
> > machine).
> 
> Well, if you have compiler support this really should not be that much
> of an issue.  

Jon, does this mean that the stuff you're working on involves adding
some compiler support for GC? (Like, getting access types to behave like
Controlled types, so they can register themselves as roots?)  I guess I
should have asked the question directly: How exactly are you planning to
achieve this GC support?  (If the answer is "I'd like to keep my cards
close to the vest right now until it's done and I get my money for it",
well, that's cool, but just say so.)

Barring compiler support, it's fairly obvious that one could implement
"smart references" in Ada95 using a Controlled type wrapped around an
access type.  (Clearly, this is how reference-counting schemes have been
implemented in Ada95 already.)  The Initialize, Adjust, and Finalize for
these "smart references" could make sure that every reference registered
itself with the collector.  I can see that this combined with
Storage_Pools could provide a complete GC mechanism.  But it would
require programmer discipline: A programmer would have to make sure to
always wrap every access value into one of these "smart references." 
Some potential for human error there.

> Conservative collectors really live in a "hostile" world
> where there is no compiler support and not much other information
> either (no type information, for example).

So from this should I infer that your GC support will exploit type
information?  Hmm, I figured meta-data would have to come into the
picture sometime.

> > It seems to me that, before you can collect the dead objects in a
> > given pool, you have to be able to locate and identify every access
> > value that currently points into that pool.
> 
> Yup - you certainly do.

So is this what your stuff is going tot do?

------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "johnvolan@sprintmail.com",
   Slogan => "Ada95: The World's *FIRST* International-Standard OOPL",
   Disclaimer => "These opinions were never defined, so using them " & 
     "would be erroneous...or is that just nondeterministic now? :-) ");
------------------------------------------------------------------------

Re: newbie Q: storage management

[Jon S Anthony]

In article <33740D4A.5BE1@sprintmail.com> "John G. Volan" <johnvolan@sprintmail.com> writes:

> Jon S Anthony wrote:
> > 
> > In article <33720AA5.2E59@sprintmail.com> "John G. Volan" <johnvolan@sprintmail.com> writes:
> > 
> > > I'm very keen to see how true GC (not conservative GC) could be
> > > shoehorned into Ada95 (other than by compiling to the Java virtual
> > > machine).
> > 
> > Well, if you have compiler support this really should not be that much
> > of an issue.  
> 
> Jon, does this mean that the stuff you're working on involves adding
> some compiler support for GC?

No.  No compiler support.  I've mentioned elsewhere that hacking this
into GNAT would not be a reasonable use of (my) time.


> should have asked the question directly: How exactly are you planning to
> achieve this GC support?  (If the answer is "I'd like to keep my cards
> close to the vest right now until it's done and I get my money for it",
> well, that's cool, but just say so.)

Close to the vest for the moment, but mostly because I do not want to
oversell the case or miss a T-crossing or I-dotting.  I have a couple
variants which are now working, but which I am trying to refine wrt to
both time and space (including reference locality issues and possible
paging concerns and such).  And there are several other variants and
issues to consider (incremental stuff in particular).

Besides, Robert claims there is positively, absolutely, beyond a
shadow of any conceivable doubt, no money in this.  :-) :-)


> Barring compiler support, it's fairly obvious that one could implement
> "smart references" in Ada95 using a Controlled type wrapped around an
> access type.  (Clearly, this is how reference-counting schemes have been
> implemented in Ada95 already.)  The Initialize, Adjust, and Finalize for
> these "smart references" could make sure that every reference registered
> itself with the collector.  I can see that this combined with
> Storage_Pools could provide a complete GC mechanism.  But it would
> require programmer discipline: A programmer would have to make sure to
> always wrap every access value into one of these "smart references." 
> Some potential for human error there.

First, this is just waaaayyyy tooooo expensive in time and space.
Secondly, as you say it is not particularly "safe".  I wanted simple
pointers and safety of use - gurantees of consistency and such - and
have managed to get this except for a pathological case where safety
can be accidently circumvented.  The only way to ensure that this
can't happen would require access to the stack and frame pointers and
that's not portable (which is a prime requirement).


> So from this should I infer that your GC support will exploit type
> information?  Hmm, I figured meta-data would have to come into the
> picture sometime.

Yes - but not in any magical way.


> > > It seems to me that, before you can collect the dead objects in a
> > > given pool, you have to be able to locate and identify every access
> > > value that currently points into that pool.
> > 
> > Yup - you certainly do.
> 
> So is this what your stuff is going tot do?

Absolutely!  All the variants I am considering are tracing collectors
of various sorts - which means you have to have the roots...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: newbie Q: storage management

[Robert Dewar]

<<Besides, Robert claims there is positively, absolutely, beyond a
shadow of any conceivable doubt, no money in this.  :-) :-)>>

My goodness, I never said anything of the kind. I think that all sorts
of tools can be sold to people who want them. I can tell you dozens of
potentially interesting things that could make money. What I said was
something totally different. I said that none of our current customers
had mentioned GC as something that they wanted from us. They have many
other things they *do* want, and we are busy working on those!

Re: newbie Q: storage management

[Robert A Duff]

In article <JSA.97May7204713@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
>> In general, it is *not* the purpose a language standard to force
>> implementers to produce good products.  The purpose is to ensure
>
>Again, this makes good sense - at least up to a point.  But as you say
>"in general".

Yes, up to a point.

Actually, I'm not sure what "in general" really means.  Maths folks
seem to use it to mean "always", but regular folks seem to use it to
mean "in the usual case".

>...  Why even have generics?  Why have tasking?  Why have
>packages?  All in a single language?

Well, if you'll let me stretch this point further, I'll answer: We have
those features purely because if we didn't, we couldn't standardize
their syntax and semantics.  I mean, if you want tasking, but you don't
care about portability, use Joe Schmoe's fancy threads package -- maybe
it's even better than Ada tasking.  E.g., it would be "better" in some
sense, for an implementer to support "type T is task..." rather than
"task type T is...".  The former syntax is clearly more uniform with the
rest of the language.  The RM says, no, you have to do it the way we
say, or else it ain't Ada.  The RM doesn't say, "Thou shalt have a good
syntax for task types."  It says, "Thou shalt have this particular
syntax, for better or worse."

I admit I'm stretching the point. ;-)

>...  Certainly there are requirements
>floating around here that were more than simply standardizing all the
>implementations that were supposedly doing the same sort of thing in
>some one language but just in incompatible ways.  Clearly there are
>various things having to do with "good" that are not implementation
>dependent.

Sure (still stretching) -- if we're going to standardize on something,
we might as well make it "good".  That doesn't mean "goodness" is the
basic purpose of the standard.

>How about the DSA?  How many Ada83 vendors were falling over
>themselves trying to implement various distributed object scenarios??
>Was there anyone doing this?  None of the ones I'm aware were.

I'm aware of two attempts to do distribution in Ada 83: The Software
Leverage run-time, and I think Verdix did something-or-other.  So it's
not completely new stuff (in the DS annex).

>> you can write a compiler for a subset of Ada.  The standard doesn't
>> force you to support all the features of Ada -- your customers with
>> money to spend are the ones doing the forcing.
>
>Yes, this is definitely true.  But, you also have to recognize that if
>something is not specifically called out, most people won't even think
>it is _possible_.  So, it would not even occur to them that they could
>request it.  How many customers do you think would even think of
>asking for something like the DSA from their _compiler vendor_ if it
>weren't called out as it is??

Well, maybe.

On the other hand, during Ada 9X, there was a lot of, "better not nail
down so-and-so, or some compiler customer will demand it, despite the
fact that said customer doesn't need it, and wouldn't use it".

>> purpose of a GC annex would be to standardize whatever hooks there are
>> (such as procedures for turning it off and on, specifying how many
>> generations you want, and so forth).  But even within the GC community,
>> there are strong disagreements about what such hooks ought to look like
>> -- some people don't like generational GC, so what's that hook supposed
>> to mean?
>
>True enough.  One obvious way out of this for Ada is the generalized
>version of what Robert called out as a "compromise": a subsystem of
>generics which offered several variants.  A single global GC handling
>all dynamic memory issues isn't really needed.  In fact, this is an
>area where Ada could do something a little different by offering the
>ability to have multiple collectors per application targetting the
>specific needs of specific types (or classes of types).  This is the
>sort of thing that I've been working on.

I'm very much looking forward to seeing what you've done (will it be
public?) but I must say I'm skeptical.  All the GC folks say, "GC is a
global problem", and I tend to agree.  I mean, if so-and-so- pool is
GC'ed, you still have to find all the pointers into it.

- Bob

Re: newbie Q: storage management

[Brian Rogoff]

On Fri, 9 May 1997, Robert A Duff wrote:
> In article <JSA.97May7204713@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
> >> purpose of a GC annex would be to standardize whatever hooks there are
> >> (such as procedures for turning it off and on, specifying how many
> >> generations you want, and so forth).  But even within the GC community,
> >> there are strong disagreements about what such hooks ought to look like
> >> -- some people don't like generational GC, so what's that hook supposed
> >> to mean?
> >
> >True enough.  One obvious way out of this for Ada is the generalized
> >version of what Robert called out as a "compromise": a subsystem of
> >generics which offered several variants.  A single global GC handling
> >all dynamic memory issues isn't really needed.  In fact, this is an
> >area where Ada could do something a little different by offering the
> >ability to have multiple collectors per application targetting the
> >specific needs of specific types (or classes of types).  This is the
> >sort of thing that I've been working on.
> 
> I'm very much looking forward to seeing what you've done (will it be
> public?) but I must say I'm skeptical.  All the GC folks say, "GC is a
> global problem", and I tend to agree.  I mean, if so-and-so- pool is
> GC'ed, you still have to find all the pointers into it.
> 
> - Bob

I've seen some similar ideas from the C++ community for a number of years,
so I think Jon's suggestions have merit. There are a number of collectors, 
of various levels of transparency, which can be accessed from 

	http://stork.ukc.ac.uk/computer_science/Html/Jones/gc.html

one of them, Cmm (ftp://ftp.di.unipi.it/pub/project/posso/cmm/) seems to 
be similar to what Jon is describing for Ada. There are also proposals on
how to make C++ "GC friendly" without changing it too much; since Ada is 
similar some of the same considerations apply. 

-- Brian

Re: newbie Q: storage management

[Robert A Duff]

In article <Pine.SGI.3.95.970509120443.10301B-100000@shellx.best.com>,
Brian Rogoff  <bpr@shellx.best.com> wrote:
>... There are also proposals on
>how to make C++ "GC friendly" without changing it too much; since Ada is 
>similar some of the same considerations apply. 

Ada is already pretty GC friendly, as compared to C++.

- Bob

Re: newbie Q: storage management

[Jon S Anthony]

In article <E9w2oL.Hu7@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> In article <JSA.97May7204713@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
> >> In general, it is *not* the purpose a language standard to force
> >> implementers to produce good products.  The purpose is to ensure
> >
> >Again, this makes good sense - at least up to a point.  But as you say
> >"in general".
> 
> Yes, up to a point.
> 
> Actually, I'm not sure what "in general" really means.  Maths folks
> seem to use it to mean "always", but regular folks seem to use it to
> mean "in the usual case".

Good point.  I try to use the phrase "in general" to be "in the usual
case" and specifically call out always (or every or some other
appropriate universal).  So, I think we are in synch. here.


> >...  Why even have generics?  Why have tasking?  Why have
> >packages?  All in a single language?
> 
> Well, if you'll let me stretch this point further, I'll answer: We have
<...>
> I admit I'm stretching the point. ;-)

Check.  Definitely stretching! :-)  But I see what you're after...


> >...  Certainly there are requirements
> >floating around here that were more than simply standardizing all the
> >implementations that were supposedly doing the same sort of thing in
> >some one language but just in incompatible ways.  Clearly there are
> >various things having to do with "good" that are not implementation
> >dependent.
> 
> Sure (still stretching) -- if we're going to standardize on something,
> we might as well make it "good".  That doesn't mean "goodness" is the
> basic purpose of the standard.

Check.  That is not the purpose of the standard.  It is (or should be)
a primary "meta" goal of the design (which the standard is intended to
capture in enough public explicit detail that it can be communicated
with few [preferably no] misunderstanding to the "appropriate"
audience").  By "meta" goal I mean "quality of service" goal - *not*
functional goal.  A QOS kind of goal is typically an "ility" or "ness"
sort of thing.


> I'm aware of two attempts to do distribution in Ada 83: The Software
> Leverage run-time, and I think Verdix did something-or-other.  So it's
> not completely new stuff (in the DS annex).

Interesting.  Is/was SL an Ada compiler vendor?  Or some one doing an
add on capability?  Second doesn't count.


> On the other hand, during Ada 9X, there was a lot of, "better not nail
> down so-and-so, or some compiler customer will demand it, despite the
> fact that said customer doesn't need it, and wouldn't use it".

Wow.  Interesting.


> >True enough.  One obvious way out of this for Ada is the generalized
> >version of what Robert called out as a "compromise": a subsystem of
> >generics which offered several variants.  A single global GC handling
> >all dynamic memory issues isn't really needed.  In fact, this is an
> >area where Ada could do something a little different by offering the
> >ability to have multiple collectors per application targetting the
> >specific needs of specific types (or classes of types).  This is the
> >sort of thing that I've been working on.
> 
> I'm very much looking forward to seeing what you've done (will it be
> public?) but I must say I'm skeptical.  All the GC folks say, "GC is a
> global problem", and I tend to agree.  I mean, if so-and-so- pool is
> GC'ed, you still have to find all the pointers into it.

One should always be skeptical :-)

Yes, GC is certainly global in the sense that you have to find all the
roots and my approach certainly does this.  If it didn't, it would
indeed be worthless.  GC is not global in the sense that all objects
(objects of all types) are potential roots.  That is, potential roots
can be type specific.  As soon as you have that, you can have multiple
collectors (of possibly different kinds) and mix both GC'd things and
non GC'd things in a single application.

I would like this stuff to be "public".  The need was sparked by the
product we are focusing on having a rather "stunning" amount of
interconnections.  The work has been driven by research into design
alternative modeling, functional representation, and domain and
rationale modeling.  And a healthy dose of just plain old pragmatic
"wants".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: newbie Q: storage management

[Robert A Duff]

In article <JSA.97May9171656@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
>Interesting.  Is/was SL an Ada compiler vendor?  Or some one doing an
>add on capability?  Second doesn't count.

Software Leverage is a small software house that at that time was
selling Ada compilers (derived from Verdix sources, mostly) for, for
example, Sequent Symmetry, AMETEK (I can't remember the name of it but
it was sort of hyper-cube-like distributed) machine, VxWorks, etc. --
i.e. various sorts of specialty products.  They did a distributed
tasking run-time system.  I'm not sure if that qualifies as the first or
second (above), and I'm not sure why the second "doesn't count".
S.L. also worked on an Ada compiler for the Symbolics Lisp Machine (and,
of course it did garbage collection -- it couldn't easily do
otherwise!).

- Bob

Re: newbie Q: storage management

[Jon S Anthony]

In article <E9xz6E.Ino@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> Software Leverage is a small software house that at that time was
> selling Ada compilers (derived from Verdix sources, mostly) for, for
> example, Sequent Symmetry, AMETEK (I can't remember the name of it but
> it was sort of hyper-cube-like distributed) machine, VxWorks, etc. --

Thanks for the info.

> S.L. also worked on an Ada compiler for the Symbolics Lisp Machine (and,
> of course it did garbage collection -- it couldn't easily do
> otherwise!).

Hmmm, so SL would count as much for GC as DSA...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: newbie Q: storage management

[Robert Dewar]

Jon said

<<Yes, this is definitely true.  But, you also have to recognize that if
  something is not specifically called out, most people won't even think
  it is _possible_.  So, it would not even occur to them that they could
  request it.  How many customers do you think would even think of
  asking for something like the DSA from their _compiler vendor_ if it
  weren't called out as it is??>>

If no customers would even think of asking for something, it does not
*begin* to belong in the standard. However, DSA is of course not in this
category. Lots of Ada users know very well they need this kind of
capability, and there have been several more or less successful attempts
to provide this capability. The DSA did not appear out of the blue in
Ada 95, it appeared because there was indeed a consensus recognition that
this was an important problem that needed a solution.

The issue was not whether the facility was needed, the answer to that for
a significant number of applications is of course yes, and you can be sure
customers know it. The issue is whether enough was known to usefully
standardize it.

Sure there may be customers who don't know all the details of what they
want or need, and part of the job of a vendor is to help them figure out
these details, but in my experience, 
Jon's scenario of clueless customers who don't have any idea of what
is going on is certainly not the norm!

Re: newbie Q: storage management

[Robert Dewar]

Jon asks

<<Again, this makes good sense - at least up to a point.  But as you say
 "in general".  Why even have generics?>>
   
  Because there was consensus agreement that this was a critical feature

<<Why have tasking?>>

  Because there was consensus agreement that this was a critical feature

<<Why have packages?>>

  Because there was consensus agreement that this was a critical feature

  The whole point is that no such consensus existed for the idea of GC, not
  even a noticable minority opinion, hence it was just not on the radar
  screen. And this was not because it was ignored, it was because the great
  majority actively opposed the idea, and there was no significant input
  from anyone to the contrary (look for example through the revision
  requests ...)

<<How about the DSA?  How many Ada83 vendors were falling over
  themselves trying to implement various distributed object scenarios??>>

  A fair question, the DSA only *just* survived the process, and the
  discussion was exactly along the lines of wondering whether we were
  sure that we knew enough to specify the approach. However, unlike the
  case with GC, the clear majority *did* feel that this was a critical
  feature which should be addressed. The discussion was not over whether
  the language should have such features, but whether the formulation
  was correct. We did not even get that far with GC.

<<True enough.  One obvious way out of this for Ada is the generalized
version of what Robert called out as a "compromise": a subsystem of
generics which offered several variants.  A single global GC handling
all dynamic memory issues isn't really needed.  In fact, this is an
area where Ada could do something a little different by offering the
ability to have multiple collectors per application targetting the
specific needs of specific types (or classes of types).  This is the
sort of thing that I've been working on.>>

  Actually, I prefer an approach with single global GC handling, but in
  any case, clearly the constructive thing at this stage is to produce
  sample implementations and encourage users to use them!

Re: newbie Q: storage management

[Jon S Anthony]

In article <dewar.863177058@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Jon asks
> 
> <<Again, this makes good sense - at least up to a point.  But as you say
>  "in general".  Why even have generics?>>
>    
>   Because there was consensus agreement that this was a critical feature
> 
> <<Why have tasking?>>
> 
>   Because there was consensus agreement that this was a critical feature
> 
> <<Why have packages?>>
> 
>   Because there was consensus agreement that this was a critical feature

You completely missed the point of this.  Bob got it, but had another
take on it.  You should read those replies.


>   The whole point is that no such consensus existed for the idea of GC, not
>   even a noticable minority opinion, hence it was just not on the radar

Yes, but that was not the point.


> <<True enough.  One obvious way out of this for Ada is the generalized
> version of what Robert called out as a "compromise": a subsystem of
> generics which offered several variants.  A single global GC handling
> all dynamic memory issues isn't really needed.  In fact, this is an
> area where Ada could do something a little different by offering the
> ability to have multiple collectors per application targetting the
> specific needs of specific types (or classes of types).  This is the
> sort of thing that I've been working on.>>
> 
>   Actually, I prefer an approach with single global GC handling, but in
>   any case, clearly the constructive thing at this stage is to produce
>   sample implementations and encourage users to use them!

Check!

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: newbie Q: storage management

[Kevin Cline]

"Samuel A. Mize" <smize@magellan.bgm.link.com> wrote:

>True for most applications.  The requirements were written so that a
>vocal minority could get validated compilers.  (In all fairness,
>they were the supposed target group for the language, originally.
>Ada rapidly evolved to serve a larger audience.)

Evidently not rapidly enough, since that audience never showed up.

Re: newbie Q: storage management

[Robert Dewar]

Kevin Cline said

<<Evidently not rapidly enough, since that audience never showed up>>

That's wrong. I guess if Kevin's criterion for success is to achieve
universal dominance (say as Visual Basic has done in the PC development
area), then this audience did not show up.

But a substantial audience has shown up, and the use of Ada is wider
than many people imagine (usually statements like the ones from Kevin
are based on prejudice rather than data). For examle, the survey that
JPR reprinted shows substantial Ada use.

An interesting comparison is to look at the proportion of the OS market
held by Unix, and the proportion of the programming language market held
by Ada. The former is of course much smaller, and yet Unix remains a
significant force, and is likely to be one for a while (even in the
context of the NT blitz, Unix will remain a major player, for example,
in the form of Open/NT).

These days, people often tend to regard a product as a failure if it
does not achieve massive Microsoft-style domination. For example, OS/2
is a failure (wrong, millions of users of OS/2 find it essential, and IBM
continues to fully support it), the Mac is a failure because only 10% of
users use it (never mind that the total number is in the tens of millions),
Delphi is a failure (because only 5% of PC applications use it -- but
go visit the Borland page describing Delphi applications in real life --
Ada would be happy to have such a page), etc. etc. etc.

Of course it is a concern that if Ada has only a small part of the market,
then how will the necessary tools etc appear. That to me is one of the strong
arguments for GNAT. The open systems approach of GNAT means that it is much
easier for GNAT to take advantage of developments for other languages and
systems, and in fact GNAT continues to make rapid progress despite the fact
that ACT is quite a bit smaller than Microsoft :-)

A little note on that progress. Mark V systems announced a new product at
STC that does Ada Diagramming. The exciting thing for us is that this is
the first example of an ASIS application for GNAT developed and marketed
by a third party, quite independent of ACT. One of our objectives in
putting substantial resources into the ASIS development was in the hope that
such applications would appear, so it is nice to see that happening! So far
Mark V has not been able to port this to other Ada 95 compilers, but hopefully
in the future other Ada 95 technologies will develop comarable ASIS interfaces
that will allow such tools to be compiler independent.

Robert Dewar
Ada Core Technologies

Re: newbie Q: storage management

[Samuel A. Mize]

I wrote:
> It just means you should know what you're doing in two areas:
> 1) Make sure the logic of your code avoids using dangling references.
> 2) If memory reclamation is important for your application, make sure that
>    the implementation supports it.
> 3) If your program is large or long-lived enough for memory leakage to be
>    a problem, make sure you deallocate objects when done with them.  (In
>    this case, (2) definitely applies.)

This isn't a Three Stooges routine ("pick two!"), you have to be careful
in THREE areas.


> Sam Mize
> 
> -- Samuel Mize           (817) 619-8622               "Team Ada"
> -- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

-- Samuel Mize           (817) 619-8622               "Team Ada"
-- Hughes Training Inc.  PO Box 6171 m/s 400, Arlington TX 76005

Re: newbie Q: storage management

[Robert Dewar]

Sam said

<<> 1) Make sure the logic of your code avoids using dangling references.
> 2) If memory reclamation is important for your application, make sure that
>    the implementation supports it.
> 3) If your program is large or long-lived enough for memory leakage to be
>    a problem, make sure you deallocate objects when done with them.  (In
>    this case, (2) definitely applies.)>>

You really do not have to worry about 2). There has never been an Ada 83
or Ada 95 compiler that did not support unchecked deallocation for the global
heap, so there is nothng that you need to make sure of here. You can 
freely instantiate Unchecked_Deallocation on library level access types.

For access types at a local level, the situation has been less uniform.
Compilers with all the following behaviors have existsed:

1. All objects automatically freed on scope exit, explicit unchecked
   deallocation ignored.

2. All objects automatically freed on scope exit, but unchecked deallocation
   can be used to free them earlier.

3. No automatic free on scope exit, but unchecked deallocation works fine.

For examples, Alsys-386 (case 1)  Alsys-SPARC (case 2)  GNAT (case 3)

Of course in the GNAT case, we are are talking about default behavor,
since this is Ada 95, alternative storage pools can be specified to get
a behavior different from the default.

Re: newbie Q: storage management

[Marinus van der Lugt]

Kaz Kylheku wrote:

> Whose responsibility is it to destroy these objects? The Ada 95 standard

It is the programmers resposibility.

> says that an implementation is permitted to implement garbage collection,
> but not required to do so.

Garbage collection is the process that concatenates already
deallocated area's into one big area so memory does not get fragmented.

> I know that it is possible to instantiate a generic freeing function for
> explicitly destroying objects. But why is there is this lack of symmetry in the
> language?  On the one hand, you have a slick ``new''-expression to create
> objects, but the complementary deletion operation is totally obscured. Does

Well, everybody is entitled to his or hers opinion.

> this mean that explicit freeing of objects via an instance of
> Unchecked_Deallocation is discouraged (due to the potential creation of

No. I don't know why it is called 'unchecked'_deallocation, but maybe it
is done
so you know that _YOU_ are responsible.

> dangling references)? Is it the reponsibility of the language implementation to
> automagically detect when an object is no longer reachable and do the
> appropriate deallocation, even if garbage is not collected?

No, see above.

Hope this helps,
Rien

Re: newbie Q: storage management

[Jon S Anthony]

In article <33673929.F5D@space-elec.dofn.de> Marinus van der Lugt <lugt@space-elec.dofn.de> writes:

> Kaz Kylheku wrote:
> 
> > Whose responsibility is it to destroy these objects? The Ada 95 standard
> 
> It is the programmers resposibility.

Not necessarily.  The RM certainly suggests that impls. with GC would
be nice to have.  Manual stuff is actually the thing "denegrated".


> Garbage collection is the process that concatenates already
> deallocated area's into one big area so memory does not get
> fragmented.

No, GC is what automatically determines dead stuff and once again
makes it available for use.  This may or may not compact or coalesce
this space.

> > this mean that explicit freeing of objects via an instance of
> > Unchecked_Deallocation is discouraged (due to the potential creation of
> 
> No. I don't know why it is called 'unchecked'_deallocation, but maybe it

Actually, I think Kaz is spot on with this.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: newbie Q: storage management

[Robert Dewar]

<<> No. I don't know why it is called 'unchecked'_deallocation, but maybe ..>>

It is called unchecked_deallocation because it is possible to make incorrect
calls that result in erroneous execution, and there are no checks rquired
to prevent this.

Re: newbie Q: storage management

[Robert I. Eachus]

In article <5k5hif$7r5@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

  > I've looked at the ISO standard and the relevant FAQ's and
  > tutorials, but I still need some discussion or clarification about
  > the management of objects obtained via ``new'', because what I
  > have read so far seemed rather vague in one respect.

  > Whose responsibility is it to destroy these objects? The Ada 95
  > standard says that an implementation is permitted to implement
  > garbage collection, but not required to do so.

    The rules are difficult to understand, but are "in there."
Basically, the compiler/run-time is required to reclaim the storage if
the scope of the type declaration is left, except to tasks, the type
Ada.Strings.Unbounded.Unbounded_String, and for types for which the
pragma Controlled applies.

  > I know that it is possible to instantiate a generic freeing
  > function for explicitly destroying objects. But why is there is
  > this lack of symmetry in the language?  On the one hand, you have
  > a slick ``new''-expression to create objects, but the
  > complementary deletion operation is totally obscured.

    In general, this asymmetry reflects the domain for which Ada was
originally intended.  Most safety-critical emebedded systems used to
be designed with a rule that all allocations were done once at
start-up so nothing was ever freed.  Also in real-time systems you
can't just shut down to do garbage collection at random times.  There
are real-time garbage collection algorithms now, but just using Ada
controlled types in a real-time system is enough of a headache.

   In more modern Ada embedded systems (and in non-embedded systems),
allocations at any time are allowed.  But trusting the user of an
abstraction to know how and when to deallocate things is tricky.  So
the usual is to hide the deallocation inside the abstraction anyway.

  > Does this mean that explicit freeing of objects via an instance of
  > Unchecked_Deallocation is discouraged (due to the potential
  > creation of dangling references)?

   No, it means that the name is intended to warn the programmer that
dangling references are his or her responsibility.  The idea was that
the programmer instantiates Unchecked_Deallocation, then wraps the
call in whatever checks he or she knows are required, thus creating a
checked deallocation routine.

  > Is it the reponsibility of the language implementation to
  > automagically detect when an object is no longer reachable and do
  > the appropriate deallocation, even if garbage is not collected?

   Only for types derived from Unbounded_String, Controlled,
Limited_Controlled, and types derived from them.  For types derived
from Controlled or Limited_Controlled, you or whoever creates the type
needs to pay attention to storage reclamation when defining Finalize,
and the compiler will do the rest.  This usually amounts to four or
five lines of code.  Every once in a while I think about defining a
"Managed" type derived from Controlled or Limited_Controlled, but it
doesn't seem worth the effort.

    For instance, here is a list abstraction with storage management.
The reason I didn't use an "off-the-shelf" implementation was that I
wanted part of the abstraction to be getting the contents of the list
as an array.  How much of the abstraction is devoted to storage
management?  Less than ten lines, and the bulk of that is freeing list
elements in the right order.  (I could have made List_Element a
controlled type as well, simplifying the code for Empty but adding
complexity elsewhere.  This approach seemed cleaner and more
efficient.)

    (Flame retardant: I deleted lots of comments and blank lines, and
put some loops and if statements on a single line to include these
files here.  Not my usual style. ;-)

with Ada.Finalization;
generic
  type Element is private;
  type Element_Array is array (Positive range <>) of Element;
package Lists is

  type List is new Ada.Finalization.Controlled with private;
  function Length(L: List) return Integer;
  procedure Append(L: in out List; E: in Element);
  procedure Prepend(L: in out List; E: in Element);
  function Contents(L: in List) return Element_Array;
  procedure Empty(L: in out List);

private

  type List_Element;
  type Pointer is access List_Element;
  type List is new Ada.Finalization.Controlled with record
    LP: Pointer;
  end record;
  type List_Element is record
     Value: Element;
     Next:  Pointer;
  end record;
  procedure Finalize(Object: in out List);

end Lists;

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

with Unchecked_Deallocation;
package body Lists is

  procedure Free is new Unchecked_Deallocation(List_Element,Pointer);

  function Length(L: List) return Integer is
     Count: Integer := 0;
     Temp: Pointer := L.LP;
  begin
     while Temp /= null loop
       Temp := Temp.Next;
       Count := Count + 1;
     end loop;
     return Count;
  end Length;

  procedure Append(L: in out List; E: in Element) is
     Temp: Pointer := L.LP;
  begin
     if Temp = null then L.LP := new List_Element'(E,null); return; end if;
     while Temp.Next /= null loop Temp := Temp.Next; end loop;
     Temp.Next := new List_Element'(E,null);
     return;
  end Append;

  procedure Prepend(L: in out List; E: in Element) is
  begin L.LP := new List_Element'(E,L.LP); end;

  function Contents(L: in List) return Element_Array is
    EA: Element_Array(1..Length(L));
    Temp: Pointer := L.LP;
  begin
    for I in EA'Range loop EA(I) := Temp.Value; Temp := Temp.Next; end loop;
    return EA;
  end Contents;
 
  procedure Empty(L: in out List) is
    Temp: Pointer := L.LP;
  begin
    while Temp /= null loop 
      Free(L.LP);
      Temp := Temp.Next;
      L.LP := Temp;
    end loop;
  end Empty;

  procedure Finalize(Object: in out List) is
  begin Empty(Object); end Finalize;

end Lists;

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

					Robert I. Eachus

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

Re: newbie Q: storage management

[Jon S Anthony]

In article <5k5hif$7r5@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

> I've looked at the ISO standard and the relevant FAQ's and tutorials, but I
> still need some discussion or clarification about the management of objects
> obtained via ``new'', because what I have read so far seemed rather vague in
> one respect.
> 
> Whose responsibility is it to destroy these objects? The Ada 95 standard
> says that an implementation is permitted to implement garbage collection,
> but not required to do so.

Right.  So, in actual fact it is implementation dependent.  If the
implementation provides GC, then you can forget about it.  If not, you
have to do something about it yourself.  The most typical thing is to
use manual deallocation via "Unchecked_Deallocation".  At the moment,
I know of only two cases where GC is provided: Intermetrics and Aonix
Ada->Java compilers (each of which avail themselves of the Java VM
GC).

I'm working on a set of GC subsystems providing a range of generic GC
variants which will allow you to create various collectors (various
versions of mark-sweep, mark-compact, copying, generational,
concurrent, treadmill, etc.) for your supplied type(s).  This has its
ups and downs wrt implementation provided GC and bolt on conservative
collectors.  The biggest down is a certain lack of transparency for
the user - though you can in fact get pretty close to a natural style,
maintain safety, be very flexible about it, and supply high time
efficiency (yes, I know this is hard to believe, and it took a lot of
head scratching to get there).  Space efficiency is not so good for
the more general cases (typically 8 bytes of overhead - making these
variants poor for things like CONS cells or some such).  Special cases
are needed for strings and CONS cells (as these are just too useful
and ubiquitous to ignore).

I can't say for sure when all this will be ready, but probably some
time this summer.


> I know that it is possible to instantiate a generic freeing function
> for explicitly destroying objects. But why is there is this lack of
> symmetry in the language?

Basically, this asymmetry is there because the designers did not think
they could "require" GC (at least at the level of the high expectation
of it for things like Lisp, Eiffel, ST, etc.) because many of the
target areas of use would not need (or even require _not_ having) GC.
But, the designers (especially Ada83) really were GC adherents, so
they compromised and suggested that GC would be a very good thing for
implementations to provide, but had to leave the door open for
impls. only supplying manual deallocation.

> On the one hand, you have a slick ``new''-expression to create
> objects, but the complementary deletion operation is totally
> obscured.

Actually, it is not obscured enough! :-) I mean if you had GC you
don't even _have_ such an operation in the programmers model.


> Does this mean that explicit freeing of objects via an instance of
> Unchecked_Deallocation is discouraged (due to the potential creation
> of dangling references)?

Oddly enough, this is indeed the implication.  That's even why the
thing is called "unchecked" (connoting something a bit dodgy).


> Is it the reponsibility of the language implementation to
> automagically detect when an object is no longer reachable and do
> the appropriate deallocation, even if garbage is not collected?

Not in any formal sense - i.e., there is nothing in the RM that
suggests that an implementation really should have GC or its just a
lame implementation.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: newbie Q: storage management

[Robert Dewar]

Jon answers Kaz:

<<> I know that it is possible to instantiate a generic freeing function
> for explicitly destroying objects. But why is there is this lack of
> symmetry in the language?

Basically, this asymmetry is there because the designers did not think
they could "require" GC (at least at the level of the high expectation
of it for things like Lisp, Eiffel, ST, etc.) because many of the
target areas of use would not need (or even require _not_ having) GC.
But, the designers (especially Ada83) really were GC adherents, so
they compromised and suggested that GC would be a very good thing for
implementations to provide, but had to leave the door open for
impls. only supplying manual deallocation.>>>


Jon, I don't think this is the right answer, you are focussing too much
on GC, but the question was not about GC, it was about the asymmetry
(i.e. new is a straight forward primitive, free rquires a messy
instantiation).

In fact the assymetry is quite deliberate, and reflects the fact that
new is safe (cannot result in erroneous execution), but free is dangerous
(and can easily result in erroneous execution if misused).

Re: newbie Q: storage management

[Kaz Kylheku]

In article <dewar.862625257@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Jon answers Kaz:
>
><<> I know that it is possible to instantiate a generic freeing function
>> for explicitly destroying objects. But why is there is this lack of
>> symmetry in the language?
>
>Basically, this asymmetry is there because the designers did not think
>they could "require" GC (at least at the level of the high expectation
>of it for things like Lisp, Eiffel, ST, etc.) because many of the
>target areas of use would not need (or even require _not_ having) GC.
>But, the designers (especially Ada83) really were GC adherents, so
>they compromised and suggested that GC would be a very good thing for
>implementations to provide, but had to leave the door open for
>impls. only supplying manual deallocation.>>>
>
>
>Jon, I don't think this is the right answer, you are focussing too much
>on GC, but the question was not about GC, it was about the asymmetry
>(i.e. new is a straight forward primitive, free rquires a messy
>instantiation).
>
>In fact the assymetry is quite deliberate, and reflects the fact that
>new is safe (cannot result in erroneous execution), but free is dangerous
>(and can easily result in erroneous execution if misused).

Yes, that's all I really wanted to know, and I suspected as much.

It's perfectly clear that since a conforming Ada implementation is not required
to supply GC, a maximally portable Ada program cannot rely on its presence. It
would be foolhardy to write a program that expects the implementation to locate
unreachable objects and reclaim them, when the language doesn't require the
facility.

Re: newbie Q: storage management

[Robert Dewar]

Kaz says

<<to supply GC, a maximally portable Ada program cannot rely on its presence. It
would be foolhardy to write a program that expects the implementation to locate
unreachable objects and reclaim them, when the language doesn't require the
facility.>>


Actually the issue is not so much what the language requires (as I explained
in a previous post, it is hard to require GC in any formal sense). What is
important is what you wll actually find out there.

As an example, consider the following. There is nothing in the Ada RM that
requires a implementation to support more than one digit of precision for
floating-point. This means that, by the same reasoning as Kaz is using
above, a maximally portable Ada program should not have a declaration like

   type x is digits 6;

However, in the real world, no one knows any Ada implemnetation where
Max_Digits is less than 6, so the above declaration is in practice
entirely portable, even though not blessed by the language.

On the other hand, you cannot get much of a hint from the RM that the
declaration

   type x (y : integer := 0) is record
     q : string (1 .. y);
   end record;

is problematic, and indeed it will work on some implementations. But if
you know the real world of Ada implemntations, then you will know that
the above variant record declaration is not a good idea, and will cause
unexpected storage errors on some (most?) Ada 95 implementations.

Re: newbie Q: storage management

[Nick Roberts]

Kaz Kylheku <kaz@vision.crest.nt.com> wrote in article
<5k5hif$7r5@bcrkh13.bnr.ca>...
> I've looked at the ISO standard and the relevant FAQ's and tutorials, but
I
> still need some discussion or clarification about the management of
objects
> obtained via ``new'', because what I have read so far seemed rather vague
in
> one respect.
> 
> Whose responsibility is it to destroy these objects? The Ada 95 standard
> says that an implementation is permitted to implement garbage collection,
> but not required to do so.
> 
> I know that it is possible to instantiate a generic freeing function for
> explicitly destroying objects. But why is there is this lack of symmetry
in the
> language?  On the one hand, you have a slick ``new''-expression to create
> objects, but the complementary deletion operation is totally obscured.
Does
> this mean that explicit freeing of objects via an instance of
> Unchecked_Deallocation is discouraged (due to the potential creation of
> dangling references)? Is it the reponsibility of the language
implementation to
> automagically detect when an object is no longer reachable and do the
> appropriate deallocation, even if garbage is not collected?
> 

In Ada, an object of an access type is defined (by the language) as being
deallocated, in effect, when that type goes out of scope. However, since
the object cannot possibly be dereferenced (used) when its type has gone
out of scope, an Ada compiler need, in practice, do nothing to deallocate
the object: it can just leave the memory used up by the allocation
permanently allocated (until the program terminates).

The Ada compilers that I have used are old and arcane ones (for four-bit
target machines, believe it or not). I gather from recent net conversations
that most Ada compilers these days do not do any automatic memory
reclamation ('garbage collection'), because it is not generally required.
Well, I would agree wholeheartedly that in embedded applications, random
garbage collection would be just a tad impractical; of course, in these
applications, access types (I don't mean 'access all' types) tend not to be
used anyway.

However, I would assert that an Ada compiler which targets a desktop
computer should provide full reclamation, no matter how much extra memory
or time it costs. It seems just too impractical to me that it should do
otherwise.

I would welcome comments on this.

Nick.

Re: newbie Q: storage management

[Robert Dewar]

Nick says

<<However, I would assert that an Ada compiler which targets a desktop
computer should provide full reclamation, no matter how much extra memory
or time it costs. It seems just too impractical to me that it should do
otherwise.>>

Impractical for whom? A lot of people programming in C, C++, Pascal, etc
seem to manage fine without automatic garbage collection. yes of course
I agree that GC would be desirable, but the fact of the matter is that

(a) we certainly have not run into any customers who have even noted GC
as a major requirement, let alone something they would be willing to fund.

(b) we do not see that the major work in providing GC would begin to pay for
itself if we did it on a speculative basis.

Just because you want something does not mean that it is impractical for
someone else not to provide it at no cost :-)