The document describes an interpreter for a chemical language called Higher Order Chemical Language (HOCL) based on the chemical computing model. The interpreter uses a production system approach with RETE pattern matching to enable efficient execution of the chemical language. Key constructs of the language include passive molecules to represent facts, active molecules to represent rules, and solutions to represent independent computational threads. The interpreter was implemented using Jess rule engine and experiences showed the importance of random conflict resolution and intelligent compilation for chemical modeling applications.

1. S-Cube Learning Package
Executing the HOCL: Concept of a Chemical
Interpreter
INRIA, CNR, SZTAKI
Zsolt Németh, SZTAKI
www.s-cube-network.eu

2. Learning Package Categorization
S-Cube
Service Infrastructure
Multi-level and self-adaptation
Supporting adaptation of
service-based applications

3. Learning Package Overview
 The notion of chemical modeling
 Interpreter for a chemical language
– Design considerations
– Main constructs
– Implementation
 Experiences

4. Background: Complex problems in large
scale distributed computing
• Grid, service based systems, clouds are characterized as
– Large number of interacting entities
– Heterogeneity
– Unknown/unpredictable behaviour
– Dynamicity
• Coordination, scheduling, optimisation and other complex
tasks like
– Service composition
– Workflow enactment
– Process / Service coordination
– Resource scheduling
– Optimisation
– Recovery
 Usually hard to solve/formalize, NP-hard, exact solutions are
slow, etc.

5. Background: Notion of autonomic
computing
 Kephart: The vision of autonomic computing (2003)
 Parts of the system should be able
– Self-configuration
– Self-optimization
– Self-healing
– Self-protection
 Since then many self-* proposals

6. Background: Notion of nature inspired
algorithms
 The vision of autonomic computing ~ nerves
 Nature phenomena like ants, molecules, particles, cells,
membranes, neurons, immune system, foraging, etc.
– possess self-controlled, self-coordinating, self-evolving, etc. properties
 Primitive actions emerge as “intelligent” behaviour
 Computing processes
– can mimic nature phenomena
– inspired by nature metaphors
 See The Chemical Computing model and HOCL Programming
 See Dynamic Adaptation with the Chemical Model

7. The chemical metaphor
 Computational chemistry
– Simulate chemical processes
 Chemical computing model
– Inspired by chemistry; chemistry as a metaphor
– Data = molecules
– Functions = molecules
– Computation = reactions
– State = chemical solution
 Idea: algorithms are artificially sequential
– computing steps should be carried out independently, concurrently
locally
– no notion of serialisation, instructions, computing steps, explicit control
– computation is self-evolving

8. A chemical language
• Higher Order Chemical Language (HOCL)
• based on the -calculus, see The Chemical Computing model and
HOCL Programming
• Higher order: active molecules (procedures)
– capture other active molecules
– produce other active molecules
• Multiset rewriting
• multiset = chemical solution
• active molecules capture other molecules and transform
• replace P by M if C in <>
– P: pattern, captured molecules
– M: action, produced molecules
– C: condition

9. The Dutch flag example
let r = replace <i,red>,<j,white> by <i,white>,<j,red> if i>j in
let w = replace <i,white>,<j, blue> by <i, blue>,<j,white> if i>j in
let b = replace <i,red>,<j,blue> by <i,blue>,<j,red> if i>j in
<<1,blue>,<2,white>,<3,white>,<4,red>,<5,blue>,<6,white>,r,w,b>
2
5 blue
white 6
1
r white
blue
white
3 4 b
w red

10. Chemistry and distributed computing
 Existing models, proposals, concepts
– Self-coordinating distributed systems
– Service composition
– Workflow enactment
– Dynamic workflow
– Desktop grid coordination
 General purpose chemical tools, interpreters do not exist
– Significantly different from current languages, tools,
environments
– Long development cycle
 A short development cycle for chemical tools: combine
multiple models
– Declarative techniques, pattern matching

11. Learning Package Overview
 The notion of chemical modeling
 Interpreter for a chemical language
– Design considerations
– Main constructs
– Implementation
 Experiences

12. Backgorund: the idea of abstract
interpreter
 The chemical model is semantically different from most
computing models
– it is not an imperative language
– it is not deterministic
– it is not related to the von Neumann model
 In such cases an intermediate level of abstraction is
introduced: an abstract engine
– Prolog, Lisp, and many others are executed in this way
 Efficient pattern matching is necessary
– best known algorithm: RETE
– found in many production systems
© S-Cube – 12/<Max>

13. Execution of declarative languages
• Highly abstract computational models
• Executed on von Neumann physical
high level
architectures language
• Notion of abstract machine compile
– hypothetic machine inbetween
abstract
– gives the illusion of executing a highly abstract engine
language natively
interprete
– high level language compiled to an
intermediate language physical
– the intermediate language is interpeted machine

14. Production systems
 A tool for artificial intelligence applications
– knowledge as facts and rules
 Facts
– assumed true
– elementary, learned experience
match
– produced facts
 Rules
– transform the knowledge base
– pattern check action
– condition
– action rule selected

15. Conceptual abstract engine
 Notion of the abstract interpreter
 RETE pattern matching from production system
 Intermediate language: that of production system +
extensions
 To be solved: hierarchical knowledge base
– Law of locality
– Law of membrane
 Parallel/concurrent execution

16. Learning Package Overview
 The notion of chemical modeling
 Interpreter for a chemical language
– Design considerations
– Main constructs
– Implementation
 Experiences

17. Passive molecules
 Facts: statements
– Sorted (1), (1 2 5 apple), (a b 15 22)
- no names but order does matter
– Unsorted ((slot1 a)(slot2 apple)), ((x 2)(y 5)(z 6))
- slots have names
 Molecule template
– (molecule (administrative slots) (instance slots))
- Administrative: id, solution, name
- (deftemplate number extends molecule (slot value)
 (number (value 1))
 (color (type white))

18. Active molecules
 Active molecules → rules?
– a simple solution but in this way active molecules cannot be modified
 Higher order property?
– active molecules can be captured and transformed
– difficult to realize with rules
 Active molecules
– Rule: pattern, condition, action
– Fact: represents the instance
- Derived from molecule template
- Can be asserted, retracted, transferred, etc.

19. Active molecules
 The Dutch flag example
– representation of the “red” molecule
(defrule r
(rule red)
;match <i, red> and <j, white> if i>j
→
;swap <i, red> and <j, white>
)

20. Solutions
 Two-faced entities
– Data when inactive
– Process when active
- Each solution is an independent thread
 Solutions are hierarchical but facts cannot be nested
– It is neither a fact nor a rule
 Bidirectional references between solutions and molecules
– Prolog-like terms
(solution (id x)(in nil)(molecules y z))
(molecule (id y)(in x)(value 5)…)
5 blue
(molecule (id z)(in x)(type blue)…)

21. Solutions
 Single step, flat pattern matching
 The Dutch flag example (cont’d)
(defrule r (solution (id k)(in nil)(molecules j l))
(rule red)
(solution ?x) (molecule (id j)(in k)(value 4)…)
(molecule (value ?i)(in ?x)) (molecule (id l)(in k)(type red)…)
(molecule (color red)(in ?x))
(solution ?y) (solution (id x)(in nil)(molecules y z))
(molecule (value ?j)(in ?y))
(molecule (id y)(in x)(value 2)…)
(molecule (color white)(in ?y))
(test ?i > ?j) (molecule (id z)(in x)(type white)…)
→
;swap <i, red> and <j, white>

22. Relocate
 Most actions are transferring molecules between solutions
– very frequent operation, must be efficient
– must not make the intermediate language too complicated
 Hard to maintain the references in an efficient way when
moving molecules between solutions
– serious performance degradation
– error prone
 External procedure to the language: relocate
– Written in Java
– Operates on the internal data structures
– Adds imperative flavour where necessary

23. Relocate
 There are various types of moving molecules
– Move x from a to b
- replace a:<x, ωa>,b:<ωb> by a:<ωa>,b:<x,ωb>
– Move everything except x from a to b
- replace a:<x, ωa>,b:<ωb> by a:<x>,b:< ωa,ωb>
– Move everything from a to b
- replace a:<ωa>,b:<ωb> by a:<>,b:< ωa,ωb>
 Different for top-level and other solutions
 Deleting solutions
 All 15 cases represented by a single instruction
– Keep the intermediate language simple
– Realize efficiently

24. Relocate
 Relocate (what to move) (what not to move) (from) (to)
 The Dutch flag example (cont’d)
(defrule r
(rule red)
(solution ?x)
(molecule (value ?i)(in ?x))
(molecule (color red)(in ?x))
(solution ?y)
(molecule (value ?j)(in ?y))
(molecule (color white)(in ?y))
(test ?i > ?j)
)
(relocate (molecule (value ?i)(in ?x)) nil (solution
?x) (solution ?y))

25. Learning Package Overview
 The notion of chemical modeling
 Interpreter for a chemical language
– Design considerations
– Main constructs
– Implementation
 Experiences
 Conclusions

26. Implementation
 Initial experiments: CLIPS
– C Language Integrated Production System
 Full implementation: jess
– a rule engine for the Java platform
 Main components
– Interpreter
– Graphical user interface
– Simple debugging and tracing tools
– Custom interfaces

27. Program control
Current reaction
Breakpoints,
adding molecules
at runtime
Molecules Potential reactions
per solution
Debug
information

28. Learning Package Overview
 The notion of chemical modeling
 Interpreter for a chemical language
– Design considerations
– Main constructs
– Implementation
 Experiences
 Conclusions

29. Experiences I
 Importance of random conflict resolution
 Corresponds to random molecule selection
 Foxes and rabbits (Lotka-Volterra) problem
– Predators and preys in a closed environment
– Their number should oscillate
 … Did not oscillate…
 Custom made random conflict resolution was necessary
– unexpected importance of real randomness in molecule selection

30. Experiences II
 Importance of intelligent compilation
 Tic-tac-toe game (custom interface)
– HOCL active molecule ~ rule
- Performance and scalability problems
- On larger boards response times are very long
– HOCL code broken into many simple rules
- Instead of few but complex rules
- Better fits the RETE algorithm (RETE better supports these)
- No performance issues, good scalability
 Intelligent compilation needs further research

31. Learning Package Overview
 The notion of chemical modeling
 Interpreter for a chemical language
– Design considerations
– Main constructs
– Implementation
 Experiences
 Conclusions

32. Conclusion
 The chemical model is a good candidate for autonomic, self-*
computing
 Various possibilities in distributed scenarios
 General purpose tools are needed
 Our approach
– Quick realisation of an interpreter
– Notion of abstract engine
– Combine different models
– Interfaces to the environment

33. Connections to other teaching units
 Foundations
– The Chemical Computing model and HOCL Programming
 Application
– Dynamic Adaptation with the Chemical Model
© S-Cube – 33/<Max>

34. References
Vilmos Rajcsányi, Zsolt Németh: The chemical machine: an interpreter for the Higher Order Chemical
Language. CGWS@EuroPar 2011, to appear.
Jean-Pierre Banatre, Pascal Fradet, and Yann Radenac. Programming self-organizing systems with the
higher-order chemical language. International Journal of Unconventional Computing, 3(3):161–177, 2007

35. Acknowledgements
The research leading to these results has
received funding from the European
Community’s Seventh Framework
Programme [FP7/2007-2013] under grant
agreement 215483 (S-Cube).