There's a good amount of theory floating around that motivates discourse control. A lot of it, however, is rendered useless by the crudeness of our interpreter. We don't need to handle all the ways of pushing and popping through a conversation that exist, because we aren't capable of having a real conversation in the first place. However, the program that I wanted to write was intended to be theoretically sound as far as it went, and also to be easy to modify.
Since the theory behind this section is fairly simple, and there isn't any code, I won't summarize it here. Look at the sources page for some references on discourse control and pragmatics, or read chapters 14 and 15 in Allen.
The basic pragmatic problems facing us are dealing with the reference and context of the users' statements, deciding when to take the floor in a dialogue, handling the obligations the user forces on us (answering questions, giving recommendations when asked and so forth), carrying on our own plan for a dialogue (eliciting information and using it to design user schedules, disambiguating via questions, showing off our special functionality), and remembering the useful facts we learn about each user.
Reference and context are only loosely related to these other problems, and have a separate class in the code. The other problems are mostly unsolved, even at the design stage.
A useful system will have to be easily modifiable in terms of our discourse goals; we should be able to write new scripts for any reasonable eventuality by stringing together a few chunks of code. It should be capable of handling multiple output modalities, including TCP to control (our messages to control can be thought of as 'statements' in the dialogue). We should also be prepared for text-to-speech and GUI modes, but there may be others. We will have to be robust in the face of users who refuse to accept their conversational responsibilities (not saying 'hello', or abruptly changing the subject), and give polite, explanatory messages when lower-level components fail.
We anticipate learning the name of each user by reading their nametag, and at minimum we should greet them by name. We can also initialize a model of their likes and dislikes, or whether we have already asked them certain questions, or both. Alternately, the like/dislike model may reside in Prolog. It may or may not be worthwhile to reinitialize the parser for each user (see the name allocation problem in architecture), but the interpreter should be constant if we want to network between users by comparing their preferences.
If necessary, the system might ask disambiguation questions to resolve unclear referents; discourse control should be prepared to handle this if possible.
A very feasible goal I proposed at the beginning of the semester would be to design and print each user's customized conference schedule. The system would ask questions like Are you interested in robotics? or What speaker do you like?, and use these preferences to infer what events the user is interested in, using a simple frame-filling model to decide what to ask next. Replies to questions like these are easy to parse and interpret, and can be added to the database via the interpreter's believe function. As slots in the schedule were filled, the system could start trying to construct a schedule. When this was complete, it could use a portable printer and Java's printing API to print the schedule with the interesting events highlighted.
While this is a challenging problem, I think it is both solvable and likely to impress people. Apart from discourse control problems and the actual logical inferences needed to construct the schedule, the system basically contains all the components needed.