10 —
Due Thursday, 13 November 2025, 11:59:59pm
Purpose to build a model of a mixed-typed language, similar to JavaScript
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 10 within your assigned GitHub repository. The directory should contain the following items:
the executables xjs as specified below;
the sub-directory 10/Tests/ with the required integration test
the sub-directory 10/Special/ with the required special test; and
an optional sub-directory called 10/Other/ for all auxiliary files.
Programming Task Using your favorite programming language, you are to create a complete model of the Mixed language: its syntax and its JavaScript-like semantics. The Mixed language enables programmers to construct a software system that mixes typed and untyped modules.
ExampleGG is an Example whose Names also contain the following keywords: if0, while0, block, def, =, /, +, ==, class, method, isa, new, –>, tmodule, module, timport, import.
See figure 28 for the BNF grammar of systems and import specifications in the Mixed language. For all other productions, consult the preceding milestones. A mixed system consists of typed and untyped modules, with the former importing from the latter and vice versa. The new keyword timport bridges the gap between typed modules that need services from untyped modules.
The typed modules and the body of a mixed system must satisfy typing constraints. Accommodating the import of an untyped module into a typed one calls for one additional validity rule; see figure 29. The rule for type checking complete systems should be modified so it skips untyped modules.
A tmodule must import modules via a timport specification.
A tmodule may not import the same module using two different Shapes.
A tmodule may not import a tmodule using a timport specification.
MixedSystem ::= (MixedModule^*
MixedImport^*
Declaration^*
Statement^*
Expression)
MixedModule ::= (tmodule ModuleName MixedImport^* Class Shape)
| (module ModuleName Import^* Class)
MixedImport ::= (import ModuleName)
| (timport ModuleName Shape)
Figure 28: The concrete syntax of types in the Type language
M is the name of mod in Modules
C is the name of the class defined in mod
[an import]
Modules, SClasses ⊢ (timport M S) ⟹ SClasses [C : S]
Figure 29: Typing rules for imports in mixed systems the Mixed language
Adapt the AST data representation from Typed to Mixed. Update your parser and type checker for Module accordingly.
Implement an additional pass that checks the validity of import specifications.
Consider modifying the rule for type checking systems from figure 20 so that untyped modules (module) are ignored. Your type checker needs to be modified accordingly.
Modify the pass that turns the AST of a well-formed and well-typed Mixed system into a Module AST so that the linker from 8 —
Modules can create a Class program, which can then be run on the Class CESK machine. Note Depending on your chosen implementation language and your choice of AST data representation, your linker might already work for Mixed ASTs or you might find it easy to adapt the linker so that it works this way.
Uncomment the cases of the CESK machine that you commented for 9 —
Static Types. Stop! Why is this necessary?
The xjs program reads one ExampleGG from STDIN, constructs the AST, performs the validity checks, links the system into a complete program, runs the CESK machine, and writes one of the following strings 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 in one of the modules comes with two fields or methods 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;
a number n if the CESK machine produces a number n for the well-formed and valid Mixed system;
"object", if the CESK machine produces an object for the well-formed and valid Mixed system; or
"run-time error" if the CESK machine produces an error outcome for the well-formed and valid Mixed system.
blatant, which (1) type checks and to which (2) the CESK semantics assigns an object, even though fact (1) predicts that its CESK semantics is a number.
insidious, which (1) type checks, (2) has a numeric CESK semantics, and (3) violates a type between a typed and an untyped module.
That is, a value going from typed code to untyped code does not satisfy the specified type, which means that the type checker would flag a fully-typed version of this program.
Extra credit Reconstruct the program in the JavaScript/TypeScript world.
Testing Task Create 10 integration tests for xjs.
A test always consists of inputs, expected
output, and an automated procedure for comparing the actual output
with the expected one. —
Readings Pragmatics and Mixed-Typed Systems If you’d like to know more, take a look at the slightly expanded version [HTML only].