3 ms·

For largely the same reason that relational databases need identity. The classic example is the users table. Everything about the user, from their username to t

by jamii 12y ago

For largely the same reason that relational databases need identity. The classic example is the users table. Everything about the user, from their username to their email address, can be changed. So you need some way to stably reference that user. In the timeless Tarpit/Edelweiss world, the current state of the program is a pure function of its inputs. That means that the id has to be deterministically derived from the inputs. For now we synthesise ids out of contextual information eg "the user created at time T by event X". This works for now but it feels a little awkward. Once we have written more code in Eve we will have a better set of examples to guide thinking about a solution.

seanmcdirmid 12y ago
Isn't that effectively mutation then? You have an ID with information related to that ID that changes, or what we would call mutable fields in the object world. Anyways, this is why I don't play with declarative programming models anymore: I would wind up hacking in necessary things like identity and mutation in very weird ways. This is why I decided instead to try applying declarative time semantics to an imperative programming model. Your solution is quite similar to mine: all blocks that continue in after clauses underneath an event are indexed by the event instance (we memoize event instances so they have identifiers). One problem that we had to deal with is the discrete nature of an event handling context; it made sense to have an additional clause that continues after the event (to create an object like a new user) vs. code that executes discretely (like a physics step). The former gets indexed by the event instance, the latter is shared across all event instances (so you can't really create an object in anything other than a top-level block of event-after block).
- jamii 12y ago
  I'm not sure where you got the idea that we are proposing a language where nothing ever changes :p Both Bloom and Edelweiss are ideas about how to model time/change declaratively ie without having to specify control flow or incidental ordering. That doesn't seem to be too different to Glitch. Whether you think of imperative code pushing updates to data structures or declarative code pulling updates from stream is a matter of perspective. Either way, you still have to figure out how to order and combine those updates. Bloom takes the approach that each fact is true at an explicit point in time, so rather than mutating in place you simple define the state at time T+1 in terms of the state at time T. Both states are simultaneously accessible so you don't have to worry about what order the changes happen in. Edelweiss takes the approach discussed in Out Of The Tarpit where the true state is just the list of input events and everything else is an incrementally maintained view over these events. Edelweiss makes this practical by analysing datalog code to determine when an input event can no longer contribute to the state of the system. This is roughly analogous to GC, except that instead of relying on pointers to determine unreachability it uses static analysis. The appeal of this model is that you can always explain the state of system to the programmer by tracing backwards through the views.
  - seanmcdirmid 12y ago
    I don't think you are, and neither am I. What we both want is controlled change, we are just going about it from different directions. I'm still trying to get a handle on Bloom and this discussion is useful, thanks! Glitch is based on the same GC analogy but does a pure dynamic analysis: input events generally never wash out of the system since they are often clock ticks that step a physics simulation :)

by jamii 12y ago

seanmcdirmid 12y ago

Isn't that effectively mutation then? You have an ID with information related to that ID that changes, or what we would call mutable fields in the object world. Anyways, this is why I don't play with declarative programming models anymore: I would wind up hacking in necessary things like identity and mutation in very weird ways. This is why I decided instead to try applying declarative time semantics to an imperative programming model. Your solution is quite similar to mine: all blocks that continue in after clauses underneath an event are indexed by the event instance (we memoize event instances so they have identifiers). One problem that we had to deal with is the discrete nature of an event handling context; it made sense to have an additional clause that continues after the event (to create an object like a new user) vs. code that executes discretely (like a physics step). The former gets indexed by the event instance, the latter is shared across all event instances (so you can't really create an object in anything other than a top-level block of event-after block).

jamii 12y ago
I'm not sure where you got the idea that we are proposing a language where nothing ever changes :p Both Bloom and Edelweiss are ideas about how to model time/change declaratively ie without having to specify control flow or incidental ordering. That doesn't seem to be too different to Glitch. Whether you think of imperative code pushing updates to data structures or declarative code pulling updates from stream is a matter of perspective. Either way, you still have to figure out how to order and combine those updates. Bloom takes the approach that each fact is true at an explicit point in time, so rather than mutating in place you simple define the state at time T+1 in terms of the state at time T. Both states are simultaneously accessible so you don't have to worry about what order the changes happen in. Edelweiss takes the approach discussed in Out Of The Tarpit where the true state is just the list of input events and everything else is an incrementally maintained view over these events. Edelweiss makes this practical by analysing datalog code to determine when an input event can no longer contribute to the state of the system. This is roughly analogous to GC, except that instead of relying on pointers to determine unreachability it uses static analysis. The appeal of this model is that you can always explain the state of system to the programmer by tracing backwards through the views.
- seanmcdirmid 12y ago
  I don't think you are, and neither am I. What we both want is controlled change, we are just going about it from different directions. I'm still trying to get a handle on Bloom and this discussion is useful, thanks! Glitch is based on the same GC analogy but does a pure dynamic analysis: input events generally never wash out of the system since they are often clock ticks that step a physics simulation :)