From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b307bd75c8071241 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: newbie Q: storage management Date: 1997/05/09 Message-ID: #1/1 X-Deja-AN: 240656759 Distribution: world References: <5k5hif$7r5@bcrkh13.bnr.ca> Organization: PSI Public Usenet Link Newsgroups: comp.lang.ada Date: 1997-05-09T00:00:00+00:00 List-Id: In article bobduff@world.std.com (Robert A Duff) writes: > In article , Jon S Anthony 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