[gclist] Collector in language definition.

[Charles Fiterman]

> Charles Fiterman wrote:
> > 
> > There is a very powerful reason for having
> > Garbage Collection implied by a language
> > definition. It is required for a type safe
> > language.
> [...]
> > Type safe languages can have functional and
> > class composition and all sorts of powerful
> > things that wouldn't go in unsafe languages.
> 
> What exactly are "functional and class composition", and why
> couldn't you put them in an unsafe language?

First functional composition. Let us suppose you want some functions
to have a property you call being-a-transaction. Such a function
will either succeed leaving side effects or fail with an exception
leaving no side effects. The hard way is to take a function and
modify it by hand so it has the property. This is difficult and
error prone, further if the modified function uses other functions
it can break down after the fact when those other functions are
modified by other programmers.

Now suppose you have a fully reflexive language. Write a function
that takes a function as an argument examines it as a directed
graph and returns a new function having the desired property. Once
this works you can turn out functions having the desired property
at will and at run time.

Now class composition. Let us suppose you want a class to have
a property called make-utility. A member of such a class will have
a timestamp which will be updatded when the member is changed, it
will have a dependency list and a rebuild method. In short you
will be able to ask if it is current and rebuild it if it isn't.
Just like having a make utility in your program.

Again there is the hard way which is error prone and the easy way.
Write a function which reads a class as a directed graph and returns
a new class with the desired property.

You are already firmilar with one form of class composition, inheritance.
But this is buried in the compiler. In C++ classes aren't objects, you
can't roll your own. You can't add new forms of class composition. I
have class X and want persistant-X, I have persistant-X I want
make-utility-persistant-X now give me trace-to-auditing-make-utility ... ...

Now suppose you are doing all this. It means you are building functions
and classes with very indirect tools. As hard as it was to track type
safety before now you need help. An uncollected language is out of
the question. You should have no idea of the storage dependencies of
some far out function in a class built via six kinds of class composition.

If you get the comp.objects FAQ you will read a long disertation on
why Object orientation without garbage collection is nonsense. But
basicly not having a garbage collector breaks encapsultion in very
deep ways. In order to use a class you need to know how it deals with
storage. While there is only one kind of class composition floating
around this is almost managable, people can still use C++. But allow
multiple flavors of class composition and the idea is mearly silly.