►Programming Languages
▼Assignments, Actual
•11 — Mixed:   Linking
9.0.0.1
    contents    up  next → 

11 — Mixed: Linking🔗

Due Thursday, 20 November 2025, 11:59:59pm

Purpose to build a model of a sound mixed-typed programming language (part 1)

This assignment is part of a mini-project about the pragmatics of mixed-typed programming languages like the TypeScript/JavaScript or Typed Racket/Racket combination.

Delivery Deliver your solutions in a directory called 11 within your assigned GitHub repository. The directory should contain the following items:

  • the executables xlink as specified below;

  • the sub-directory 11/Tests/ with the required integration test; and

  • an optional sub-directory called 11/Other/ for all auxiliary files.

The directory 11/ may also contain a Makefile (see —Make) in case you need us to build your executable. An executable should not be checked into a repository.

Programming Task Using your favorite programming language, you are to create a sound linker for the Mixed language. The purpose of a sound linker is to create a Class program that enables a modified CESK machine to check the interactions between typed and untyped code for adherence to the specified types.

The sound linker translates a well-formed and valid Mixed system into the AST of a well-formed and valid Class program where each typed class AST comes with a type field.

To this end, the sound linker combines the existing linker with two new passes:

  1. A synthesis pass synthesizes a new typed module from an untyped module that is imported into a typed context:

    • For an occurrence of (timport M Shape) in module K, this pass creates a typed copy of M named M.into.K annotated with Shape and replaces the import specification in K with (import M.into.K).

    • For an occurrence of (timport M Shape) in the system’s body, this pass creates a typed copy of M named M.into.Body annotated with Shape and replaces the import specification in the system’s body with (import M.into.Body).

    These choices of names make only sense because the pass may assume the program is well-formed and valid according to 10 — A La JS.

    Note The synthesized modules do not get type checked.

  2. A type-it pass ensures that all (ASTs of) class definitions in typed modules are equipped with the module’s type annotation. If you used the hint in the first step of the plan of 9 — Static Types, this pass might be a no-op.

    A modified CESK machine will use these type annotations to protect the classes from originally typed modules during interactions with synthesized modules.

The resulting AST is then sent to the existing linker, which produces an (AST of) a Class program that can run on the CESK machine as is and a modified version.

The xlink program reads one ExampleGG from STDIN, constructs the AST, performs the validity checks, links the system into a complete program, and writes one of the following to STDOUT: The outcomes are listed in the order in which they may occur for a given program.

  • "parser error" if the given ExampleGG is not an element of the Mixed grammar;

  • "duplicate module name" if in the well-formed Mixed system, at least two of the module definitions come with the same name;

  • "duplicate method, field, or parameter name" if in the well-formed Mixed system one class definition one method definition, or one Shape comes with (at least) two fields, methods, or parameters that have the same name;

  • "bad import" if in the well-formed Mixed system one of the validity constraints concerning imports into tmodules is violated;

  • "undeclared variable error" if in the well-formed Mixed system one of the variable references comes without declaration or one reference to a ClassName (in a statement or an expression) comes without a (possibly imported) class definition;

  • "type error" if in the well-formed Mixed system one of the typed pieces of code fails to satisfy one of the typing judgments;

  • the names of all modules that the sound linker creates for a well-formed and valid Mixed system.

    The names are printed in the following form:
    [ ModuleNameAsString1, ..., ModuleNameAsStringn ] .

    A ModuleNameAsString is ModuleName surrounded with string quotes.

    For these outputs, the test harness will compare the expected result with the actual result via set equality. That is, the ordering does not matter.

Testing Task Create 10 integration tests for xlink.

A test always consists of inputs, expected output, and an automated procedure for comparing the actual output with the expected one. — For this course, an integration test consists of a pair of files: n-in.ss, the input file, and n-out.ss, the expected output file, where n is an integer between 0 and the requested number of tests (exclusive). The comparison procedure is (string or numeric) equality on the content of the output file and the actual output. — Constraint No test file may exceed the size limit of 5Kb.

    contents    up  next →