Why are the 'context' and 'object' functions in Rebol different, but essentially the same?

Question

On the one hand we have:

>> source object
object: make function! [[
    "Defines a unique object."
    blk [block!] "Object words and values."
][
    make object! append blk none
]]

For context we see:

>> source context
context: make function! [[
    "Defines a unique object."
    blk [block!] "Object words and values."
][
    make object! blk
]]

So, for object the object is constructed from a block to which none has been appended. This doesn't change the length, or, to my knowledge, add anything. With context, on the other hand, the object is constructed with the passed-in block, as is.

Why the difference and why, for example, couldn't context just be an alias for object.

Answer 1

Backwards compatibility. We had a context function already in Rebol that worked a particular way (not initializing variables), but we needed a function that initialized variables to none, as a convenience function when creating objects as data structures rather than as code containers.

It made sense to call it object since that is the type name, and since "context" is actually kind of a bad name for objects in a language with context-sensitive semantics (for a more appropriate meaning of the word "context"). It really leads to some confusing conversations. Since R3 has modules now, most of the previous uses of the context function are covered better by modules. Keeping context at all is mostly for backwards compatibility.

The current object function is pretty much a placeholder for a better type construction wrapper that we haven't thought up yet. We need something like it, but there may be subtle changes in its behavior needed that we'll discover with more use. For one thing, the fact that it modifies its spec block makes it not very safe for recursion or concurrency. It will likely end up as a native if that improves it, or maybe as a construct option if that turns out to be a better approach.

One thing that did turn out to be a win is the practice of using the type name without the exclamation point as the name of a type construction function. We changed map to be that as well, and we may end up adding similar constructors for other types, though most that need them have them already.