Language Theory
Production code is increasingly written by AI coding agents, so the professional value of language design has shifted from developer ergonomics alone toward machine-facing guarantees: grammars and schemas that constrain what a model may emit, type and effect systems that make generated code checkable before it runs, and harnesses that measure where generated programs fail. The course accordingly treats syntax and semantics as the enforcement layer for agent-produced software rather than as purely human-facing notation.
Current description → proposed description
This is an advanced course in current trends of programming language design and implementation. Students will create a modern trends inspired programming language and solve traditional problems using their creation. This course builds on our undergraduate language theory class (CSC 3210).
This advanced course explores the theory and practice of programming language design, with an emphasis on modern trends such as functional paradigms, domain-specific languages, type systems, metaprogramming, and AI-assisted code generation. Building on undergraduate foundations, students examine the formal structures underlying language syntax and semantics, including grammars, parsing, and language evaluation strategies. As a culminating experience, students will design and implement a prototype programming language tailored to a specific problem domain, incorporating features inspired by modern compilers and interpreters. Topics include language abstraction, runtime environments, type inference, garbage collection, and interoperability. The course also addresses the role of language design in emerging fields like Artificial Intelligence and software verification, encouraging students to critically evaluate how language shapes human–machine interaction, developer productivity, and system safety. The course further treats language design as a control surface for autonomous coding agents, using grammars, static types, effect systems, and sandboxed runtimes to make machine-generated programs checkable, reproducible, and accountable.
What changes
- Adopts the workbook's fuller two-paragraph description in place of the three-sentence catalog text
- Adds type systems, metaprogramming, DSLs and functional paradigms as named modern trends
- Treats grammars and type systems as constraints on LLM code generation
- Adds an evaluation harness for AI-generated programs (property-based, differential, LLM-as-judge)
- Adds language-level safety and effect/capability confinement over machine-written code
6 proposed outcomes, mapped to 6 program outcomes
Each outcome below is written to be observable and assessable, and each is mapped to the program learning outcomes for which it produces evidence.
Students will be able to design a formal specification for a domain-specific programming language, expressing its concrete and abstract syntax as an unambiguous grammar and its evaluation strategy as a set of operational semantic rules.
Writing an unambiguous grammar and operational semantic rules is direct application of formal language theory and the discrete mathematics of parsing and evaluation named in PLO 3.1.
Students will be able to implement a working front end and execution model for a defined core subset of that language - lexer, parser, a type checker with inference over that subset, and an interpreter or a compiled backend (one, not both) - with defended runtime decisions governing scoping, memory management, and host interoperability, and with the out-of-scope features named and justified.
Building a type checker with inference and a runtime for a bounded core subset applies the language-theory foundations of PLO 3.1 beyond derivation to executable systems, and naming what is deliberately left out is itself a defended scoping judgement about the theory a 3-credit implementation can carry.
Students will be able to construct machine-facing interfaces for their language - structured output schemas, grammar-constrained decoding, and tool-call surfaces - and to engineer the accompanying system prompt and few-shot exemplar set that adapt a model with no pretraining exposure to the new language, measuring first-attempt validity with and without each constraint.
Writing and iterating the system prompt and exemplar set that make an unfamiliar language usable by an LLM, and measuring the resulting alignment and formatting gains, is the prompt engineering PLO 4.2 names; the ablation that isolates each constraint is run against the grammar itself, which is the language theory of PLO 3.1 applied as a decoding constraint.
Students will be able to evaluate the reliability of AI-generated programs in their language by constructing an evaluation harness that combines static type checking, property-based and differential testing, and calibrated LLM-as-judge review, and by feeding the resulting failure taxonomy back into a revision of the language's grammar, type system, or generation interface, then re-running the harness to demonstrate which failure classes the revision eliminated and which it did not.
Building the harness and selecting metrics for generated-code correctness is the assessment of performance and limitations PLO 6.2 requires, and the revise-and-re-measure cycle supplies the iterative refinement half of that outcome - here the artifact refined on diagnostic evidence is the language and its generation interface rather than a trained model, since those are what determine what the model can emit.
Students will be able to critique the safety guarantees a language design can and cannot extend over machine-generated code - type and memory safety, effect and capability confinement, sandboxed execution - and to produce an accountability statement for a named deployment context that identifies which guarantees are enforced mechanically, which are left to the caller, who bears responsibility when machine-written code in the language causes harm, and what limits must be disclosed to a party depending on it.
The accountability statement is the evidence: naming who answers for harm caused by machine-written code, distinguishing mechanically enforced guarantees from those the caller must supply, and disclosing the design's limits to a dependent party are the accountability, transparency, and potential-harm obligations this outcome names; the workbook states that outcome twice, once under Christian Faith as PLO 1.1 and once under Integrated Disciplinary Knowledge as PLO 3.2, so a CLO that earns one necessarily earns the other.
Students will be able to communicate a language's design rationale, trade-offs, and limits through a written reference specification and a design review defended to both compiler-literate reviewers and non-specialist stakeholders who must depend on the language.
Producing a reference specification and defending the same design to specialist and non-specialist audiences is the dual-audience technical communication PLO 5.1 names, including responsibility for stating the design's limits honestly.
Program outcomes this course reaches
Filled cells are program learning outcomes with at least one supporting course learning outcome in this course. Sparse coverage is expected — no single course carries all twelve.
The workbook maps this course too
The proposal workbook's assessment map already assigns program learning outcomes to this course. The outcomes above were written to cover it.
| Program outcome | Workbook level | In this draft |
|---|---|---|
| PLO 3.1 AI Theory and Mathematics | D | covered |
| PLO 5.1 Communicating AI to Any Audience | I | covered |
I = Introduced · D = Developed · AE = Assessed at Exit