Hi All-- Just wanted to say that there is some cross-over here to electronic bus systems, and the related Producer-Consumer paradigm (PC). Some bus systems broadcast all messages to all connected nodes, ie they are unaddressed. In particular Bosch's CAN bus, used in cars, trucks, industry, and science, was designed this way. While each message (frame) has a header and body, and the header is used to select messages of interest, as originally designed the header did *not* contain a destination address, but rather a bit-pattern which each connected node can choose to accept. This is very flexible, and can be used in various ways.
The Producer-Consumer paradigm broadcasts Events from one or more Producers to zero or more Consumers. A Producer sends an Event on on state *change*. Rather than using a bit-encoded meaning, it uses an arbitrary number (set of bits) to represent that meaning. The meaning of the message is the sum total of the originating change and the resultant actions as a response to the Event. Neither the Producers nor Consumers are aware of each others activities. We are adapting both of the above for use in model railroading. An example of an Event might be "Evening is falling". The sending of such an event might be triggered by a button-press, a clock, or software (each an independent Producer). Similarly, the resultant actions might be: a change in the train schedule, house and lights coming on, changed traffic signal operation, dimming of the room lights, etc. Again, each of these are independent from each other. The similarities to "publish and subscribe" are striking, although there is no central control. Obviously braodacasting every message to every connected node is not scalable, so, we are also implementing an interest-based routing of messages onto only those bus-segments, which have nodes interested n a particular message, to reduce traffic. While the lower-level firmware and hardware are relatively fixed, the upper protocols and software start looking a lot like Fonc concepts. The upper layer protocols are quite independent, and they could easily be relabeled as domain-specific-languages. This just makes me think that this group is on the right track, and the software/hardware fraternities aren't that far apart. David OpenLCB.org On Mon, Mar 19, 2012 at 1:40 PM, Alan Kay <alan.n...@yahoo.com> wrote: > Hi Benoit > > This is basically what "publish and subscribe" schemes are all about. > Linda is a simple "coordination protocol" for organizing such loose > couplings. There are sketches of such mechanisms in most of the STEPS > reports .... > > Spreadsheets are simple versions of this > > The Playground language for the Vivarium project was set up like this > > For real scaling, one would like to move to more general semantic > descriptions of "what is needed" and "what is supplied" ... > > Cheers, > > Alan > > ------------------------------ > *From:* Benoît Fleury <benoit.fle...@gmail.com> > *To:* Fundamentals of New Computing <fonc@vpri.org> > *Sent:* Monday, March 19, 2012 1:10 PM > *Subject:* [fonc] Naive question > > Hi, > > I was wondering if there is any language out there that lets you describe > the behavior of an "object" as a grammar. > > An object would receive a stream of events. The rules of the grammar > describe the sequence of events the object can respond to. The "semantic > actions" inside these rules can change the internal state of the object or > emit other events. > > We don't want the objects to send message to each other. A bus-like > structure would collect events and dispatch them to all interested objects. > To avoid pushing an event to all objects, the "bus" would ask first to all > objects what kind of event they're waiting for. These events are the > possible alternatives in the object's grammar based on the current internal > state of the object. > > It's different from object-oriented programming since objects don't talk > directly to each other. > > A few questions the come up when thinking about this: > - do we want backtracking? probably not, if the semantic actions are > different, it might be awkward or impossible to undo them. If the semantic > actions are the same in the grammar, we might want to do some factoring to > remove repeated semantic actions. > - how to represent time? Do all objects need to share the same clock? Do > we have to send "tick" events to all objects? > - should we allow the parallel execution of multiple scenarios for the > same object? What does it make more complex in the design of the object's > behavior? What does it make simpler? > > If we assume an object receive a tick event to represent time, and using a > syntax similar to ometa, we could write a simplistic behavior of an ant > this way: > > # the ant find food when there is a food event raised and the ant's > position is in the area of the food > # food indicates an event of type "food", the question mark starts a > semantic predicate > findFood = food ?(this.position.inRect(food.area)) > > # similar rule to find the nest > findNest = nest ?(this.position.inRect(nest.area)) > > # at every step, the ant move > move = tick (=> move 1 unit in current direction (or pick random > direction if no direction)) > > # the gatherFood scenario can then be described as finding food then > finding the nest > gatherFood = findFood (=> pick up food, change direction to nest) > findNest (=> drop food, change direction to food > source) > > There is probably a lot of thing missing and not thought through. > > But I was just wondering if you know a language to do this kind of things? > > Thanks, > Benoit. > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
