Empirical Modelling and the use of LISP macros

This is an interesting study, and sounds technically very challenging. There's no doubt that you are doing enough work to justify an excellent reward, but you will need to be sure that you orient all your efforts towards an EM theme. (It's hard to give credit for exercises in EDEN programming per se, however virtuosic they may be.)

You have identified some sensible reasons for building in LISP features into EDEN. The two main ones are perhaps:

1. you can make use of sophisticated LISP functions in framing dependencies in EDEN.
2. you can use LISP macros to generate complex families of definitions in EDEN.

It is important that you link your work to what has already been ventured in EDEN. For 2, this means taking a look at / critiquing the macro mechanisms that exist in EDEN, as documented in the EDEN handbook. The ideas behind the "definition factory" prototyped in JS-EDEN emile last year - see Lab 9 from 2012 are also relevant. For 1, note that, at an early stage in the development of EDEN we got rather excited about the potential for blending EDEN with functional programming, and Simon Yung built a front-end to Miranda called Admira ("A definitive Miranda") which we assumed would provide a powerful environment for EM (see /dcs/acad/wmb/public/projects/notations/admira). It was then that we realised that EM was not about framing sophisticated dependencies using the richest abstract functions we could specify - the criterion for whether a dependency was appropriately framed was essentially experiential in character - can the modeller become so fluent in appreciating the relationships between an observable and the observables in terms of which it's defined that they directly experience the connection?This brings completely different priorities to the mechanisms used to frame definitions - firstly, how the values of variables are mediated to the user becomes critical, and secondly, the relationships that are expressed in functional terms have to be sufficiently simple to be 'experienceable'.

Important also that your writing reflects understanding of what has already been discussed in the module (and which you may have missed through absence earlier this term) - relevant sessions were those concerned with critiquing noughts-and-crosses in Miranda from an EM perspective (see Session 4.3), and the discussion of Imagine-d Logo (see Session 7.3). You may also want to consider (most probably as potential future work rather than yet more to be actually implemented!) the prospects for adding a "definitive LISP notation" to EDEN using the AOP. Finally, there's the challenge that we all face in writing about EM in its relation to programming. When you describe EM as "heavily reliant on remembering states and procedural code" for instance, this could reflect good understanding (as in "EM is all about modelling state and transitions between states, so cannot be declarative in character") or misdirect the reader into thinking that EM is somehow identifiable with a variety of procedural programming.

Note that the final section seems to end mid-sentence. Though this is somewhat tantalising it may not be significant. For instance,