libraries and environments

[Jonathan S. Shapiro]

I find myself writing a depressing number of library routines that
take the same three or four capability registers as arguments.  In
most cases, these registers hold things like the active domain key, a
schedule key, or a space bank key.

The register positions of these keys seem in practice fixed by
convention -- the constructor/factory sets things up a certain way,
and the process tends to leave them alone because it needs them
frequently.

The dependency on these keys is so pervasive, and the practice of
passing them explicitly is so distracting, that I am considering
introducing the notion of a "library environment" -- a library can
document the set of capabilities that it expects will be sitting in
key registers and where those capabilities live, and is entitled to
assume that the caller will arrange this before invoking the library
routine.

For the moment, the capabilities I have in mind to include in the
"library environment" are as follows:

	Register	Capability
	0		zero number key (hardwired)
	1		constituents node key
	2		domain key to self
	3		schedule key
	4		space bank key

	31		resume key to domain caller

Most libraries will not require the last one, since in most cases they 
do not return directly to the caller.

Applications that do not use such libraries need not maintain these
register conventions.

In cases where non-conventional choices of these values might be
desirable, the library interface can define an "extended" version of
the library routine, or the user can cook the environment
appropriately before performing the call to the library.

Does this seem unwise?

Would it be better to place the schedule key in a well-defined
constituent slot, on the theory that it is mostly used during startup
and initialization?

I am tempted NOT to include the space bank key, as the source of space 
is something one might want to control carefully.


shap