Ideas to Jot

Interpreter

Here is an idea for a more versatile Interpreter format that will allow for things like error handling and backtracing to be more streamlined.

A trait << Interpreter >> which contains Interpreter Components to perform tasks at each step of the Interpreter Pipeline.

The Interpreter Components that each Interpreter must have:

• InputReader
• Lexer
• Parser
• Translator
• Executor
• OutputWriter

Each component should share a similar interface to generalize the pipeline. The primary method for executing each component will take in an InterpreterComponentInput (ICI) and produce an InterpreterComponentOutput (ICO).

The format for an ICO is:

• A field for InterpreterComponentReturnStatus (ICRS), which indicates the success/fail status of the execution of the component.
• A field for InterpreterComponentState (ICS), which is an externally-visible-equivalent of the internal state that the component was left on when the pipeline execution leaves the component.
• A field for InterpreterPipelineData (IPD), which is the data that the component produces for the Interpreter to process and pass onto the next component.

The format for an ICI is:

• A map containing strategies to be injected into the IC, for which the component decides what map keys are used.
• A field for InterpreterPipelineData (IPD), which is the data that the component takes in to process from the previous component.

The following can mixin the IPD trait:

• the Token trait
• the ParseNodeLike trait
• LanguageInternalRepresentation (LIR) Objects
• a wrapper around a character sequence / string
• a wrapper around "None" for empty data

Here is a list of potential I/O for each component:

• InputReader: ICI - None, ICO - character sequence
• Lexer: ICI - character sequence, ICO - Tokens
• Parser: ICI - Tokens, ICO - syntax tree (ParseNodes)
• Translator: ICI - syntax tree, ICO - LIR Objects
• Executor: ICI - LIR Objects, ICO - LIR Objects ?? eg to save serialized output ??
• OutputWriter: ICI - LIR Objects, ICO - character sequence

E.g. InteractiveInterpreter extends Interpreter and can decide to use components with interactive elements that provide user feedback. GraphicalInterpreter extends Interpreter and may use a Java Swing GUI to take in input / write output text.

The above examples show how the user-level I/O can be decoupled from the Interpreter's internal components.

The ICRS and ICS of each component's output can be used by the Interpreter's pipeline logic for decision-making. Instead of the current dodgy system of the Parser calling the Lexer whenever it feels like it needs more input to complete a parse node, a ICRS-ICS combination will lead the Interpreter to decide whether it is safe to move on to translation or to backtrack all the way to the InputReader to collect more input. This allows complete decoupling between the Interpreters' components. A central decision-making process will be able to marshal data between the components and decide when to execute them.