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,f03afc58e3eb222,start X-Google-Attributes: gid103376,public From: "Marin David Condic, 407.796.8997, M/S 731-93" Subject: Re: Java vs Ada 95 Date: 1996/10/21 Message-ID: <96102116593631@psavax.pwfl.com>#1/1 X-Deja-AN: 191276948 sender: Ada programming language comments: Gated by NETNEWS@AUVM.AMERICAN.EDU x-vms-to: SMTP%"INFO-ADA@VM1.NODAK.EDU" newsgroups: comp.lang.ada x-vms-cc: CONDIC Date: 1996-10-21T00:00:00+00:00 List-Id: Larry Kilgallen writes: >> Therefore, although existing Ada users may be perfectly happy without >> GC, it might well be the case that non-Ada users would be attracted to >> Ada if it had GC. All is not lost -- it may well happen that Ada will >> have GC in a few years. (Several have pointed out that "having GC" is >> an implementation issue. Correct, but I think one can reasonably define >> "language X has GC" to mean "I am confident that all implementations of >> language X now and in the future will have GC". In that sense, Lisp has >> GC, but Ada does not (yet).) > >It seems to me, therefore, that "has GC" does not belong in the standard >or in an annex any more than "has an optimizing back end". Standards >must leave some areas for implementors to differentiate themselves, >or else one will be stuck like Unix or HTML with each implementor >striving to add their own source-incompatible "added-value" extensions >thereby undercutting the standard. GC, peephole optimizers, and the >like can all be left unstandardized without harm to source portability. > I'd have to agree with the notion of leaving it up to the implementation to decide - the language makes it easy to either do it or not do it as your market demands. (As opposed to some languages which basically demand garbage collection or leaving memory wasted until program termination) For embedded computers, it's not as big a concern as it might be for data processing systems or simulations or...(take your pick) Most "hard" realtime systems eschew dynamic allocation for predictability reasons and hence don't need garbage collection. If that's your market, you don't want the language standard demanding you throw things in your customer clearly doesn't want. The "soft" realtime systems may use this technology more frequently and for these apps, there may be some market in offering it as an option. For the folks building apps on a "traditional" platform (VAX/VMS, Sun/Unix, PC/Windows, etc...) there would probably be a big advantage in claiming your compiler has GC running all the time (With Unchecked-Deallocation functioning for those who like to "Roll Your Own" and accept the risk.) I'd prefer to see the vendor decide what they want to target for and let me pick the best approach for the apps I build. However, there *might* be some advantage in a language standard to saying something to the effect that: "If an implementation provides garbage collection, then the following constraints apply..." Then outline some minimal set of expected behavior as it may apply to program correctness, error detection, exceptional conditions or whatever else may be a concern for *language* behavior. (If the garbage collection is truly invisible, except for performance or space issues, then it doesn't need to be specified by the language standard, eh?) MDC Marin David Condic, Senior Computer Engineer ATT: 561.796.8997 M/S 731-96 Technet: 796.8997 Pratt & Whitney, GESP Fax: 561.796.4669 P.O. Box 109600 Internet: CONDICMA@PWFL.COM West Palm Beach, FL 33410-9600 Internet: CONDIC@FLINET.COM =============================================================================== "If you don't say anything, you won't be called on to repeat it." -- Calvin Coolidge ===============================================================================