compile environment..

[David Bein <pyramid!bein@sri-unix>]

Scott:

  Two cheers for Accent -- they have clones and do it via copy-on-write
  One cheer for Unix -- they don't have copy-on-write..

  How about the following?

(1) compile-file :affect-environment <val> :use-environment <val>
		:load-result <val>

	:affect-environment specifies whether or not it is permissible
	to muck with current image in the process of effecting the
	compilation. default: nil -- do not mess with my space

	:use-environment specifies that the current environment is
	needed (or not) for the compilation. default: nil always
	be clean and use the "standard" environment.

	:load-result says what to do with the result and does not
	necessarily imply that the current environment will be
	messed with in any ways other than what are implied if
	you only load the result of compilation. default: nil

Letting the defaults for these be NIL and putting the handling
of them into the same gray-zone as some of the file ops implies
that they are standardized for those environments where they
make sense (and can be implemented) and simply ignored where
they can not be done or do not make sense.

(Look out for the black-zone)...

(2) compile :clone <val> :virgin <val> :in-current-env <explicit-progn-form>
		:in-other-environment <explicit-progn-form>

	:clone means explicitly do not mess with my process space
	to compile my function. The result of the compilation, i.e.
	the function object, magically finds it way into my space.

	default: nil -- do it in my space -- mess with it too.

	:virgin implies clone and do something akin to an exec
	with proper redirection such that the result of the
	compilation comes back as in :clone. Exactly what the
	"clean" environment must look like should be well
	specified as it is expected that this is the only
	part which could easily be standardized.

	default: nil -- do it in my space -- mess with it too.

	:in-current-environment means evaluate forms in the current
	environment and then :clone with the result being stuffed
	back into my current space. This is somewhat akin to
	eval-before-context-save or something like that.

	default: nil -- this means nothing special if there is not some
	kind of context saving mechanism going on other than yet another
	kind of top-level eval-when-who-knows kind of form.

	:in-other-environment means evaluate the forms after getting
	into the new environment. It applies to either :clone or
	:virgin. It is somewhat akin to eval-after-context-save
	or something like that. The effects of this should not
	be noticed in the post-compile environment.

	default: nil -- this means nothing if there is no way
	to get a new context or maybe it should be yet another
	pre-form which acts like eval-when- ...

Somewhere in here we find that it is useful to have a working
definition of what is a process (from a CL point of view) and
that many things we would like to be able to do are limited
by the fact that we don't have a good handle on things. I
could very easily graft pieces from Accent or Unix into
a working process definition, but that is beyond the question
at hand. I guess your reply to Moon et al is just the tip of
the iceberg.

Comments?

--David

p.s. What about errors in compilation if we do it in another
	process space?