The difference between objects and functions in my model here is that objects have a history and functions do not. Modeling a pure function as an object which has a history doesn’t really make sense. However, the frontend syntax you describe here is totally compatible with a fundamental model which does make a distinction between objects and functions – it is still the case that you can send a message to a function (and get back the result of computing the function), functions just do not have an identity or a history (whereas objects do).
OK, noted.
I’m not familiar with what you’re referencing here (“proto object”, “identity API”), do you have a link?
In general, I’m trying to construct something similar to process isolation, such that multiple users can use the VM, create their own objects, etc. while still guaranteeing that objects will behave as expected. More specifically, this ownership restriction provides for hierarchical transactional objects, where the objects created by an object can always be “folded into” it (or modeled as within it), since they cannot be called from elsewhere. It is probably possible to relax the restriction somewhat while preserving that, e.g. allow children to call parents, but this introduces some complexities in modeling (would the child-parent call be part of the history, or not? if the former, where is it in history, since the triggering call has not been responded to yet? if the latter, what exactly is this? etc.).
However, it would be easy to drop this restriction and leave the rest of the construction the same, we’d just lose these guarantees. I suppose that this ownership check could even be implemented in the object code (program), and perhaps that would be preferable to putting it in the base model.
I suppose that it could be (some sort of handler when you call an object). This instruction is intended to revert any state changes (“as if the transaction never happened”), so we’d need to think about how that works with catch/handle semantics, but I can imagine a basic first pass (it is as if the call in question never happened, and you have to handle the error) would be reasonable enough, and possible to build on top of.