Re: Java vs Ada 95

Re: Java vs Ada 95

[Marin David Condic, 407.796.8997, M/S 731-93]

Larry Kilgallen <kilgallen@EISNER.DECUS.ORG> 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
===============================================================================

Re: Java vs Ada 95

[Larry Kilgallen]

In article <96102116593631@psavax.pwfl.com>, "Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM> writes:

>     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?)

Well the issue of _knowing_ whether the compiler supports GC has been
raised, and there are probably two forms for that:

     - ability for a program to specify that gc is expected

     - ability for a running program to determine whether gc is present

Larry Kilgallen