7.1 What is This Assignment’s Purpose?🔗

We want you to think about and build a DSL of your own. You start by choosing a domain and identifying its language elements.

7.2 Assignment🔗

Choose a domain that you find interesting that you’d like to model as a DSL. We will not judge your choice of domain, but rather the quality of your modeling.

Note that if you do a weak or sloppy job here, we will send back the proposal for revision, and we’ll do it as many times as needed until we are satisfied. If you have not gotten approval, you will not be able to do the final project (as in, we will not look at projects whose proposals we did not approve), and this will significantly hurt your course grade! So you have an incentive to do this well.

Since you have probably not thought about these questions before, we have provided a rough template that you can follow to guide your thinking and writing. If for some reason this template is either too restrictive or not applicable…go ahead, do your thing! Don’t be gratuitously different (most languages will fit in the template, and if you don’t follow it it may be harder for us to evaluate), but if you have good reason, feel free to express your individuality. Even if you don’t follow the template strictly, the elements of the template are what we care about the most, so think about how to address them.

7.3 Our Template🔗

Next:

• What are the data in the domain?

• What are the operations in the domain?

Some domains may be operation-rich and data-poor (like finite-state automata), and others may be data-rich and operation-poor (like modeling the relations in a database). It would be surprising if you have a domain that is poor in both and is yet somehow interesting. However, that doesn’t mean you can’t have that! Just be prepared to justify your choice a bit harder in this case. But we love a pleasant surprise!

Next, the semantic properties. While the following properties may not be true for all DSLs, given where DSLs fit in the framing of this course, we expect this part to be particularly rich and interesting:

• Beyond the data and operations, what are the other core concepts or abstractions of the domain?

• What are the interesting relationships/constraints between the core concepts? These are typically the things to check for.

• Which of these relationships would you expect to be baked into the language (i.e., must be true of all programs) and which would be defined explicitly as a property and checked (i.e., would only be true for individual programs)?

• Are the latter properties just from a fixed set (not all programs have them, but the ones that programs do have are standard), or do you need the ability to write down custom properties for some programs?

• Do you anticipate that there will be both static and dynamic errors? If so, what do you expect to be caught when, and why?

• What’s excluded? In what ways is the language’s expressive power limited?

In addition, there may be interesting human-factors considerations:

• Are there notations commonly used in this domain?

• If you could define any tooling you want, what kind of tooling would you like to see?

• Are there any other human-factors considerations?

Next:

• Can you sketch what a few sample programs might look like? If it’s difficult to show on the page, then use prose to give us a sense. If you really can’t, get in touch with the professor and discuss alternative submission formats before the deadline.

Finally:

• Anything else you think is worth saying that doesn’t fall in the above items? (If nothing, please leave blank.)

7.4 What To Hand In🔗

Turn in your proposal!