Dataflow Engine

[drernie]

In Swan Theory, a programming language consists primary of:

• names
• transformations
• dataflow

Traditional programming languages are implemented as monolithic parsers and evaluators. Swan languages are implemented as atomic transformations linked by a dataflow engine.

The basic idea is that every dictionary has a reduce function for iterating over its components (with map being a special case). The reduce also takes an out parameter identifying the next stage of the pipeline.

Each rule in our symbol table would similarly have an out parameter, making it trivial to chain them together contextually. The signature would probably be something like:

   rule = (key, dict, out) -> 

You probably already have something like this for handling nested dictionaries and recursive generation of HTML elements. This issue is a suggestion to make that design pattern explicit, perhaps even as a prototype we could apply to input dictionaries.

That way, instead of hard-wiring our language together, we can simply implement it as a pipeline. Something like:

   input_dictionary.map (interpreter.map (layout.map server))

[drernie]

Actually, it should probably be more like:

kiosk_dict.pipe paginator .pipe tagifier .pipe renderer .pipe viewer

1. The first transform takes a semantic kiosk description and creates a series of pages.
2. The second uses layout templates to generate the tag dictionaries
3. The third turns the dictionaries into HTML.
4. The last is responsible for updating the HTML the user is watching

Interestingly, the paginator will likely need to access parent dictionaries (e.g., ads). Instead of complete worlds, it might be sufficient to add a 'get' or 'find' method that checks for an 'up' property if the name is not found locally.

[drernie]

I think the existing implementation is sufficient, at least for now. Closing.