Add proof-of-concept for handling module types in Source Typed

[zhaojj2209]

Part of #1399

This PR adds a basic implementation of module type handling in Source Typed, using the rune module as an example. Source Typed is now able to properly handle types for runes, as well as throw errors when attempting to import a name that does not exist in the module.

Summary of implementation:

• A map of names available in the runes module to their respective type information is created (see runeTypes.ts). The map also contains an extra prelude attribute, which contains the types shared by variables and functions in the module (in this case, Rune and AnimatedRune). The type information in the map are in the form of Source Typed code strings (constant/function/type alias declarations) which can be evaluated by the Source Typed type checker. To hide the actual implementation of the module, the code in the map are placeholder code that only serves to save the correct types in the type environment when the code is evaluated. The types for the variables/functions are retrieved from the rune module documentation.
• When encountering import statements that import from the rune module, the Source Typed type checker will fetch the prelude code + code for the names imported for that module, and evaluate the code as a program string. Following evaluation, the correct types for the module names will be saved in the type environment for use in the rest of the program.

Sample screenshots:

To test this PR, link local js-slang to local frontend and write runes module code in any of the Source Typed chapters. Some unit tests have also been written.

To expand this proof-of-concept to an implementation that is extensible to all modules, the following needs to be done:

• The map of module names to types (runeTypes.ts) should be shifted to the modules repo. All future module type maps should be written in the modules repo instead and made available for fetching (e.g. as JSON files).
• The TODO: Add logic for fetching module type declarations map from modules repo code should be replaced with logic that fetches the module maps from the module repo as and when needed.

When writing module type maps, note the following:

• The map must contain a prelude attribute that contains code for the types shared by variables and functions in the module. If there are no shared types, an empty string should be provided.
• Code in the map should be placeholder code that hides the actual module implementation and only provides the correct types needed.
• The module map must contain all names in the module, else the NameNotFoundInModule error will be thrown for names that are not in the module map.
• Types in the map must be consistent with the modules documentation.

Limitations in the current approach:

• Since the placeholder value for runes is the string 'Rune', type errors will not be thrown if attempting to assign type string to the rune. This is an unfortunate result of hiding the module implementation using Source primitive values. One possible solution would be to add special placeholder type for modules, however this will likely require more extensive changes to Source Typed, and is currently out of scope for this PR.

[coveralls]

Pull Request Test Coverage Report for Build 5999214362

• 37 of 40 (92.5%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.04%) to 82.715%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/errors/typeErrors.ts	8	9	88.89%
src/typeChecker/typeErrorChecker.ts	28	30	93.33%

Totals
Change from base Build 5995455758:	0.04%
Covered Lines:	10803
Relevant Lines:	12619

---

💛 - Coveralls

[martin-henz]

Yes as a proof-of-concept this is interesting. I don't think we should start hard-wiring module types into js-slang as in https://github.com/source-academy/js-slang/pull/1467/files#diff-2e2aa2db6619eec1be92cd4c227f51bafd0c3e8a0ba28a58c105e5e08944ec5d

Instead, the module should provide the types to be used in Source §x Typed.

We need to take a closer look at this next year.

[martin-henz]

Closing this issue in favor of source-academy/modules#217