This anecdote will demonstrate the problem, which Ralf actually brought up a few days ago. I balked at first, but now I totally see the point. I was trying to convert Language Wars v2.1 alpha into a game that had WAV files. The first thing I did was to make the torpedo firing play a WAV file I have, using Jacques Deschenes sfx2.e file. Guess what? There were compile-time conflicts due to conflicting global types and constants. So I started to hack the various includes. Three changes later, I got a run-time error, which I was unable to diagnose because I'm not registered. I'm sure I probably could have made this work, but I just gave up. Ralf's suggestion was to change the scope rule to allow routines in deep includes inaccessible. This would solve my problem, but create others. I think I have included graphics.e file. I know it includes machine.e. So, in my main file, I call machine.e files without directly including it. I am exploiting the scope rules. If this new scope rules is implemented, all such programs would no longer work. It seems to me that the first priority should be portability. Currently, the scope rules do not allow portability. This is bad. But, what would be the new scope rules? Are we ready to make hundreds of programs un-runnable without hacking it? In deeply nested and complex includes, this could cause inefficient code. On the other hand, this could certainly lead to more discipline. Perhaps this should be dynamicly turned on and off. Any thoughts, Robert (or anyone else?) Alan - Visit the jfw ml web page: http://yoyo.cc.monash.edu.au/~nallan/jfw
