Thank you for the writeup!
A few questions on the basic design decisions being made here:
- Am I correct in understanding that your object system “bakes in” class-based inheritance for method dispatch (a la Smalltalk or objvlisp)?
- What search mechanism (when handling choicepoints/backtracking) are you using (perhaps related to this discussion)?
- How do transactions handle failure (if that is possible)? Is there “read-your-writes”? I think it would be nice to spell out the design decisions as they pertain to transactionality.
What does this mean operationally? Does it mean that:
- Sending to a non-existent object will crash
- Sending to a non-existent object will return a sentinel value (“no answer”)
- Some third thing
I also wanted to share a bit of my own work in case any of the ideas within are interesting for your experimentation. I’ve been working on a “minimal object kernel” which aims to capture the minimal structure necessary for transactional object interactions and proper information boundaries. My system does not yet feature any Prolog-style declarativity, variables, backtracking, etc., but the basic system structure should be compatible with adding those (which I plan to investigate in the near future). Writeup of my current design:
paper.pdf (370.9 KB)