"System Object" vs. "Sys Context"

Let's say I asked you to explain the difference between the system context (sys) and the system object (system)--and why they are two different things.

I'm betting you'd probably not be able to explain it. Because I get them mixed up all the time. :yawning_face:

TL; DR: - Having something called SYSTEM that is distinct from SYS isn't doing anyone any cognitive favors, and it should be changed. I propose SYS and SYSTEM be synonyms for the system context, and what is currently known as SYS become SYS.UTIL.

sys System Context: Usermode Helpers for the Core

There's a lot of support code behind things like booting, or LOAD or DO, or registration of codecs or whatever... that the average user is probably not going to want to call on a day-to-day basis. An example is make-scheme.

These routines don't necessarily compete for names with things in LIB. But putting them in SYS helps to call out that most users probably don't need to be concerned with them.

  • Pretty much every function in LIB routines is supposed to be something you could imagine a user being interested in calling in their scripts.

  • SYS functions are things that would generally only be called from extensions, or internally as a support function for natives or LIB functions.

system System Object: Global Variables and Template Objects

The system object is specified by a file called %sysobj.r.

As most people know, this is where you go to look for global state like the arguments that were passed to the interpreter when it ran...or the list of modules that have been loaded. But it also contains a large number of empty objects.

The make prep process creates a header file of constants of the integer indices of the fields in these objects. That makes it fast and easy for the core C code to directly address those fields, instead of having to linear search for them by key name.

Using these template objects has the effect that no matter how you create a derived object, it will get the fields named in them in that particular order. So the precalculated indexes will always be able to find the fields where they are looking... as long as that object was used as the base object.

But these template objects aren't just about interfacing quickly between C and the structures. Using common objects as keys helps save on allocations of lists of the keys...as the objects will share that list (as long as the object isn't expanded or created with more keys than specified in the base.

(I actually think it is a mistake to be doing objects this way, and that we should adopt JavaScript's model of "hidden classes" to get a more systemic optimization.)

Proposal: SYS => SYS.UTIL, SYSTEM <=> SYS

Having to type sys.util when you want something like sys.util.make-scheme isn't that oppressive.

UTIL is abbreviated, but so is SYS. We could make UTIL just an alias for UTILITIES, so the verbose-minded could write system.utilities.make-scheme if it pleased them.