System Implementation
The following group of pages will document about the implementation of the current Source Modules system.
Table of Contents
The js-slang library contains the open-source implementations of the programming language Source. Source is a series of small subsets of JavaScript, designed for teaching university-level programming courses for computer science majors, following Structure and Interpretation of Computer Programs, JavaScript Adaptation (https://source-academy.github.io/sicp/).
The js-slang library exposes one main function that Source Modules system developers should be concerned with, the runInContext method.
runInContext(code: string, context: Context, options: Partial<IOptions> = {}): Promise<Result> { ... }Applying this funciton on a Source program string will trigger the evaluation of the provided Source program string. The object returned from runInContext is of Result type that contains the value which is the result of the last statement in the evaluation of the Source program string. Below is a brief overview of the evaluation process of the runInContext function exposed by the Source implementation library.
The two main methods of evaluating a Source program is through the js-slang interpreter and transpiler with the transpiler being the default mode. Read more about how the Source Modules system is integrated into the two modes in the js-slang page in this section.
Read more about the js-slang Source implementation library here.
The cadet-frontend project contains information regarding the frontend of the Source Academy (https://source-academy.github.io/) immersive online experiential environment for learning programming, developed in the School of Computing at the National University of Singapore. This repository houses the sources for the frontend of the Source Academy, written in ReactJS with Redux.
In the Redux store of the Source Academy frontend, there is the debuggerContext that Source Module developers should be concerned about. The debuggerContext is collected from the Saga middleware, specifically at WorkspaceSaga during evaluation of any Source program. After evaluation of the Source program, an action loaded with debuggerContext is dispatched. The corresponding reducer, WorkspaceReducer, saves the debuggerContext into the Redux store.
Previously, there is almost no information passed by frontend to the Source Module's tabs. In other words, the Source Module tabs and bundle do not have direct access to the program being evaluated.
---> = data flow
---+ = child component (no data flow)
program ---> sagas ---> front-end ---+ source module tab
In the event that the source module tab requires additional information, they have to invent a way to collect the information and pass it to their corresponding module tab. This introduces many 'inventive' ways throughout the code base for their data collection.
---> = data flow
---+ = child component (no data flow)
_______________________
| | 'inventive' collection of data from sagas
| v
program ---> sagas ---> front-end ---+ source module tab
As such, the solution is to introduce a formalised pipeline such that module tabs are able to easily access their required information. The front-end now saves the required data and save it into the store, where module tabs can easily access the required information. This eliminates the need for other 'inventive' ways to be deployed and clutter the code base.
---> = data flow
---+ = child component (no data flow)
------> redux store
| |
program ---> sagas ---> front-end | debuggerContext passed as react component props
| v
---+ source module tab
Read more about cadet-frontend the frontend of Source Academy here.