The goal is to investigate a particular aspect of metaprogramming that is not covered in the regular course material, present a summary of the investigation to the class, and submit a formal paper discussing the topic.

This is a research project, so you are expected to investigate your topic through the use of current journals, available conference papers, appropriate web sites, and any other pertinent sources you can find for information.

Written reports

The written reports must be submitted either as hardcopies or as email attachments in pdf format by 10a.m. on April 4th. They must be 1500-2500 words, must be word-processed (no hand-written documents will be accepted, and papers that are too long or too short will be penalized), and should include sufficient background and explanatory information to be readable by a typical fourth-year computing student. Because effective communication is a crucial part of your general professional development, spelling, grammar, and readability will all be considered in the grading of the submission.

The reports should be laid out in an acceptable fashion for technical reports, complete with abstract, introduction, suitable division into sections and subsections, conclusions, and list of references cited in the report.

Oral presentation

The presentations will be carried out in class in the final two or three lectures, with a specific schedule established in March.

The presentations should be 10-12 minutes in length, followed by 2-4 minutes for class questions.

The mark for the oral presentation will be based on the instructor's assessment and on evaluations submitted by those attending the presentations. The evaluations will cover

• how well the presenter seemed to know their topic
• the clarity of explanations
• the visual effectiveness of the presentation
• the presenter's handling of questions
• the effectiveness of the verbal presentation (speed and clarity of speech, timeliness, looking at the audience, etc)

Advice: the presentation should be geared towards your audience. Provide enough background and enough details so the audience can clearly understand the salient points of your project, but don't get bogged down in details your audience will find tedious or distracting.

Late penalties: late papers will be accepted until 10am April 6th at a penalty of 20% of the total possible mark. No papers will be accepted after that point.

No late presentations will be accepted - you must deliver your presentation in your scheduled time slot or you will receive a mark of 0.

Collaboration and academic integrity: the research papers are to be individual efforts, written and researched on your own - no collaborative work is permitted, and university rules and policies on plagarism and academic fraud will be strictly enforced.

Project option: as an alternative to the research paper, students have an option of pursuing a metaprogramming project. This would involve carrying out the design, implementation, and testing of a suitable software product. To pursue this option the student must meet with the instructor in advance to get permission for the project (to ensure the project itself is of a suitable nature and scope for the course).

Some topic ideas

Notes

- If you cover metaprogramming with a particular tool, language, or library, be sure your focus is on the metaprogramming details/implementation - not simply a recitation of the language syntax/features.

- If you pick a topic we've already covered in lectures/labs, be sure your project tackles depth/detail/features well beyond what we covered in the course.

Topic ideas

• metaprogramming with C++ templates (in substantially greater depth than covered in class)

• implementation of macros/preprocessors for languages in other languages (e.g. source filters in perl) or for languages that do not naturally support them (e.g. bash, ruby)

• implementation of new debugging/analysis tools for a chosen language

• metaprogramming for obfuscation (e.g. to prevent reverse engineering, or for viruses to evade detection)

• self-evolving or mutating code

• genetic algorithms for code generation

• metaprogramming in machine learning (e.g. the implementation of automl)

• metaprogramming for automating code migration (e.g. from one language to another)

• code generation for control systems (e.g. factories)

• the implementation of key Boost features (i.e. how Boost is built, not a study of boost syntax/features)

• the implementation of visual programming tools, such as SNAP and various game development packages, which allow the programmer to select program elements by clicking on appropriate images and dragging them into the "code"

• metaprogramming in other realms (e.g. dna metaprogramming)

• writing programs that self-modify "on-the-fly" in homoiconic languages outside the lisp family (e.g. in tcl, mathematica, wolfram, julia, prolog)

• writing programs that self-modify "on-the-fly" in non-homoiconic languages other than ruby (typically languages supporting some form of eval(string), e.g. python or perl)

• the use of the Warren Abstract Machine (WAM) to form intermediate representations of languages like lisp