Creating an Abstract Definitive Machine Plugin for JS-EDEN

This is a bold and challenging proposal even though you have made considerable effort to constrain the scope. Your abstract shows that you have gained a good grasp of key issues behind the conception of the ADM. I like the nonchalant way in which you write "the model for this coursework would be fairly simple" when I consider the conceptual difficulties that the ADM has posed in every attempt at practical implementation. It is important that you realise (perhaps you do!) that the credit for the modelling study will not be confined to the work you do on making a model for the ADM (such as the systolic array model you propose to implement using the ADM you develop), but will embrace your work on the design and implementation of the (prototype) ADM itself. Any practical contribution you can make here would be much appreciated - as you will have noticed, this aspect of the CS405 module is the one that has the most sketchy support from the tools in their current state.

It is natural to assume that first of the three 'uses of the ADM' you refer to is the simplest. Certainly it is the most closely related to a conventional machine. From an EM perspective, though, we know that behaviours that are machine-like are amongst the most sophisticated - they are the end-result of an elaborate process of searching for and crafting agency within its context. When you refer to the fact that the "machine step should be slow enough for the human agent to recognise the states of the system, to give them the possibility of interacting and understanding", you are highlighting this perspective, and this may in fact be the best place to focus your attention. Making an environment in which to simulate the human-driven execution of the ADM on top of JS-EDEN is probably quite close to what you have in mind to do anyway. The ingredient that makes this particular attractive as an exercise in EM is the role that experience can have in the development of program-like behaviours, and for this the idea of constructing visual elements and modelling the dependencies between them is crucial. There might be a shift in emphasis in the kind of definitions you have to consider here, with what Matt Cranham characterised in the emile variant of JS-EDEN as 'drawables' being well-represented. If you wanted to pursue this direction, and make manually walking through the execution of an ADM instantiation the primary focus of your submission (how hard it is to characterise this notion of constructing a behaviour in words!), then Chapter 2 of Ashley Ward's thesis (on which the brief account of the "Authentic ADM" featuring in the slides from CS405 is based - see Session 8.3) has some valuable reading (especially section 2.3 on the operational semantics). As Ashley's account makes clear, the topic of interference between actions to be performed in parallel in the (A)ADM is rich and interesting in itself, and this is something which a manual mode of execution could readily highlight.

Finally, as a reminder of something we have already discussed, should you choose to focus on the systolic array example, you may find something relevant / of interest in the work of Patrick Sockett (the SAND project: sandSockett1992) and the AOP implementation of SAND by Antony Harfield - see sandHarfield2003(in both cases outstanding work done in final year projects). You may also find it helpful to explore parsing in a JS-EDEN framework following the work of Hui Zhu that will be the subject of the lab in Week 10.