3 ms·
Alan Kay: Worlds: Controlling the scope of side effects [pdf]
- pj 17y agoThis is a neat idea. I suppose it is like saving your game in a video game. When you get killed, just start over at your last save.
- mahmud 17y agoI have read the paper when it came on LtU a while ago, and the analogy doesn't do the research justice. You could always persist side-effects until later use. That's what closures allow you to do. However, what the paper introduces is a new kind of "versioned memory"; Think of it as copy-on-write for the process' RAM, where certain procedures can make all the global side-effects they desire and keeping the changes only visible to themselves. Not only that, but it keeps a journal of state-change, so you can track how a particular variable changed over time. At least that's my understanding of it.
- cma 17y agoSeems to share roots with some of the ideas developed in David Reed's thesis, Naming and Synchronizations in a Decentralized Computer System: http://www.lcs.mit.edu/publications/specpub.php?id=773 http://www.lcs.mit.edu/publications/specpub.php?id=773
- rntz 17y agoComing from Haskell, this seems a lot like taking the entire state of the world, sans I/O, and just bundling it into a monad (or MonadPlus, etc). Powerful, but a bit of a blunt instrument compared to using a finer-grained technique. The backtracking use-case given of trying two keys to open a safe, for example, is straightfoward to solve with the List monad. import OutsideWorld (keyA, keyB, unlocksSafe) unlockSafe = do key <- [keyA, keyB] if unlocksSafe key then return key else mzero Of course, in Haskell, this would be more idiomatically solved simply using filter; but it's a toy example after all.