* newbie Q: storage management @ 1997-04-29 0:00 Kaz Kylheku 1997-04-30 0:00 ` Samuel A. Mize ` (4 more replies) 0 siblings, 5 replies; 58+ messages in thread From: Kaz Kylheku @ 1997-04-29 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-04-29 0:00 newbie Q: storage management Kaz Kylheku @ 1997-04-30 0:00 ` Samuel A. Mize 1997-04-30 0:00 ` kaz ` (2 more replies) 1997-04-30 0:00 ` Robert I. Eachus ` (3 subsequent siblings) 4 siblings, 3 replies; 58+ messages in thread From: Samuel A. Mize @ 1997-04-30 0:00 UTC (permalink / raw) To: Kaz Kylheku 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-04-30 0:00 ` Samuel A. Mize @ 1997-04-30 0:00 ` kaz 1997-04-30 0:00 ` Jon S Anthony 1997-05-02 0:00 ` Samuel A. Mize 2 siblings, 0 replies; 58+ messages in thread From: kaz @ 1997-04-30 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-04-30 0:00 ` Samuel A. Mize 1997-04-30 0:00 ` kaz @ 1997-04-30 0:00 ` Jon S Anthony 1997-05-02 0:00 ` Samuel A. Mize 1997-05-02 0:00 ` Samuel A. Mize 2 siblings, 1 reply; 58+ messages in thread From: Jon S Anthony @ 1997-04-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-04-30 0:00 ` Jon S Anthony @ 1997-05-02 0:00 ` Samuel A. Mize 1997-05-02 0:00 ` Jon S Anthony ` (3 more replies) 0 siblings, 4 replies; 58+ messages in thread From: Samuel A. Mize @ 1997-05-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-02 0:00 ` Samuel A. Mize @ 1997-05-02 0:00 ` Jon S Anthony 1997-05-03 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 0 replies; 58+ messages in thread From: Jon S Anthony @ 1997-05-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-02 0:00 ` Samuel A. Mize 1997-05-02 0:00 ` Jon S Anthony @ 1997-05-03 0:00 ` Robert Dewar 1997-05-05 0:00 ` Samuel A. Mize 1997-05-03 0:00 ` Robert Dewar 1997-05-04 0:00 ` Kevin Cline 3 siblings, 1 reply; 58+ messages in thread From: Robert Dewar @ 1997-05-03 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-03 0:00 ` Robert Dewar @ 1997-05-05 0:00 ` Samuel A. Mize 1997-05-06 0:00 ` Robert Dewar 1997-05-06 0:00 ` Michael F Brenner 0 siblings, 2 replies; 58+ messages in thread From: Samuel A. Mize @ 1997-05-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-05 0:00 ` Samuel A. Mize @ 1997-05-06 0:00 ` Robert Dewar 1997-05-06 0:00 ` Robert A Duff 1997-05-06 0:00 ` Michael F Brenner 1 sibling, 1 reply; 58+ messages in thread From: Robert Dewar @ 1997-05-06 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-06 0:00 ` Robert Dewar @ 1997-05-06 0:00 ` Robert A Duff 1997-05-08 0:00 ` Jon S Anthony 0 siblings, 1 reply; 58+ messages in thread From: Robert A Duff @ 1997-05-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-06 0:00 ` Robert A Duff @ 1997-05-08 0:00 ` Jon S Anthony 1997-05-08 0:00 ` John G. Volan ` (2 more replies) 0 siblings, 3 replies; 58+ messages in thread From: Jon S Anthony @ 1997-05-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-08 0:00 ` Jon S Anthony @ 1997-05-08 0:00 ` John G. Volan 1997-05-09 0:00 ` Jon S Anthony 1997-05-09 0:00 ` Robert A Duff 1997-05-09 0:00 ` Robert Dewar 2 siblings, 1 reply; 58+ messages in thread From: John G. Volan @ 1997-05-08 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-08 0:00 ` John G. Volan @ 1997-05-09 0:00 ` Jon S Anthony 1997-05-09 0:00 ` John G. Volan 0 siblings, 1 reply; 58+ messages in thread From: Jon S Anthony @ 1997-05-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-09 0:00 ` Jon S Anthony @ 1997-05-09 0:00 ` John G. Volan 1997-05-13 0:00 ` Jon S Anthony 0 siblings, 1 reply; 58+ messages in thread From: John G. Volan @ 1997-05-09 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-09 0:00 ` John G. Volan @ 1997-05-13 0:00 ` Jon S Anthony 1997-05-13 0:00 ` Robert Dewar 0 siblings, 1 reply; 58+ messages in thread From: Jon S Anthony @ 1997-05-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-13 0:00 ` Jon S Anthony @ 1997-05-13 0:00 ` Robert Dewar 0 siblings, 0 replies; 58+ messages in thread From: Robert Dewar @ 1997-05-13 0:00 UTC (permalink / raw) <<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! ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-08 0:00 ` Jon S Anthony 1997-05-08 0:00 ` John G. Volan @ 1997-05-09 0:00 ` Robert A Duff 1997-05-09 0:00 ` Brian Rogoff ` (2 more replies) 1997-05-09 0:00 ` Robert Dewar 2 siblings, 3 replies; 58+ messages in thread From: Robert A Duff @ 1997-05-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-09 0:00 ` Robert A Duff @ 1997-05-09 0:00 ` Brian Rogoff 1997-05-10 0:00 ` Robert A Duff 1997-05-09 0:00 ` Jon S Anthony 1997-05-10 0:00 ` Robert Dewar 2 siblings, 1 reply; 58+ messages in thread From: Brian Rogoff @ 1997-05-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-09 0:00 ` Brian Rogoff @ 1997-05-10 0:00 ` Robert A Duff 0 siblings, 0 replies; 58+ messages in thread From: Robert A Duff @ 1997-05-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-09 0:00 ` Robert A Duff 1997-05-09 0:00 ` Brian Rogoff @ 1997-05-09 0:00 ` Jon S Anthony 1997-05-10 0:00 ` Robert A Duff 1997-05-10 0:00 ` Robert Dewar 2 siblings, 1 reply; 58+ messages in thread From: Jon S Anthony @ 1997-05-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-09 0:00 ` Jon S Anthony @ 1997-05-10 0:00 ` Robert A Duff 1997-05-12 0:00 ` Jon S Anthony 0 siblings, 1 reply; 58+ messages in thread From: Robert A Duff @ 1997-05-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-10 0:00 ` Robert A Duff @ 1997-05-12 0:00 ` Jon S Anthony 0 siblings, 0 replies; 58+ messages in thread From: Jon S Anthony @ 1997-05-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-09 0:00 ` Robert A Duff 1997-05-09 0:00 ` Brian Rogoff 1997-05-09 0:00 ` Jon S Anthony @ 1997-05-10 0:00 ` Robert Dewar 2 siblings, 0 replies; 58+ messages in thread From: Robert Dewar @ 1997-05-10 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-08 0:00 ` Jon S Anthony 1997-05-08 0:00 ` John G. Volan 1997-05-09 0:00 ` Robert A Duff @ 1997-05-09 0:00 ` Robert Dewar 1997-05-13 0:00 ` Jon S Anthony 2 siblings, 1 reply; 58+ messages in thread From: Robert Dewar @ 1997-05-09 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-09 0:00 ` Robert Dewar @ 1997-05-13 0:00 ` Jon S Anthony 0 siblings, 0 replies; 58+ messages in thread From: Jon S Anthony @ 1997-05-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-05 0:00 ` Samuel A. Mize 1997-05-06 0:00 ` Robert Dewar @ 1997-05-06 0:00 ` Michael F Brenner 1997-05-06 0:00 ` Assuaging sour grapes :-) [was: newbie Q: storage management] John G. Volan ` (2 more replies) 1 sibling, 3 replies; 58+ messages in thread From: Michael F Brenner @ 1997-05-06 0:00 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Assuaging sour grapes :-) [was: newbie Q: storage management] 1997-05-06 0:00 ` Michael F Brenner @ 1997-05-06 0:00 ` John G. Volan 1997-05-07 0:00 ` Kevin Cline ` (2 more replies) 1997-05-07 0:00 ` newbie Q: storage management Jeff Carter 1997-05-07 0:00 ` Robert Dewar 2 siblings, 3 replies; 58+ messages in thread From: John G. Volan @ 1997-05-06 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Assuaging sour grapes :-) [was: newbie Q: storage management] 1997-05-06 0:00 ` Assuaging sour grapes :-) [was: newbie Q: storage management] John G. Volan @ 1997-05-07 0:00 ` Kevin Cline 1997-05-07 0:00 ` John G. Volan 1997-05-08 0:00 ` Jon S Anthony 1997-05-07 0:00 ` Stephen Posey 1997-05-08 0:00 ` Dynamic binding of packages Nick Roberts 2 siblings, 2 replies; 58+ messages in thread From: Kevin Cline @ 1997-05-07 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Assuaging sour grapes :-) [was: newbie Q: storage management] 1997-05-07 0:00 ` Kevin Cline @ 1997-05-07 0:00 ` John G. Volan 1997-05-07 0:00 ` John G. Volan 1997-05-08 0:00 ` Jon S Anthony 1997-05-08 0:00 ` Jon S Anthony 1 sibling, 2 replies; 58+ messages in thread From: John G. Volan @ 1997-05-07 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Assuaging sour grapes :-) [was: newbie Q: storage management] 1997-05-07 0:00 ` John G. Volan @ 1997-05-07 0:00 ` John G. Volan 1997-05-07 0:00 ` Robert Dewar 1997-05-08 0:00 ` Jon S Anthony 1 sibling, 1 reply; 58+ messages in thread From: John G. Volan @ 1997-05-07 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Assuaging sour grapes :-) [was: newbie Q: storage management] 1997-05-07 0:00 ` John G. Volan @ 1997-05-07 0:00 ` Robert Dewar 0 siblings, 0 replies; 58+ messages in thread From: Robert Dewar @ 1997-05-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Assuaging sour grapes :-) [was: newbie Q: storage management] 1997-05-07 0:00 ` John G. Volan 1997-05-07 0:00 ` John G. Volan @ 1997-05-08 0:00 ` Jon S Anthony 1 sibling, 0 replies; 58+ messages in thread From: Jon S Anthony @ 1997-05-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Assuaging sour grapes :-) [was: newbie Q: storage management] 1997-05-07 0:00 ` Kevin Cline 1997-05-07 0:00 ` John G. Volan @ 1997-05-08 0:00 ` Jon S Anthony 1 sibling, 0 replies; 58+ messages in thread From: Jon S Anthony @ 1997-05-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Assuaging sour grapes :-) [was: newbie Q: storage management] 1997-05-06 0:00 ` Assuaging sour grapes :-) [was: newbie Q: storage management] John G. Volan 1997-05-07 0:00 ` Kevin Cline @ 1997-05-07 0:00 ` Stephen Posey 1997-05-08 0:00 ` Dynamic binding of packages Nick Roberts 2 siblings, 0 replies; 58+ messages in thread From: Stephen Posey @ 1997-05-07 0:00 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Dynamic binding of packages 1997-05-06 0:00 ` Assuaging sour grapes :-) [was: newbie Q: storage management] John G. Volan 1997-05-07 0:00 ` Kevin Cline 1997-05-07 0:00 ` Stephen Posey @ 1997-05-08 0:00 ` Nick Roberts 1997-05-08 0:00 ` John G. Volan 2 siblings, 1 reply; 58+ messages in thread From: Nick Roberts @ 1997-05-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Dynamic binding of packages 1997-05-08 0:00 ` Dynamic binding of packages Nick Roberts @ 1997-05-08 0:00 ` John G. Volan 0 siblings, 0 replies; 58+ messages in thread From: John G. Volan @ 1997-05-08 0:00 UTC (permalink / raw) 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? :-) "); ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-06 0:00 ` Michael F Brenner 1997-05-06 0:00 ` Assuaging sour grapes :-) [was: newbie Q: storage management] John G. Volan @ 1997-05-07 0:00 ` Jeff Carter 1997-05-07 0:00 ` Robert Dewar 2 siblings, 0 replies; 58+ messages in thread From: Jeff Carter @ 1997-05-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-06 0:00 ` Michael F Brenner 1997-05-06 0:00 ` Assuaging sour grapes :-) [was: newbie Q: storage management] John G. Volan 1997-05-07 0:00 ` newbie Q: storage management Jeff Carter @ 1997-05-07 0:00 ` Robert Dewar 1997-05-09 0:00 ` Robert I. Eachus 2 siblings, 1 reply; 58+ messages in thread From: Robert Dewar @ 1997-05-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-07 0:00 ` Robert Dewar @ 1997-05-09 0:00 ` Robert I. Eachus 1997-05-10 0:00 ` Robert Dewar 0 siblings, 1 reply; 58+ messages in thread From: Robert I. Eachus @ 1997-05-09 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-09 0:00 ` Robert I. Eachus @ 1997-05-10 0:00 ` Robert Dewar 0 siblings, 0 replies; 58+ messages in thread From: Robert Dewar @ 1997-05-10 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-02 0:00 ` Samuel A. Mize 1997-05-02 0:00 ` Jon S Anthony 1997-05-03 0:00 ` Robert Dewar @ 1997-05-03 0:00 ` Robert Dewar 1997-05-03 0:00 ` Jon S Anthony 1997-05-05 0:00 ` Samuel A. Mize 1997-05-04 0:00 ` Kevin Cline 3 siblings, 2 replies; 58+ messages in thread From: Robert Dewar @ 1997-05-03 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-03 0:00 ` Robert Dewar @ 1997-05-03 0:00 ` Jon S Anthony 1997-05-04 0:00 ` Robert Dewar 1997-05-05 0:00 ` Samuel A. Mize 1 sibling, 1 reply; 58+ messages in thread From: Jon S Anthony @ 1997-05-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-03 0:00 ` Jon S Anthony @ 1997-05-04 0:00 ` Robert Dewar 0 siblings, 0 replies; 58+ messages in thread From: Robert Dewar @ 1997-05-04 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-03 0:00 ` Robert Dewar 1997-05-03 0:00 ` Jon S Anthony @ 1997-05-05 0:00 ` Samuel A. Mize 1 sibling, 0 replies; 58+ messages in thread From: Samuel A. Mize @ 1997-05-05 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-02 0:00 ` Samuel A. Mize ` (2 preceding siblings ...) 1997-05-03 0:00 ` Robert Dewar @ 1997-05-04 0:00 ` Kevin Cline 1997-05-04 0:00 ` Robert Dewar 3 siblings, 1 reply; 58+ messages in thread From: Kevin Cline @ 1997-05-04 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-04 0:00 ` Kevin Cline @ 1997-05-04 0:00 ` Robert Dewar 0 siblings, 0 replies; 58+ messages in thread From: Robert Dewar @ 1997-05-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-04-30 0:00 ` Samuel A. Mize 1997-04-30 0:00 ` kaz 1997-04-30 0:00 ` Jon S Anthony @ 1997-05-02 0:00 ` Samuel A. Mize 1997-05-04 0:00 ` Robert Dewar 2 siblings, 1 reply; 58+ messages in thread From: Samuel A. Mize @ 1997-05-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-02 0:00 ` Samuel A. Mize @ 1997-05-04 0:00 ` Robert Dewar 0 siblings, 0 replies; 58+ messages in thread From: Robert Dewar @ 1997-05-04 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-04-29 0:00 newbie Q: storage management Kaz Kylheku 1997-04-30 0:00 ` Samuel A. Mize @ 1997-04-30 0:00 ` Robert I. Eachus 1997-04-30 0:00 ` Marinus van der Lugt ` (2 subsequent siblings) 4 siblings, 0 replies; 58+ messages in thread From: Robert I. Eachus @ 1997-04-30 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-04-29 0:00 newbie Q: storage management Kaz Kylheku 1997-04-30 0:00 ` Samuel A. Mize 1997-04-30 0:00 ` Robert I. Eachus @ 1997-04-30 0:00 ` Marinus van der Lugt 1997-04-30 0:00 ` Jon S Anthony 1997-04-30 0:00 ` Jon S Anthony 1997-05-02 0:00 ` Nick Roberts 4 siblings, 1 reply; 58+ messages in thread From: Marinus van der Lugt @ 1997-04-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-04-30 0:00 ` Marinus van der Lugt @ 1997-04-30 0:00 ` Jon S Anthony 1997-05-02 0:00 ` Robert Dewar 0 siblings, 1 reply; 58+ messages in thread From: Jon S Anthony @ 1997-04-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-04-30 0:00 ` Jon S Anthony @ 1997-05-02 0:00 ` Robert Dewar 0 siblings, 0 replies; 58+ messages in thread From: Robert Dewar @ 1997-05-02 0:00 UTC (permalink / raw) <<> 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. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-04-29 0:00 newbie Q: storage management Kaz Kylheku ` (2 preceding siblings ...) 1997-04-30 0:00 ` Marinus van der Lugt @ 1997-04-30 0:00 ` Jon S Anthony 1997-05-02 0:00 ` Robert Dewar 1997-05-02 0:00 ` Nick Roberts 4 siblings, 1 reply; 58+ messages in thread From: Jon S Anthony @ 1997-04-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-04-30 0:00 ` Jon S Anthony @ 1997-05-02 0:00 ` Robert Dewar 1997-05-04 0:00 ` Kaz Kylheku 0 siblings, 1 reply; 58+ messages in thread From: Robert Dewar @ 1997-05-02 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-02 0:00 ` Robert Dewar @ 1997-05-04 0:00 ` Kaz Kylheku 1997-05-04 0:00 ` Robert Dewar 0 siblings, 1 reply; 58+ messages in thread From: Kaz Kylheku @ 1997-05-04 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-04 0:00 ` Kaz Kylheku @ 1997-05-04 0:00 ` Robert Dewar 0 siblings, 0 replies; 58+ messages in thread From: Robert Dewar @ 1997-05-04 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-04-29 0:00 newbie Q: storage management Kaz Kylheku ` (3 preceding siblings ...) 1997-04-30 0:00 ` Jon S Anthony @ 1997-05-02 0:00 ` Nick Roberts 1997-05-03 0:00 ` Robert Dewar 4 siblings, 1 reply; 58+ messages in thread From: Nick Roberts @ 1997-05-02 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: newbie Q: storage management 1997-05-02 0:00 ` Nick Roberts @ 1997-05-03 0:00 ` Robert Dewar 0 siblings, 0 replies; 58+ messages in thread From: Robert Dewar @ 1997-05-03 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 58+ messages in thread
end of thread, other threads:[~1997-05-13 0:00 UTC | newest] Thread overview: 58+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-04-29 0:00 newbie Q: storage management Kaz Kylheku 1997-04-30 0:00 ` Samuel A. Mize 1997-04-30 0:00 ` kaz 1997-04-30 0:00 ` Jon S Anthony 1997-05-02 0:00 ` Samuel A. Mize 1997-05-02 0:00 ` Jon S Anthony 1997-05-03 0:00 ` Robert Dewar 1997-05-05 0:00 ` Samuel A. Mize 1997-05-06 0:00 ` Robert Dewar 1997-05-06 0:00 ` Robert A Duff 1997-05-08 0:00 ` Jon S Anthony 1997-05-08 0:00 ` John G. Volan 1997-05-09 0:00 ` Jon S Anthony 1997-05-09 0:00 ` John G. Volan 1997-05-13 0:00 ` Jon S Anthony 1997-05-13 0:00 ` Robert Dewar 1997-05-09 0:00 ` Robert A Duff 1997-05-09 0:00 ` Brian Rogoff 1997-05-10 0:00 ` Robert A Duff 1997-05-09 0:00 ` Jon S Anthony 1997-05-10 0:00 ` Robert A Duff 1997-05-12 0:00 ` Jon S Anthony 1997-05-10 0:00 ` Robert Dewar 1997-05-09 0:00 ` Robert Dewar 1997-05-13 0:00 ` Jon S Anthony 1997-05-06 0:00 ` Michael F Brenner 1997-05-06 0:00 ` Assuaging sour grapes :-) [was: newbie Q: storage management] John G. Volan 1997-05-07 0:00 ` Kevin Cline 1997-05-07 0:00 ` John G. Volan 1997-05-07 0:00 ` John G. Volan 1997-05-07 0:00 ` Robert Dewar 1997-05-08 0:00 ` Jon S Anthony 1997-05-08 0:00 ` Jon S Anthony 1997-05-07 0:00 ` Stephen Posey 1997-05-08 0:00 ` Dynamic binding of packages Nick Roberts 1997-05-08 0:00 ` John G. Volan 1997-05-07 0:00 ` newbie Q: storage management Jeff Carter 1997-05-07 0:00 ` Robert Dewar 1997-05-09 0:00 ` Robert I. Eachus 1997-05-10 0:00 ` Robert Dewar 1997-05-03 0:00 ` Robert Dewar 1997-05-03 0:00 ` Jon S Anthony 1997-05-04 0:00 ` Robert Dewar 1997-05-05 0:00 ` Samuel A. Mize 1997-05-04 0:00 ` Kevin Cline 1997-05-04 0:00 ` Robert Dewar 1997-05-02 0:00 ` Samuel A. Mize 1997-05-04 0:00 ` Robert Dewar 1997-04-30 0:00 ` Robert I. Eachus 1997-04-30 0:00 ` Marinus van der Lugt 1997-04-30 0:00 ` Jon S Anthony 1997-05-02 0:00 ` Robert Dewar 1997-04-30 0:00 ` Jon S Anthony 1997-05-02 0:00 ` Robert Dewar 1997-05-04 0:00 ` Kaz Kylheku 1997-05-04 0:00 ` Robert Dewar 1997-05-02 0:00 ` Nick Roberts 1997-05-03 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox