Conference turris::languages

    This isn't really an answer, because I don't personally have a test
    application. (I can think of one though... DECmcc meets all your
    requirements!) But I wanted to reply to say what a good idea this
    project is. To me memory allocation (etc) is "the next frontier" for
    CASE. I reckon that something like 25% of the total effort in a large
    system software project goes into dealing with memory allocation, or
    more accurately memory DEallocation. Tracking down memory leaks is
    incredibly time-consuming, but that's only the tip of the iceberg. Much
    more significant is all the thought that has to go in at the design
    stage to avoid memory leaks, which would be completely unnecessary with
    garbage collection. Although it's 20 years since I used a langauge that
    had it (POP-2... how many people remember that one?) I can still
    remember how incredibly liberating it is.  There are all sorts of
    things that are very natural to do, that you don't because of the
    memory allocation implications. Having functions return results as
    structures is one example.
    
    I was wondering, in a philosophical moment recently, what would be an
    acceptable price to pay for garbage collection?  My figure is 30%, in
    terms of execution time, space, etc. After all, we are easily paying a
    lot more than that for using high-level langauges, but nobody in their
    right mind would write in assembler without some very good reason.
    Similarly, general-purpose hardware-hiding GUI systems such as Motif
    and Windows are vast CPU hogs, but that doesn't stop their popularity,
    because there are so many applications that just wouldn't get written
    otherwise.
    
    Surely though there are language implications? For garbage collection
    to work you need very strong typing. Things like undifferentiated
    unions and variable-size (C-style) arrays are out! Casting becomes an
    even more dubious practice, and the language would need to provide
    mechanisms for the (fairly rare) cases where it is really necessary.
    
    In summary, the sooner the better...
    
    	John

    I've heard of POP-2, do I win a prize?   (I've never
    programmed in it, however).
    
>I reckon that something like 25% of the total effort in a large
>system software project goes into dealing with memory allocation, or
>more accurately memory DEallocation. 
    
    I don't believe this is true.  There are numerous products
    around which have clearly put zero effort into dealing with
    memory deallocation -- this, alas, appears to be the norm.
    
 > Similarly, general-purpose hardware-hiding GUI systems such as Motif
 > and Windows are vast CPU hogs, but that doesn't stop their popularity,
    
    I saw Motif running on a Sandpiper this morning -- it really
    is pretty decent.   How long do you think it'll be before they manage
    to slow it down to normal again?
    
    (Sigh, when I were a lad if we had a whole APR it were luxury,
     tell that to the youth of today, etc etc.)
    
                                                             

I'm sorry I don't have test applications, but would like to share some Smalltalk
experiments regarding GC. Smalltalk of course has it and it's great.
The time spent is estimated to less than 10%.
Also, new features include monitoring of the GC strategy (periodic with user-define
period, when-needed, 
etc...) and having GC as a true object (one in its class)
in order to be able to specialize strategy.
This can be useful for tuning critical applications.

Moreover, good monitoring and observability of GC allows to optimize only where
is needed, though may be more expensive on some tests, trading predicatability 
versus performance.

Last but not least, GC strategy is closely related to persistence schemes,
and it could be a nice trick to accomodate both.

You don't need "strong typing" to have decent GC.  Look at LISP and APL.

	:Karl, the weird languages guy.

    I tried looking at APL, but it made my eyes go funny. As for LISP, it
    has the strongest typing you can imagine: there is only one type.
    (Actually that isn't quite true, because atoms have multiple types).
    
    In general, you don't need any compile-time typing if everything
    carries type information at runtime (which is the case for APL,
    and to the extent that there are types, for Lisp). Also for Pop-2.
    (Ever come across that?)
    
    Languages like C++ are already a compromise in the direction of
    efficiency, in that they try to do type checking a compile time rather
    than runtime. I guess moving all type checking to runtime removes
    further constraints from the programmer, at a further cost in cycles to
    execute. Of course, this is the delight of using "untyped" languages;
    you can produce things much more quickly, if you don't mind the extra
    execution time. (I still remember how easy it was to "knock things up"
    in Pop-2).
    
    	John
    

>          <<< Note 342.5 by TAEC::HARPER "John Harper, DTN 828 5351" >>>
>     
>     In general, you don't need any compile-time typing if everything
>     carries type information at runtime (which is the case for APL,
>     and to the extent that there are types, for Lisp). Also for Pop-2.

That really depends on whether you have any preference between getting
your errors at compile-time and getting them at run-time.  For software
being delivered to customers, compile-time is often preferable.

    The important thing is that the programmer should not normally deal
    with pointers and addresses and such.  If the language lets the
    programmer think about data and objects and functions instead of
    addresses, then the language implementor can make the compiler and RTL
    keep track of what memory is used and free.  As soon as the programmer
    can ask for the address of something, there's no easy guarantee that
    memory won't be lost.

    What I'm trying to say is that one is taking the hard road if one takes
    a language like C or BLISS and hopes to patch on a memory-manager to
    fix these problems.  The language must make it easy for the programmer
    to get the job done without needing to work at the address level in
    order for the compiler to successfully hide that level and provide
    automatic storage allocation and reclamation.

    I mentioned APL and LISP as well-known examples of this, but I agree
    they are by no means the only possible solutions.

    	:Karl.

    re .-1:
    
    Of course what you say is true: as soon as the programmer can ask for
    the address opf something (and do anything with it) you can't guarantee
    that GC can work. (Actually in itself this doesn't permit memory loss;
    it just allows the programmer to trip overhis/her shoelaces when GC
    deletes things he/she had remembered the address of).
    
    C++, used properly, works with references rather than addresses. You
    don't ask for the address of something but rather a reference to it. As
    long as you don't violate the language's type safety by using explicit
    casts and one or two other things, GC can be made to work. But it would
    need a few minor tweaks to be able to do all the things you might
    reasonably want to be able to do and still be GC-ok. (For example,
    there are cases where you need to cast to a more refined type, but I
    don't believe you can ever need to do this in a way that couldn't be
    checked to be OK at run-time, unless you are a real hacker).
    
    As for whether dynamically typed languages like LISP and Pop-2 are
    better than compile-time checked languages like C++ and Ada, I guess
    that's a religious question and therefore best avoided.
    
    	John
    

    re .-1
    
	> unless you are a real hacker.
    
    I'm usually an integer hacker, but I can be coerced.

    undeclared identifier: integer
    unexpected token: hacker
    
    Maybe you meant an int hacker?
    
    	John
    

    
    Both C and C++ sometimes lie about return values.
    
    For example, suppose I write a function to return a pointer to a char:
    
      char * myfun(void)
    
    and I execute it:
    
      > myfun(void)
        
     % core
    
    Here, the function didn't return a char *, but a core dump. This is
    merely an example: it is also easy have a memory access violation
    returned.
    
    This is clearly a deficiency in the language.
    
    (only kidding ;-)