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,a77baf86c187076a X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Garbage collection (was a spinoff of a spinoff of a GA Date: 1996/10/21 Message-ID: #1/1 X-Deja-AN: 191012866 references: <9610171549.AA07433@most> <54gb7a$nbh@linus.mitre.org> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-10-21T00:00:00+00:00 List-Id: In article <54gb7a$nbh@linus.mitre.org>, Michael F Brenner wrote: >This argument that something is an implementation detail is used (often >by other people whose initials also happen to be RD). Why should that >invalidate the Requirement we have for those implementation details? I (I think I'm the RD you're replying to) never meant to say that such details are unimportant. I meant to say that it goes without saying -- any program that leaks memory, or dereferences dangling pointers, has a bug. (Well, in some special circumstances, it's OK to leak memory.) There's no need for the requirements document to say so, and, indeed, most don't. Similarly, no requirements document says "this program shall not index arrays out of bounds." It goes without saying -- that's just a bug. The arrays in a program are implementation details. For the record: I agree that there are situations that are clearly bugs in a given Ada compiler, but the Ada compiler obeys the Ada standard. If an Ada compiler takes an hour to compile a 5-line package, that's a bug, despite the fact that the RM doesn't say so. >....When we revise the Ada Language Reference Manual next, it >should be fixed precisely in those places where more efficiency can >be put in without disturbing the reliability. Don't hold your breath. Do you know of *any* language standard that addresses efficiency in any way? I'm not trying to say efficiency if unimportant -- of course it is -- but I don't know of any feasible way to address it in a language standard. - Bob