Module definition language development plan

This is going to be pretty rough to start with, but it should become clearer as we go:

V0.1

Some of this is already done, but I want to revisit in terms of doing all the basic low-level syntax things (literals, identifiers, expressions) in a reasonable way, to add a few more question types and to to add pure call-by-value functions:

1. Basic syntax: literals (numeric, string, boolean, arrays, records); identifiers; simple expressions;

2. Module definitions: framework, metadata, component contents, distinguished "activation" component;

3. Function definitions: pure call-by-value only;

4. Fixed component definitions: SurveyPage, 3-4 Question types;

5. Data collection infrastructure.

V0.2-0.4(?)

The main part of this work will be to implement the LimeSurvey-like question types that are needed for the "standard surveys" we need to deal with.

1. Module namespaces and imports, registration and naming of modules, referencing and linking modules;

2. Translations and the details of general multi-lingual support;

3. Add more question types;

4. Parameterised modules;

5. Improve data collection infrastructure.

V0.5?

At this point, we should be able to do most simpler surveys.

1. Conditions and repetition;

2. Refactor rendering and component definition code (up to this point, I would imagine that all of the question types would have their rendering code written independently, but by now there ought to be enough examples to decide whether it's worth doing something a bit more reusable and general, e.g. a macro system that transforms "high-level" definitions to a low-level "Core" sub-language for rendering; I don't know yet whether or not this will be worth doing)'

3. Any other language features needed for Milestone 1.

LimeSurvey question types

THis is a list of the question types from LimeSurvey, more or less in the order I was thinking of implementing them. Things like more control over HTML rendering and CSS styling and the details of the data collection mechanisms will be refined as I implement more of these things.

In LimeSurvey, questions must be members of question groups. Normally all questions in a group are displayed together and the groups are displayed one after another. It's possible to assign groups to "randomisation sets", within which the group ordering is randomised each time the survey is used. It's also possible to show and hide groups based on responses to earlier questions. These facilities will be implemented by having explicit choice and repetition constructions in the module DSL.

LimeSurvey also has an "Expression Manager" that allows you to interpolate expressions based on results of earlier questions into the text of later questions, to control whether or not a question appears based on Boolean conditions, and so on. All of this functionality can be done just by having basic expression and condition support in the module DSL.

1. Basic SurveyPage question container.

2. Radio button list.

3. Drop-down list.

4. Simple text entry (single-line).

5. Generalise text entry -- parameterisation of size (and component parameterisation mechanism in general).

6. Basic attempt at general array question type.

7. Specialisations of general array question type.

8. Checkbox multiple choice questions.

9. Container for multiple sub-parts.

10. Multiple short text.

11. Multiple choice with comments.

12. List with comments.

13. Calculations and equations.

14. Interpolation into questions.

15. Numerical input types.

16. Input validation rules.

17. Inter-SurveyPage routing.

18. Conditional display, branching and looping.

19. Text display.

20. Simple specialisations: 5-point choice, yes/no, gender.

21. Date.

22. Ranking.

23. File upload.