4 ms·

Have a look at the Edelweiss paper I linked. Stable ids are needed for that model. We would probably be fine with eg random uuids if we stuck with Bloom. EDIT:

by jamii 12y ago

Have a look at the Edelweiss paper I linked. Stable ids are needed for that model. We would probably be fine with eg random uuids if we stuck with Bloom. EDIT: Thinking about it, the issue is definitely not that it is immutable but that it is declarative. In the absence of control flow, `new` is not sufficient to provide unique identity because the rule in question may be run zero or more times.

seanmcdirmid 12y ago
Alot of work in glitch goes into solving this problem. In the new case, we are able to form stable (reproducible) IDs through a memoized lexical stream (re-lex will produce the same tokens if possible) and by using the call stack (so the id is a path with special ids for loop indices). For a declarative (rule based?) language, perhaps rule firing context could be used for a similar purpose; I'll try to look at that paper and see if something clicks. I guess it depends on what makes a unique object. Though if you are completely declarative, why would object identities be necessary?
- 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

Alot of work in glitch goes into solving this problem. In the new case, we are able to form stable (reproducible) IDs through a memoized lexical stream (re-lex will produce the same tokens if possible) and by using the call stack (so the id is a path with special ids for loop indices). For a declarative (rule based?) language, perhaps rule firing context could be used for a similar purpose; I'll try to look at that paper and see if something clicks. I guess it depends on what makes a unique object. Though if you are completely declarative, why would object identities be necessary?

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 :)