Richard,

[It's easier to read emails with quotes if a blank line is placed between quotes and replies.]

> Can you give an example of how a wrapper provides semantics?  Do
> you mean that these enforce semantics and that all access must go
> through these "firewall" classes?

Yes.  For example, the wrapper for Array must provide the usual Array semantics, but perhaps not all of the Object and ProtoObject semantics.

> Are your users getting pre-compiled components or are they compiling in
> their own trusted environment?

The latter.  The fragments will be stored as Smalltalk source on the server.  Each fragment will itself therefore be "open source", and editable by the user of the fragment.

> I like the idea of compiler support, but it does seem that it would be 
> easier to
> declare references to non-core objects in the environment as properties
> that must be set when the component is instantiated.  This is the 
> approach
> I am taking in our project (http://www.simula.no:8888/QuA).

Since writing my OP, I have found out about Class.environment, and agree that this would be a simpler way of dealing with global variables.

> > (2b) Compiler flags as a compilation error any message-send whose =
> > selector does not appear in a compiler-supplied Set.

> ...to avoid a runtime error when the wrapper class does not understand?

I don't think runtime errors can be avoided completely this way, without a great deal of additional type checking.  Rather, this is to avoid sending messages like #become: or #nextObject:, which are rather dangerous!

> > (2c) Where necessary, compiler compiles "constants" (numbers, blocks, =
> > {}s, thisContext, etc) as instances of suitable wrapper classes 
> > instead =
> > of the usual Kernel classes.

> What is special about these in relation to code safety issues?

Same as above: since these classes inherit from Object, the whole Object interface is available to their users.  This might be avoidable, however, by careful restrictions in (2b).

Cheers, Paul