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: bobduff@world.std.com (Robert A Duff) Subject: Re: newbie Q: storage management Date: 1997/05/09 Message-ID: #1/1 X-Deja-AN: 240422413 References: <5k5hif$7r5@bcrkh13.bnr.ca> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-05-09T00:00:00+00:00 List-Id: 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". >... 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