On Mon, Jul 11, 2011 at 10:57 PM, John Zabroski <johnzabro...@gmail.com>wrote:
> > > On Mon, Jul 11, 2011 at 4:43 PM, karl ramberg <karlramb...@gmail.com>wrote: > >> >> >> On Mon, Jul 11, 2011 at 10:23 PM, John Zabroski >> <johnzabro...@gmail.com>wrote: >> >>> Much interesting >>> >> Thanks Karl > >>> On Mon, Jun 13, 2011 at 11:17 AM, Alan Kay <alan.n...@yahoo.com> wrote: >>> >>>> It would be great if everyone on this list would think deeply about how >>>> to have an "eternal" system, and only be amplified by it. >>>> >>>> For example, take a look at Alex Warth's "Worlds" work (and paper) and >>>> see how that might be used to deal with larger problems of consistency and >>>> version control in a live system. >>>> >>>> I also believe that we should advance things so that there are no hidden >>>> dependencies, and that dependencies are nailed semantically. >>>> >>> >>> Alan/Alex, >>> >>> Worlds does not address how to debug a live system other than random >>> state-space exploration. >>> >>> Have you made progress I am not aware of? >>> >>> As I've said before, computer scientists must be much better at studying >>> living systems if they want to build systems that can function at scales >>> that exceed the capacity for humans to configure it. How exactly does >>> "Worlds" truly deal with larger problems of consistency and version >>> control? The same question applies to David Reed's TeaTime, which is really >>> just Worlds with an illusion of infinite memory. I, too, could edit a >>> PhotoShop image forever and scroll through the history of every edit I ever >>> made using the History view, but I would need a lot of memory to do it. In >>> practice, PhotoShop requires the user to do things like compacting layers >>> and other memory organization techniques. >>> >>> To really make something like TeaTime or Worlds useful, you need bounds >>> on how the history relation of a program affects the input/output relation. >>> Even with bounds, you can still have "glitches" like the Brock/Ackerman >>> Anomaly. But the nice thing about bounds is there is a lot of mathematical >>> ways you can describe bounds, such as linear temporal logic or linear types >>> or just any linearity guarantee period. >>> >>> That said, it is okay to have hidden dependencies, as long as somebody is >>> allowed to check those dependencies at any point in time they please. A bad >>> hidden dependency would be something like a NAT firewall causing a protocol >>> to stop working. But an even more pernicious hidden dependency is in all >>> software: BUGS! >>> >>> Dealing with bugs has led Carl Hewitt to propose we should just live with >>> them, and reason about live systems using inconsistency tolerant logic. He >>> prefers his own logic, DirectLogic. >>> >>> Cheers, >>> Z-Bo >>> >>> _______________________________________________ >>> fonc mailing list >>> fonc@vpri.org >>> http://vpri.org/mailman/listinfo/fonc >>> >>> I wonder how these worlds would merge split streams of worlds. Or will >> worlds only allow branching without combining. >> Could I pull in another world and start combining them ? >> Or should they behave as website history, where I use the backbutton to >> trace may steps? >> >> Karl >> >> > > There is a formalism for thinking about what you are describing, called > Oracles [1]. (It is used to define "Fudgets" or Functional Gadgets.) > Oracles basically have a decision function that "knows" which outcome ( > "World" ) is going to materialize (create a side effect). I am > oversimplifying, but I think this is what you are asking about. Instead of > combining Worlds, you combine outcomes. After all, a World says nothing > about how it "flows back" to reality to create, say, a coin flip. > > Cheers, > Z-Bo > > [1] http://lambda-the-ultimate.org/node/1665 > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
