On Thu, Jan 17, 2013 at 2:36 PM, alex <alex_at_lurk.org> wrote:
> > except insofar as the history is explicitly recorded in
> > the environment
>
> That's a big "except insofar" though.
Indeed. It's also the essential nature of state. We can't observe the past,
only the present. Programmable state comes from maintaining a record of
observations, such that the record is available in the present.
Restarting a system does have (cognitive) semantic impact
by not running for a while.
Yes. It can be useful to model this disruption. There are also cases where
we'll want to model stateful systems as having inertia or friction, forces
that continue to apply even when we're not observing or explicitly
manipulating it. To accommodate disruption, it's best if the computation of
passive behavior is trivial (no expensive accumulators).
>
> Also, you can't really reason about a program's behaviour if someone
> can come along and change it while you're trying to reason about it.
>
We can design live programming systems that accommodate CSCW and security
properties, where mutually distrustful developers update different parts of
the system. If someone edits the same code you're about to edit, that's a
bit more difficult to handle, though a language that provides nice
composition properties (e.g. commutativity, associativity, idempotence,
stability, resource control) can help address the issue.
Live code is the ultimate in mutable local state, isn't it? :)
>
The two conditions are orthogonal, unless you assume that every program has
ambient authority to edit its own source code. (Self-modifying code has
plenty of its own issues.)
You can contain purity inside monads, but
> introducing liveness makes it all impure again, doesn't it?
It depends on whether the live edit can be observed or influenced by the
edited program. :)
Changes to a program are part of it, and absolutely nothing
is certain or immutable,
The concept of "immutable" can be understood in a very practical sense: "I
am unable to observe changes to the object". In a multi-stage live
programming environment, we can treat the stages below our code as static
and immutable, while the stages above are dynamic, alive. This works
because the lifespan of the stage exceeds the lifespan of anything built
upon it.
I've found multi-stage live programming to be an elegant way to
simultaneously support both safe static reasoning and live, dynamic
systems.
except the fact that everything halts eventually.
>
Why so sure?
Regards,
Dave
Received on Fri Jan 18 2013 - 01:43:12 GMT