These are true, but not the underlying problem. The biggest underlying reason is the multiple constraints on memory management;
a) since the data is typed rather than the pointers, every chunk of memory has to be self identifying, not just for the garbage collector, but also so (plus a b) can do the right thing. b) since garbage collection can occur, the compiler is strongly constrained about when and where it creates and destroys pointers to data that might be garbage collected. c) the layout of the stack is strongly constrained, for the garbage collector, the exception handling system, and also the return values system; any function can return zero or more values, and may not return at all. d) all array references have be bounds checked. All structure references have to be type checked. Another major pain (from the viewpoint of a compiler) is that any function can be redefined at any time, and can have it's fundamental contract changed. A lot of things might need attention at runtime, depending on what assumptions the compiler built into the code it produced. With clever design, and a few extra declarations, this kind of thing need not be horrendously expensive, but it all adds up. _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
