@eagleoutice/flowr 2.6.2 → 2.7.0

package/documentation/{print-core-wiki.js → wiki-core.js}

@@ -1,18 +1,7 @@
 "use strict";
-var __importDefault = (this && this.__importDefault) || function (mod) {
-    return (mod && mod.__esModule) ? mod : { "default": mod };
-};
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.WikiCore = void 0;
 exports.inspectContextExample = inspectContextExample;
-const shell_1 = require("../r-bridge/shell");
-const log_1 = require("../../test/functionality/_helper/log");
-const log_2 = require("../util/log");
-const doc_auto_gen_1 = require("./doc-util/doc-auto-gen");
-const doc_structure_1 = require("./doc-util/doc-structure");
-const doc_files_1 = require("./doc-util/doc-files");
-const doc_cli_option_1 = require("./doc-util/doc-cli-option");
-const doc_types_1 = require("./doc-util/doc-types");
-const path_1 = __importDefault(require("path"));
 const doc_code_1 = require("./doc-util/doc-code");
 const extractor_1 = require("../dataflow/extractor");
 const parser_1 = require("../r-bridge/parser");
@@ -43,17 +32,27 @@ const doc_issue_1 = require("./doc-util/doc-issue");
 const pipeline_executor_1 = require("../core/pipeline-executor");
 const pipeline_1 = require("../core/steps/pipeline/pipeline");
 const static_slicer_1 = require("../slicing/static/static-slicer");
-const config_1 = require("../config");
 const flowr_analyzer_builder_1 = require("../project/flowr-analyzer-builder");
 const flowr_analyzer_1 = require("../project/flowr-analyzer");
+const flowr_analyzer_context_1 = require("../project/context/flowr-analyzer-context");
+const doc_maker_1 = require("./wiki-mk/doc-maker");
+const process_value_1 = require("../dataflow/internal/process/process-value");
+const graph_1 = require("../dataflow/graph/graph");
+const process_named_call_1 = require("../dataflow/internal/process/process-named-call");
+const doc_cli_option_1 = require("./doc-util/doc-cli-option");
+const doc_files_1 = require("./doc-util/doc-files");
+const doc_structure_1 = require("./doc-util/doc-structure");
+const shell_1 = require("../r-bridge/shell");
+const log_1 = require("../../test/functionality/_helper/log");
+const log_2 = require("../util/log");
 async function makeAnalyzerExample() {
     const analyzer = await new flowr_analyzer_builder_1.FlowrAnalyzerBuilder()
-        .addRequestFromInput('x <- 1; y <- x; print(y);')
         .amendConfig(c => {
         c.ignoreSourceCalls = true;
     })
         .setEngine('tree-sitter')
         .build();
+    analyzer.addRequest('x <- 1; y <- x; print(y);');
     return analyzer;
 }
 async function extractStepsExample(analyzer) {
@@ -62,6 +61,9 @@ async function extractStepsExample(analyzer) {
     const cfg = await analyzer.controlflow();
     return { normalizedAst, dataflow, cfg };
 }
+/**
+ * Shows how to use the query API to perform a static slice (please do not simplify).
+ */
 async function sliceQueryExample(analyzer) {
     const result = await analyzer.query([{
             type: 'static-slice',
@@ -70,26 +72,23 @@ async function sliceQueryExample(analyzer) {
     return result;
 }
 /**
- *
+ * Shows how to inspect the context of an analyzer instance.
  */
 function inspectContextExample(analyzer) {
     const ctx = analyzer.inspectContext();
     console.log('dplyr version', ctx.deps.getDependency('dplyr'));
     console.log('loading order', ctx.files.loadingOrder.getLoadingOrder());
 }
-async function getText(shell) {
-    const rversion = (await shell.usedRVersion())?.format() ?? 'unknown';
-    const sampleCode = 'x <- 1; print(x)';
-    const { info, program } = (0, doc_types_1.getTypesFromFolder)({
-        rootFolder: path_1.default.resolve('./src'),
-        inlineTypes: doc_types_1.mermaidHide
-    });
-    const testInfo = (0, doc_types_1.getTypesFromFolder)({
-        rootFolder: path_1.default.resolve('./test'),
-        inlineTypes: doc_types_1.mermaidHide
-    }).info;
-    return `${(0, doc_auto_gen_1.autoGenHeader)({ filename: module.filename, purpose: 'core', rVersion: rversion })}
-
+/**
+ * https://github.com/flowr-analysis/flowr/wiki/Core
+ */
+class WikiCore extends doc_maker_1.DocMaker {
+    constructor() {
+        super('wiki/Core.md', module.filename, 'core');
+    }
+    async text({ shell, treeSitter, ctx }) {
+        const sampleCode = 'x <- 1; print(x)';
+        return `
 This wiki page provides an overview of the inner workings of _flowR_.
 It is mostly intended for developers that want to extend the capabilities of _flowR_
 and assumes knowledge of [TypeScript](https://www.typescriptlang.org/) and [R](https://www.r-project.org/).
@@ -98,21 +97,21 @@ In case you are new and want to develop for flowR, please check out the relevant
 and the [Contributing Guidelines](${doc_files_1.RemoteFlowrFilePathBaseRef}/.github/CONTRIBUTING.md).
 
 ${(0, doc_structure_1.block)({
-        type: 'NOTE',
-        content: `
+            type: 'NOTE',
+            content: `
 Essentially every step we explain here can be explored directly from flowR's REPL in an interactive fashion (see the [Interface](${doc_files_1.FlowrWikiBaseRef}/Interface#using-the-repl) wiki page).
 We recommend to use commands like ${(0, doc_cli_option_1.getReplCommand)('parse')} or ${(0, doc_cli_option_1.getReplCommand)('dataflow*')} to explore the output of flowR using your own samples.
 As a quickstart you may use:
 
 ${await (0, doc_repl_1.documentReplSession)(shell, [{
-                command: `:parse "${sampleCode}"`,
-                description: `Retrieves the AST from the ${(0, doc_types_1.shortLink)(shell_1.RShell.name, info)}.`
-            }])}
+                    command: `:parse "${sampleCode}"`,
+                    description: `Retrieves the AST from the ${ctx.link(shell_1.RShell)}.`
+                }])}
 	
 If you are brave (or desperate) enough, you can also try to use the ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'verbose')} option to be dumped with information about flowR's internals (please, never use this for benchmarking).
 See the [Getting flowR to Talk](#getting-flowr-to-talk) section below for more information.
 `
-    })}
+        })}
 	
 * [Creating and Using a flowR Analyzer Instance](#creating-and-using-a-flowr-analyzer-instance)
 * [Pipelines and their Execution](#pipelines-and-their-execution)
@@ -127,90 +126,91 @@ See the [Getting flowR to Talk](#getting-flowr-to-talk) section below for more i
 
 ## Creating and Using a flowR Analyzer Instance
 
-The ${(0, doc_types_1.shortLink)(flowr_analyzer_builder_1.FlowrAnalyzerBuilder.name, info)} class should be used as a starting point to create analyses in _flowR_.
-It provides a fluent interface for the configuration and creation of a ${(0, doc_types_1.shortLink)(flowr_analyzer_1.FlowrAnalyzer.name, info)} instance:
+The ${ctx.link(flowr_analyzer_builder_1.FlowrAnalyzerBuilder)} class should be used as a starting point to create analyses in _flowR_.
+It provides a fluent interface for the configuration and creation of a ${ctx.link(flowr_analyzer_1.FlowrAnalyzer)} instance:
 
-${(0, doc_types_1.printCodeOfElement)({ program, info, dropLinesStart: 1, dropLinesEnd: 2, hideDefinedAt: true }, makeAnalyzerExample.name)}
+${ctx.code(makeAnalyzerExample, { dropLinesStart: 1, dropLinesEnd: 2, hideDefinedAt: true })}
 
 Have a look at the [Engine](${doc_files_1.FlowrWikiBaseRef}/Engines) wiki page to understand the different engines and parsers you can use.
 
 The analyzer instance can then be used to access analysis results like the [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized-AST),
 the [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow-Graph), and the [controlflow graph](${doc_files_1.FlowrWikiBaseRef}/Control-Flow-Graph):
 
-${(0, doc_types_1.printCodeOfElement)({ program, info, dropLinesStart: 1, dropLinesEnd: 2, hideDefinedAt: true }, extractStepsExample.name)}
+${ctx.code(extractStepsExample, { dropLinesStart: 1, dropLinesEnd: 2, hideDefinedAt: true })}
 
-The underlying ${(0, doc_types_1.shortLink)(flowr_analyzer_1.FlowrAnalyzer.name, info)} instance will take care of caching, updates, and running the appropriate steps.
+The underlying ${ctx.link(flowr_analyzer_1.FlowrAnalyzer.name)} instance will take care of caching, updates, and running the appropriate steps.
 It also exposes the [query API](${doc_files_1.FlowrWikiBaseRef}/Query-API):
 
-${(0, doc_types_1.printCodeOfElement)({ program, info, dropLinesStart: 1, dropLinesEnd: 2, hideDefinedAt: true }, sliceQueryExample.name)}
+${ctx.code(sliceQueryExample, { dropLinesStart: 1, dropLinesEnd: 2, hideDefinedAt: true })}
 
-One of the additional advantages of using the ${(0, doc_types_1.shortLink)(flowr_analyzer_1.FlowrAnalyzer.name, info)} is that it provides you with context information about the analyzed files:
+One of the additional advantages of using the ${ctx.link(flowr_analyzer_1.FlowrAnalyzer.name)} is that it provides you with context information about the analysed files:
 
-${(0, doc_types_1.printCodeOfElement)({ program, info, dropLinesStart: 1, dropLinesEnd: 1, hideDefinedAt: true }, inspectContextExample.name)}
+${ctx.code(inspectContextExample, { dropLinesStart: 1, dropLinesEnd: 1, hideDefinedAt: true })}
 
 ## Pipelines and their Execution
 
-At the core of every analysis done via a ${(0, doc_types_1.shortLink)(flowr_analyzer_1.FlowrAnalyzer.name, info)} is the ${(0, doc_types_1.shortLink)(pipeline_executor_1.PipelineExecutor.name, info)} class which takes a sequence of analysis steps (in the form of a ${(0, doc_types_1.shortLink)('Pipeline', info)}) and executes it
+At the core of every analysis done via a ${ctx.link(flowr_analyzer_1.FlowrAnalyzer)} is the ${ctx.link(pipeline_executor_1.PipelineExecutor)} class which takes a sequence of analysis steps (in the form of a ${ctx.link('Pipeline')}) and executes it
 on a given input. In general, these pipeline steps are analysis agnostic and may use arbitrary input and ordering. However, two important and predefined pipelines, 
-the ${(0, doc_types_1.shortLink)('DEFAULT_DATAFLOW_PIPELINE', info)} and the ${(0, doc_types_1.shortLink)('TREE_SITTER_DATAFLOW_PIPELINE', info)} adequately cover the most common analysis steps 
+the ${ctx.link('DEFAULT_DATAFLOW_PIPELINE')} and the ${ctx.link('TREE_SITTER_DATAFLOW_PIPELINE')} adequately cover the most common analysis steps 
 (differentiated only by the [Engine](${doc_files_1.FlowrWikiBaseRef}/Engines) used).
 
 ${(0, doc_structure_1.block)({
-        type: 'TIP',
-        content: `
+            type: 'TIP',
+            content: `
 	You can hover over most links within these wiki pages to get access to the tsdoc comment of the respective element. 
 	The links should direct you to the up-to-date implementation.
 `
-    })}
+        })}
 	
 Using the [\`tree-sitter\` engine](${doc_files_1.FlowrWikiBaseRef}/Engines) you can request a dataflow analysis of a sample piece of R code like the following:
 
 ${(0, doc_code_1.codeBlock)('typescript', `
 const executor = new PipelineExecutor(TREE_SITTER_DATAFLOW_PIPELINE, {
 	parser:  new TreeSitterExecutor(),
-	request: requestFromInput('x <- 1; y <- x; print(y);')
+	context: contextFromInput('x <- 1; y <- x; print(y);')
 });
 const result = await executor.allRemainingSteps();
 `)}
 
-This is, roughly, what the ${(0, doc_types_1.shortLink)('dataflow', info)} function does when using the [\`tree-sitter\` engine](${doc_files_1.FlowrWikiBaseRef}/Engines).
-We create a new ${(0, doc_types_1.shortLink)(pipeline_executor_1.PipelineExecutor.name, info)} with the ${(0, doc_types_1.shortLink)('TREE_SITTER_DATAFLOW_PIPELINE', info)} and then use ${(0, doc_types_1.shortLink)(`${pipeline_executor_1.PipelineExecutor.name}::${new pipeline_executor_1.PipelineExecutor(default_pipelines_1.TREE_SITTER_PARSE_PIPELINE, { parser: new tree_sitter_executor_1.TreeSitterExecutor(), request: (0, retriever_1.requestFromInput)('') }, config_1.defaultConfigOptions).allRemainingSteps.name}`, info)} 
+This is, roughly, what the ${ctx.link('dataflow')} function does when using the [\`tree-sitter\` engine](${doc_files_1.FlowrWikiBaseRef}/Engines).
+We create a new ${ctx.link(pipeline_executor_1.PipelineExecutor)} with the ${ctx.link('TREE_SITTER_DATAFLOW_PIPELINE')} and then use 
+${ctx.link(`${pipeline_executor_1.PipelineExecutor.name}::${pipeline_executor_1.PipelineExecutor.prototype.allRemainingSteps.name}`)} 
 to cause the execution of all contained steps (in general, pipelines can be executed step-by-step, but this is usually not required if you just want the result).
 
-In general, however, most flowR-internal functions which are tasked with generating dataflow prefer the use of ${(0, doc_types_1.shortLink)(default_pipelines_1.createDataflowPipeline.name, info)} as this function
+In general, however, most flowR-internal functions which are tasked with generating dataflow prefer the use of ${ctx.link(default_pipelines_1.createDataflowPipeline)} as this function
 automatically selects the correct pipeline based on the engine used.
 
 ### Understanding Pipeline Steps
 
-Everything that complies to the ${(0, doc_types_1.shortLink)('IPipelineStep', info)} interface can be used as a step in a pipeline, with the most important definition being the
+Everything that complies to the ${ctx.link('IPipelineStep')} interface can be used as a step in a pipeline, with the most important definition being the
 \`processor\` function, which refers to the actual work performed by the step.
-For example, the ${(0, doc_types_1.shortLink)('STATIC_DATAFLOW', info)} step ultimately relies on the ${(0, doc_types_1.shortLink)(extractor_1.produceDataFlowGraph.name, info)} function to create a [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow-Graph) 
+For example, the ${ctx.link('STATIC_DATAFLOW')} step ultimately relies on the ${ctx.link(extractor_1.produceDataFlowGraph)} function to create a [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow-Graph) 
 using the [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized-AST) of the program.
 
 ### Shape of a Pipeline Step
 
-Using code, you can provide an arbitrary pipeline step to the executor, as long as it implements the ${(0, doc_types_1.shortLink)('IPipelineStep', info)} interface:
+Using code, you can provide an arbitrary pipeline step to the executor, as long as it implements the ${ctx.link('IPipelineStep')} interface:
 
-${(0, doc_types_1.printHierarchy)({ program, info, root: 'IPipelineStep', maxDepth: 0 })}
+${ctx.hierarchy('IPipelineStep', { maxDepth: 0 })}
 
-Every step may specify required inputs, ways of visualizing the output, and its dependencies using the ${(0, doc_types_1.shortLink)('IPipelineStepOrder', info)} interface.
+Every step may specify required inputs, ways of visualizing the output, and its dependencies using the ${ctx.link('IPipelineStepOrder')} interface.
 As the types may seem to be somewhat confusing or over-complicated, we recommend you to look at some existing steps, like 
-the ${(0, doc_types_1.shortLink)('PARSE_WITH_R_SHELL_STEP', info)} or the ${(0, doc_types_1.shortLink)('STATIC_DATAFLOW', info)} step.
-The pipeline executor should do a good job of scheduling these steps (usually using a topological sort), and inferring the required inputs in the type system (have a look at the ${(0, doc_types_1.shortLink)(pipeline_1.createPipeline.name, info)} function if you want to know more).
+the ${ctx.link('PARSE_WITH_R_SHELL_STEP')} or the ${ctx.link('STATIC_DATAFLOW')} step.
+The pipeline executor should do a good job of scheduling these steps (usually using a topological sort), and inferring the required inputs in the type system (have a look at the ${ctx.link(pipeline_1.createPipeline)} function if you want to know more).
 
 ${(0, doc_structure_1.block)({
-        type: 'NOTE',
-        content: `
+            type: 'NOTE',
+            content: `
 Under the hood there is a step-subtype called a decoration. Such a step can be added to a pipeline to decorate the output of another one (e.g., making it more precise, re-adding debug info, ...).
-To mark a step as a decoration, you can use the \`decorates\` field in the ${(0, doc_types_1.shortLink)('IPipelineStepOrder', info)} interface.
+To mark a step as a decoration, you can use the \`decorates\` field in the ${ctx.link('IPipelineStepOrder')} interface.
 However, as such steps are currently not relevant for any of flowR's core analyses we will not go into detail here. It suffices to know how "real" steps work.
 `
-    })}
+        })}
 	
 ## How flowR Produces Dataflow Graphs
 
 This section focuses on the generation of a [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow-Graph) from a given R program, using the [RShell Engine](${doc_files_1.FlowrWikiBaseRef}/Engines) and hence the 
-${(0, doc_types_1.shortLink)('DEFAULT_DATAFLOW_PIPELINE', info)}. The [\`tree-sitter\` engine](${doc_files_1.FlowrWikiBaseRef}/Engines) uses the ${(0, doc_types_1.shortLink)('TREE_SITTER_DATAFLOW_PIPELINE', info)}), 
+${ctx.link('DEFAULT_DATAFLOW_PIPELINE')}. The [\`tree-sitter\` engine](${doc_files_1.FlowrWikiBaseRef}/Engines) uses the ${ctx.link('TREE_SITTER_DATAFLOW_PIPELINE')}), 
 which replaces the parser with the integrated tree-sitter parser and hence uses a slightly adapted normalization step to produce a similar [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized-AST).
 The [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow-Graph) should be the same for both engines (although [\`tree-sitter\`](${doc_files_1.FlowrWikiBaseRef}/Engines) is faster and may be able to parse more files).
 
@@ -218,73 +218,72 @@ The [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow-Graph) should be t
 
 Let's have a look at the definition of the pipeline:
 
-${(0, doc_types_1.printHierarchy)({ program, info, root: 'DEFAULT_DATAFLOW_PIPELINE', maxDepth: 0 })}
+${ctx.hierarchy('DEFAULT_DATAFLOW_PIPELINE', { maxDepth: 0 })}
 
 We can see that it relies on three steps:
 
-1. **${(0, doc_types_1.shortLink)('PARSE_WITH_R_SHELL_STEP', info, false)}** ([parsing](#parsing)): Uses the ${(0, doc_types_1.shortLink)(shell_1.RShell.name, info)} to parse the input program.\\
-   _Its main function linked as the processor is the ${(0, doc_types_1.shortLink)(parser_1.parseRequests.name, info, false)} function._
-2. **${(0, doc_types_1.shortLink)('NORMALIZE', info, false)}** ([normalization](#normalization)):  Normalizes the AST produced by the parser (to create a [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized-AST)).\\
-   _Its main function linked as the processor is the ${(0, doc_types_1.shortLink)(parser_2.normalize.name, info, false)} function._
-3. **${(0, doc_types_1.shortLink)('STATIC_DATAFLOW', info, false)}** ([dataflow](#dataflow-graph-generation)): Produces the actual [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow-Graph) from the normalized AST.\\
-   _Its main function linked as the processor is the ${(0, doc_types_1.shortLink)(extractor_1.produceDataFlowGraph.name, info, false)} function._
+1. **${ctx.link('PARSE_WITH_R_SHELL_STEP', { codeFont: false })}** ([parsing](#parsing)): Uses the ${ctx.link(shell_1.RShell)} to parse the input program.\\
+   _Its main function linked as the processor is the ${ctx.link(parser_1.parseRequests, { codeFont: false })} function._
+2. **${ctx.link('NORMALIZE', { codeFont: false })}** ([normalization](#normalization)):  Normalizes the AST produced by the parser (to create a [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized-AST)).\\
+   _Its main function linked as the processor is the ${ctx.link(parser_2.normalize, { codeFont: false })} function._
+3. **${ctx.link('STATIC_DATAFLOW', { codeFont: false })}** ([dataflow](#dataflow-graph-generation)): Produces the actual [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow-Graph) from the normalized AST.\\
+   _Its main function linked as the processor is the ${ctx.link(extractor_1.produceDataFlowGraph, { codeFont: false })} function._
 
 To explore these steps, let's use the REPL with the (very simple and contrived) R code: \`${sampleCode}\`.
 
 ${await (0, doc_repl_1.documentReplSession)(shell, [{
-            command: `:parse "${sampleCode}"`,
-            description: `This shows the ASCII-Art representation of the parse-tree of the R code \`${sampleCode}\`, as it is provided by the ${(0, doc_types_1.shortLink)(shell_1.RShell.name, info)}. See the ${(0, doc_types_1.shortLink)(init_1.initCommand.name, info)} function for more information on how we request a parse.`
-        },
-        {
-            command: `:normalize* "${sampleCode}"`,
-            description: `Following the link output should show the following:\n${await (0, doc_normalized_ast_1.printNormalizedAstForCode)(shell, sampleCode, { showCode: false })}`
-        },
-        {
-            command: `:dataflow* "${sampleCode}"`,
-            description: `Following the link output should show the following:\n${await (0, doc_dfg_1.printDfGraphForCode)(shell, sampleCode, { showCode: false })}`
-        }
-    ], { openOutput: false })}
+                command: `:parse "${sampleCode}"`,
+                description: `This shows the ASCII-Art representation of the parse-tree of the R code \`${sampleCode}\`, as it is provided by the ${ctx.link(shell_1.RShell)}. See the ${ctx.link(init_1.initCommand)} function for more information on how we request a parse.`
+            },
+            {
+                command: `:normalize* "${sampleCode}"`,
+                description: `Following the link output should show the following:\n${await (0, doc_normalized_ast_1.printNormalizedAstForCode)(shell, sampleCode, { showCode: false })}`
+            },
+            {
+                command: `:dataflow* "${sampleCode}"`,
+                description: `Following the link output should show the following:\n${await (0, doc_dfg_1.printDfGraphForCode)(shell, sampleCode, { showCode: false })}`
+            }
+        ], { openOutput: false })}
 	
 ${(0, doc_structure_1.block)({
-        type: 'TIP',
-        content: `
+            type: 'TIP',
+            content: `
 	All of these commands accept file paths as well, so you can write longer R code within a file, and then pass 
 	the file path prefixed with \`${retriever_1.fileProtocol}\` (e.g., \`${retriever_1.fileProtocol}test/testfiles/example.R\`) to the commands.`
-    })}
+        })}
 
 Especially when you are just starting with flowR, we recommend using the REPL to explore the output of the different steps.
 
 ${(0, doc_structure_1.block)({
-        type: 'NOTE',
-        content: 'Maybe you are left with the question: What is tree-sitter doing differently? Expand the following to get more information!\n\n' + (0, doc_structure_1.details)('And what changes with tree-sitter?', `
+            type: 'NOTE',
+            content: 'Maybe you are left with the question: What is tree-sitter doing differently? Expand the following to get more information!\n\n' + (0, doc_structure_1.details)('And what changes with tree-sitter?', `
 
 Essentially not much (from a user perspective, it does essentially everything and all differently under the hood)! Have a look at the [Engines](${doc_files_1.FlowrWikiBaseRef}/Engines) wiki page for more information on the differences between the engines.
 Below you can see the Repl commands for the tree-sitter engine (using ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'default-engine')} to set the engine to tree-sitter):
 
 ${await (async () => {
-            const exec = new tree_sitter_executor_1.TreeSitterExecutor();
-            return await (0, doc_repl_1.documentReplSession)(exec, [{
-                    command: `:parse "${sampleCode}"`,
-                    description: `This shows the ASCII-Art representation of the parse-tree of the R code \`${sampleCode}\`, as it is provided by the ${(0, doc_types_1.shortLink)(tree_sitter_executor_1.TreeSitterExecutor.name, info)}. See the [Engines](${doc_files_1.FlowrWikiBaseRef}/Engines) wiki page for more information on the differences between the engines.`
-                },
-                {
-                    command: `:normalize* "${sampleCode}"`,
-                    description: `Following the link output should show the following:\n${await (0, doc_normalized_ast_1.printNormalizedAstForCode)(exec, sampleCode, { showCode: false })}`
-                },
-                {
-                    command: `:dataflow* "${sampleCode}"`,
-                    description: `Following the link output should show the following:\n${await (0, doc_dfg_1.printDfGraphForCode)(exec, sampleCode, { showCode: false })}`
-                }], { openOutput: false, args: '--default-engine tree-sitter' });
-        })()}
+                return await (0, doc_repl_1.documentReplSession)(treeSitter, [{
+                        command: `:parse "${sampleCode}"`,
+                        description: `This shows the ASCII-Art representation of the parse-tree of the R code \`${sampleCode}\`, as it is provided by the ${ctx.link(tree_sitter_executor_1.TreeSitterExecutor)}. See the [Engines](${doc_files_1.FlowrWikiBaseRef}/Engines) wiki page for more information on the differences between the engines.`
+                    },
+                    {
+                        command: `:normalize* "${sampleCode}"`,
+                        description: `Following the link output should show the following:\n${await (0, doc_normalized_ast_1.printNormalizedAstForCode)(treeSitter, sampleCode, { showCode: false })}`
+                    },
+                    {
+                        command: `:dataflow* "${sampleCode}"`,
+                        description: `Following the link output should show the following:\n${await (0, doc_dfg_1.printDfGraphForCode)(treeSitter, sampleCode, { showCode: false })}`
+                    }], { openOutput: false, args: '--default-engine tree-sitter' });
+            })()}
 `)
-    })}
+        })}
 
 ### Parsing
 
-The parsing step uses the ${(0, doc_types_1.shortLink)(shell_1.RShell.name, info)} to parse the input program (or, of course, the ${(0, doc_types_1.shortLink)(tree_sitter_executor_1.TreeSitterExecutor.name, info)} when using the [\`tree-sitter\` engine](${doc_files_1.FlowrWikiBaseRef}/Engines)).
-To speed up the process, we use the ${(0, doc_types_1.shortLink)(init_1.initCommand.name, info)} function to compile the parsing function and rely on a 
+The parsing step uses the ${ctx.link(shell_1.RShell)} to parse the input program (or, of course, the ${ctx.link(tree_sitter_executor_1.TreeSitterExecutor)} when using the [\`tree-sitter\` engine](${doc_files_1.FlowrWikiBaseRef}/Engines)).
+To speed up the process, we use the ${ctx.link(init_1.initCommand)} function to compile the parsing function and rely on a 
 custom serialization, which outputs the information in a CSV-like format.
-This means, that the ${(0, doc_cli_option_1.getReplCommand)('parse')} command actually kind-of lies to you, as it does pretty print the serialized version which looks more like the following (this uses the ${(0, doc_types_1.shortLink)(retriever_1.retrieveParseDataFromRCode.name, info)} function with the sample code \`${sampleCode}\`):
+This means, that the ${(0, doc_cli_option_1.getReplCommand)('parse')} command actually kind-of lies to you, as it does pretty print the serialized version which looks more like the following (this uses the ${ctx.link(retriever_1.retrieveParseDataFromRCode.name)} function with the sample code \`${sampleCode}\`):
 
 ${(0, doc_structure_1.details)(`Raw parse output for <code>${sampleCode}</code>`, `For the code \`${sampleCode}\`:\n\n` + (0, doc_code_1.codeBlock)('csv', await (0, retriever_1.retrieveParseDataFromRCode)((0, retriever_1.requestFromInput)(sampleCode), shell)))}
 
@@ -304,108 +303,108 @@ ${await (0, retriever_1.retrieveParseDataFromRCode)((0, retriever_1.requestFromI
 In fact, this data is merely what R's [\`base::parse\`](https://stat.ethz.ch/R-manual/R-devel/library/base/html/parse.html) and [\`utils::getParseData\`](https://stat.ethz.ch/R-manual/R-devel/library/utils/html/getParseData.html) functions provide.
 We then use this data in the [normalization](#normalization) step to create a [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized-AST).
 
-If you are interested in the raw token types that we may encounter, have a look at the ${(0, doc_types_1.shortLink)('RawRType', info)} enum.
+If you are interested in the raw token types that we may encounter, have a look at the ${ctx.link('RawRType')} enum.
 
 ### Normalization
 
-The normalization function ${(0, doc_types_1.shortLink)(parser_2.normalize.name, info)} takes the output from the previous steps and uses the ${(0, doc_types_1.shortLink)(format_1.prepareParsedData.name, info)} and 
-${(0, doc_types_1.shortLink)(format_1.convertPreparedParsedData.name, info)} functions to first transform the serialized parsing output to an object. 
-Next, ${(0, doc_types_1.shortLink)(normalize_root_1.normalizeRootObjToAst.name, info)} transforms this object to a normalized AST and ${(0, doc_types_1.shortLink)(decorate_1.decorateAst.name, info)} adds additional information to the AST (like roles, ids, depth, etc.).
-While looking at the mermaid visualization of such an AST is nice and usually sufficient, looking at the objects themselves shows you the full range of information the AST provides (all encompassed within the ${(0, doc_types_1.shortLink)('RNode', info)} type).
+The normalization function ${ctx.link(parser_2.normalize)} takes the output from the previous steps and uses the ${ctx.link(format_1.prepareParsedData)} and 
+${ctx.link(format_1.convertPreparedParsedData)} functions to first transform the serialized parsing output to an object. 
+Next, ${ctx.link(normalize_root_1.normalizeRootObjToAst)} transforms this object to a normalized AST and ${ctx.link(decorate_1.decorateAst)} adds additional information to the AST (like roles, ids, depth, etc.).
+While looking at the mermaid visualization of such an AST is nice and usually sufficient, looking at the objects themselves shows you the full range of information the AST provides (all encompassed within the ${ctx.link('RNode')} type).
 
 Let's have a look at the normalized AST for the sample code \`${sampleCode}\` (please refer to the [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized-AST) wiki page for more information):
 
-${(0, doc_structure_1.details)('Normalized AST for <code>x <- 1; print(x)</code>', (0, doc_code_1.codeBlock)('json', JSON.stringify((await (0, default_pipelines_1.createNormalizePipeline)(shell, { request: (0, retriever_1.requestFromInput)(sampleCode) }, config_1.defaultConfigOptions).allRemainingSteps()).normalize.ast, json_1.jsonReplacer, 4)))}
+${(0, doc_structure_1.details)('Normalized AST for <code>x <- 1; print(x)</code>', (0, doc_code_1.codeBlock)('json', JSON.stringify((await (0, default_pipelines_1.createNormalizePipeline)(shell, { context: (0, flowr_analyzer_context_1.contextFromInput)(sampleCode) }).allRemainingSteps()).normalize.ast, json_1.jsonReplacer, 4)))}
 
-This is… a lot! We get the type from the ${(0, doc_types_1.shortLink)('RType', info)} enum, the lexeme, location information, an id, the children of the node, and their parents.
+This is… a lot! We get the type from the ${ctx.link('RType')} enum, the lexeme, location information, an id, the children of the node, and their parents.
 While the [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized-AST) wiki page provides you with information on how to interpret this data, we will focus on how we get it from the
 table provided by the [parsing](#parsing) step.
 
-There are two important functions: ${(0, doc_types_1.shortLink)(normalize_root_1.normalizeRootObjToAst.name, info)}, which operates on the parse-output already transformed into a tree-like structure,
-and ${(0, doc_types_1.shortLink)(decorate_1.decorateAst.name, info)}, which adds additional information to the AST.
+There are two important functions: ${ctx.link(normalize_root_1.normalizeRootObjToAst)}, which operates on the parse-output already transformed into a tree-like structure,
+and ${ctx.link(decorate_1.decorateAst)}, which adds additional information to the AST.
 Both follow a [fold](https://en.wikipedia.org/wiki/Fold_(higher-order_function)) pattern.
-The fold is explicit for ${(0, doc_types_1.shortLink)(decorate_1.decorateAst.name, info)}, which directly relies on the ${(0, doc_types_1.shortLink)(stateful_fold_1.foldAstStateful.name, info)} function,
-while ${(0, doc_types_1.shortLink)(normalize_root_1.normalizeRootObjToAst.name, info)} uses the fold-idiom but deviates in cases in which (for example) we require more information on other nodes to know what it should be normalized too.
+The fold is explicit for ${ctx.link(decorate_1.decorateAst)}, which directly relies on the ${ctx.link(stateful_fold_1.foldAstStateful)} function,
+while ${ctx.link(normalize_root_1.normalizeRootObjToAst)} uses the fold-idiom but deviates in cases in which (for example) we require more information on other nodes to know what it should be normalized too.
 
 #### Normalizing the Object
 
-We have a handler for everything. For example ${(0, doc_types_1.shortLink)(normalize_if_then_1.tryNormalizeIfThen.name, info)} or ${(0, doc_types_1.shortLink)(normalize_for_1.tryNormalizeFor.name, info)} to handle \`if(x) y\` or \`for(i in 1:10) x\` constructs.
-All of these handlers contain many sanity checks to be sure that we talk to an ${(0, doc_types_1.shortLink)('RShell', info)} which we can handle (as assumptions may break with newer versions).
+We have a handler for everything. For example ${ctx.link(normalize_if_then_1.tryNormalizeIfThen)} or ${ctx.link(normalize_for_1.tryNormalizeFor)} to handle \`if(x) y\` or \`for(i in 1:10) x\` constructs.
+All of these handlers contain many sanity checks to be sure that we talk to an ${ctx.link(shell_1.RShell)} which we can handle (as assumptions may break with newer versions).
 These functions contain the keyword \`try\` as they may fail. For example, whenever they notice late into normalization that they should actually be a different construct (R is great).
-For single nodes, we use ${(0, doc_types_1.shortLink)(normalize_single_node_1.normalizeSingleNode.name, info)} which contains a catch-all for some edge-cases in the R grammar.
+For single nodes, we use ${ctx.link(normalize_single_node_1.normalizeSingleNode)} which contains a catch-all for some edge-cases in the R grammar.
 
-The output of just this pass is listed below (using the ${(0, doc_types_1.shortLink)(parser_2.normalizeButNotDecorated.name, info)} function):
+The output of just this pass is listed below (using the ${ctx.link(parser_2.normalizeButNotDecorated)} function):
 
-${(0, doc_structure_1.details)('Ast for <code>x <- 1; print(x)</code> after the first normalization', (0, doc_code_1.codeBlock)('json', JSON.stringify((0, parser_2.normalizeButNotDecorated)((await (0, default_pipelines_1.createParsePipeline)(shell, { request: (0, retriever_1.requestFromInput)(sampleCode) }, config_1.defaultConfigOptions).allRemainingSteps()).parse), json_1.jsonReplacer, 4)))}
+${(0, doc_structure_1.details)('Ast for <code>x <- 1; print(x)</code> after the first normalization', (0, doc_code_1.codeBlock)('json', JSON.stringify((0, parser_2.normalizeButNotDecorated)((await (0, default_pipelines_1.createParsePipeline)(shell, { context: (0, flowr_analyzer_context_1.contextFromInput)(sampleCode) }).allRemainingSteps()).parse.files[0]), json_1.jsonReplacer, 4)))}
 
 
 #### Decorating the AST
 
-The decoration is comparatively trivial. We take the AST throw it into the ${(0, doc_types_1.shortLink)(decorate_1.decorateAst.name, info)} function (which again, handles each normalized node type) and
+The decoration is comparatively trivial. We take the AST throw it into the ${ctx.link(decorate_1.decorateAst.name)} function (which again, handles each normalized node type) and
 get:
 
 1. The AST with ids, roles, and depth information (see the [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized-AST) wiki page for more information).
-2. A mapping of ids to nodes in the form of a ${(0, doc_types_1.shortLink)('AstIdMap', info)} object. This allows us to quickly access nodes by their id.
+2. A mapping of ids to nodes in the form of a ${ctx.link('AstIdMap')} object. This allows us to quickly access nodes by their id.
 
-The ids used for the AST generation are arbitrary (usually created by the ${(0, doc_types_1.shortLink)(decorate_1.deterministicCountingIdGenerator.name, info)}) function) but unique and intentionally
+The ids used for the AST generation are arbitrary (usually created by the ${ctx.link(decorate_1.deterministicCountingIdGenerator.name)}) function) but unique and intentionally
 separated from the ids used by the R&nbsp;parser. For one, this detaches us from the [Engine](${doc_files_1.FlowrWikiBaseRef}/Engines) used, and secondly, it allows for much easier
 extension of the AST (e.g., when R&nbsp;files use [\`base::source\`](https://stat.ethz.ch/R-manual/R-devel/library/base/html/source.html) to include other R&nbsp;files).
-All ids conform to the ${(0, doc_types_1.shortLink)('NodeId', info)} type.
+All ids conform to the ${ctx.link('NodeId')} type.
 
 ### Dataflow Graph Generation
 
 The core of the dataflow graph generation works as a "stateful [fold](https://en.wikipedia.org/wiki/Fold_(higher-order_function))", 
 which uses the tree-like structure of the AST to combine the dataflow information of the children, while tracking the currently active variables and control flow 
 information as a “backpack” (state).
-We use the ${(0, doc_types_1.shortLink)(extractor_1.produceDataFlowGraph.name, info)} function as an entry point to the dataflow generation (the actual fold entry is in ${(0, doc_types_1.shortLink)(processor_1.processDataflowFor.name, info)}).
-The function is mainly backed by its ${(0, doc_types_1.shortLink)('processors', info)} object which maps each type in the normalized AST to an appropriate handler ("fold-function").
+We use the ${ctx.link(extractor_1.produceDataFlowGraph)} function as an entry point to the dataflow generation (the actual fold entry is in ${ctx.link(processor_1.processDataflowFor)}).
+The function is mainly backed by its ${ctx.link('processors')} object which maps each type in the normalized AST to an appropriate handler ("fold-function").
 
-To understand these handlers, let's start with the simplest one, ${(0, doc_types_1.shortLink)(process_uninteresting_leaf_1.processUninterestingLeaf.name, info)} signals that 
-we do not care about this node and just produce an empty dataflow information (using ${(0, doc_types_1.shortLink)(info_1.initializeCleanDataflowInformation.name, info)}). 
+To understand these handlers, let's start with the simplest one, ${ctx.link(process_uninteresting_leaf_1.processUninterestingLeaf)} signals that 
+we do not care about this node and just produce an empty dataflow information (using ${ctx.link(info_1.initializeCleanDataflowInformation)}). 
 Looking at the function showcases the general structure of a processor:
 
-${(0, doc_types_1.printHierarchy)({ program, info, root: 'processUninterestingLeaf', maxDepth: 2, openTop: true })}
+${ctx.hierarchy(process_uninteresting_leaf_1.processUninterestingLeaf, { maxDepth: 2, openTop: true })}
 
 Every processor has the same shape. It takes the normalized node (see the [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized-AST) for more information),
-and a ${(0, doc_types_1.shortLink)('DataflowProcessorInformation', info)} object which, as some kind of "backpack" carries global information
+and a ${ctx.link('DataflowProcessorInformation')} object which, as some kind of "backpack" carries global information
 to every handler. 
-This information is to be used to create a ${(0, doc_types_1.shortLink)('DataflowInformation', info)}:
+This information is to be used to create a ${ctx.link('DataflowInformation')}:
 
-${(0, doc_types_1.printHierarchy)({ program, info, root: 'DataflowInformation', maxDepth: 2 })}
+${ctx.hierarchy('DataflowInformation', { maxDepth: 2 })}
 
 Essentially, these processors should use the dataflow information from their children combined with their own semantics
-to produce a new dataflow information to pass upwards in the fold. The ${(0, doc_types_1.shortLink)('DataflowInformation', info)} contains:
+to produce a new dataflow information to pass upwards in the fold. The ${ctx.link('DataflowInformation')} contains:
 
-* the ${(0, doc_types_1.shortLink)('DataflowGraph', info)} of the current subtree 
-* the currently active ${(0, doc_types_1.shortLink)('REnvironmentInformation', info)} as an abstraction of all active definitions linking to potential definition locations (see [Advanced R::Environments](https://adv-r.hadley.nz/environments.html))
-* control flow information in ${(0, doc_types_1.shortLink)('DataflowCfgInformation', info)} which is used to enrich the dataflow information with control flow information
-* and sets of currently ingoing (read), outgoing (write) and unknown ${(0, doc_types_1.shortLink)('IdentifierReference', info)}s.
+* the ${ctx.link(graph_1.DataflowGraph)} of the current subtree 
+* the currently active ${ctx.link('REnvironmentInformation')} as an abstraction of all active definitions linking to potential definition locations (see [Advanced R::Environments](https://adv-r.hadley.nz/environments.html))
+* control flow information in ${ctx.link('DataflowCfgInformation')} which is used to enrich the dataflow information with control flow information
+* and sets of currently ingoing (read), outgoing (write) and unknown ${ctx.link('IdentifierReference')}s.
 
-While all of them are essentially empty when processing an “uninteresting leaf”, handling a constant is slightly more interesting with ${(0, doc_types_1.shortLink)('processValue', info)}:
+While all of them are essentially empty when processing an “uninteresting leaf”, handling a constant is slightly more interesting with ${ctx.link(process_value_1.processValue)}:
 
-${(0, doc_types_1.printHierarchy)({ program, info, root: 'processValue', maxDepth: 2, openTop: true })}
+${ctx.hierarchy(process_value_1.processValue, { maxDepth: 2, openTop: true })}
 
 Please note, that we add the [value vertex](${doc_files_1.FlowrWikiBaseRef}/Dataflow-Graph#value-vertex) to the newly created dataflow graph,
-which holds a reference to the constant. If you are confused with the use of the ${(0, doc_types_1.shortLink)('ParentInformation', info)} type, 
-this stems from the [AST decoration](#normalization) and signals that we have a decorated ${(0, doc_types_1.shortLink)('RNode', info)} (which may have additional information in \`OtherInfo\`).
+which holds a reference to the constant. If you are confused with the use of the ${ctx.link('ParentInformation')} type, 
+this stems from the [AST decoration](#normalization) and signals that we have a decorated ${ctx.link('RNode')} (which may have additional information in \`OtherInfo\`).
 
-Yet again, this is not very interesting. When looking at the ${(0, doc_types_1.shortLink)('processors', info)} object you may be confused by
-many lines just mapping the node to the ${(0, doc_types_1.shortLink)('processAsNamedCall', info)} function.
+Yet again, this is not very interesting. When looking at the ${ctx.link('processors')} object you may be confused by
+many lines just mapping the node to the ${ctx.link(process_named_call_1.processAsNamedCall)} function.
 This is because during the dataflow analysis we actually "desugar" the AST, and treat syntax constructs like binary operators (e.g., \`x + y\`) as function calls (e.g. \`\` \`+\`(x, y) \`\`).
 We do this, because R does it the same way, and allows to even overwrite these operators (including \`if\`, \`<-\`, etc.) by their name.
 By treating them like R, as function calls, we get support for these overwrites for free, courtesy of flowR's call resolution.
 
 But where are all the interesting things handled then? 
 For that, we want to have a look at the built-in environment, which can be freely configured using flowR's [configuration system](${doc_files_1.FlowrWikiBaseRef}/Interface#configuring-flowr).
-FlowR's heart and soul resides in the ${(0, doc_types_1.shortLink)('DefaultBuiltinConfig', info)} object, which is used to configure the built-in environment
-by mapping function names to ${(0, doc_types_1.shortLink)('BuiltInProcessorMapper', info)} functions.
-There you can find functions like ${(0, doc_types_1.shortLink)(built_in_access_1.processAccess.name, info)} which handles the (subset) access to a variable, 
-or ${(0, doc_types_1.shortLink)(built_in_for_loop_1.processForLoop.name, info)} which handles the primitive for loop construct (whenever it is not overwritten).
+FlowR's heart and soul resides in the ${ctx.link('DefaultBuiltinConfig')} object, which is used to configure the built-in environment
+by mapping function names to ${ctx.link('BuiltInProcessorMapper')} functions.
+There you can find functions like ${ctx.link(built_in_access_1.processAccess)} which handles the (subset) access to a variable, 
+or ${ctx.link(built_in_for_loop_1.processForLoop)} which handles the primitive for loop construct (whenever it is not overwritten).
 
-Just as an example, we want to have a look at the ${(0, doc_types_1.shortLink)(built_in_repeat_loop_1.processRepeatLoop.name, info)} function, as it is one of the simplest built-in processors
+Just as an example, we want to have a look at the ${ctx.link(built_in_repeat_loop_1.processRepeatLoop)} function, as it is one of the simplest built-in processors
 we have:
 
-${(0, doc_types_1.printHierarchy)({ program, info, root: 'processRepeatLoop', maxDepth: 2, openTop: true })}
+${ctx.hierarchy(built_in_repeat_loop_1.processRepeatLoop, { maxDepth: 2, openTop: true })}
 
 Similar to any other built-in processor, we get the name of the function call which caused us to land here,
 as well as the passed arguments. The \`rootId\` refers to what caused the call to happen (and is usually just the function call),
@@ -418,7 +417,7 @@ For just the repeat loop the stitching is actually not necessary, but this way t
 
 Afterward, we take the \`processedArguments\`, perform another round of sanity checks and then use two special functions to apply the
 semantic effects of the repeat loop. We first use one of flowR's linkers to
-${(0, doc_types_1.shortLink)(linker_1.linkCircularRedefinitionsWithinALoop.name, info)} and then retrieve the active exit points with ${(0, doc_types_1.shortLink)(info_1.filterOutLoopExitPoints.name, info)}.
+${ctx.link(linker_1.linkCircularRedefinitionsWithinALoop.name)} and then retrieve the active exit points with ${ctx.link(info_1.filterOutLoopExitPoints.name)}.
 
 Feel free to have a look around and explore the other handlers for now. Each of them uses the results of its children alongside the active backpack 
 to produce a new dataflow information.
@@ -427,48 +426,38 @@ to produce a new dataflow information.
 
 Given the [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow-Graph), you can do a lot more!
 You can issue [queries](${doc_files_1.FlowrWikiBaseRef}/Query-API) to explore the graph, [search](${doc_files_1.FlowrWikiBaseRef}/Search-API) for specific elements, or, for example, request a [static backward slice](#static-backward-slicing).
-Of course, all of these endeavors work not just with the ${(0, doc_types_1.shortLink)(shell_1.RShell.name, info)} but also with the [\`tree-sitter\` engine](${doc_files_1.FlowrWikiBaseRef}/Engines). 
+Of course, all of these endeavors work not just with the ${ctx.link(shell_1.RShell.name)} but also with the [\`tree-sitter\` engine](${doc_files_1.FlowrWikiBaseRef}/Engines). 
 
 ### Static Backward Slicing
 
-The slicing is available as an extra step as you can see by inspecting he ${(0, doc_types_1.shortLink)('DEFAULT_SLICING_PIPELINE', info)}.
-Besides ${(0, doc_types_1.shortLink)('STATIC_SLICE', info)} it contains a ${(0, doc_types_1.shortLink)('NAIVE_RECONSTRUCT', info)} to print the slice as (executable) R code.
+The slicing is available as an extra step as you can see by inspecting he ${ctx.link('DEFAULT_SLICING_PIPELINE')}.
+Besides ${ctx.link('STATIC_SLICE')} it contains a ${ctx.link('NAIVE_RECONSTRUCT')} to print the slice as (executable) R code.
 
-Your main point of interesting here is the ${(0, doc_types_1.shortLink)(static_slicer_1.staticSlice.name, info)} function which relies on a modified
+Your main point of interesting here is the ${ctx.link(static_slicer_1.staticSlice.name)} function which relies on a modified
 breadth-first search to collect all nodes which are part of the slice. 
 For more information on how the slicing works, please refer to the [tool demonstration (Section 3.2)](https://doi.org/10.1145/3691620.3695359),
 or the [original master's thesis (Chapter 4)](https://doi.org/10.18725/OPARU-50107).
 
 You can explore the slicing using the REPL with the ${(0, doc_cli_option_1.getReplCommand)('slicer')} command:
 
-${await (0, doc_repl_1.documentReplSession)(shell, [{
-            command: ':slicer test/testfiles/example.R --criterion "12@product"',
-            description: 'Slice for the example file for the variable "prod" in line 12.'
-        }], { openOutput: true })}
+${await (0, doc_repl_1.documentReplSession)(treeSitter, [{
+                command: ':query @static-slice (12@product) file://test/testfiles/example.R',
+                description: 'Slice for the example file for the variable "prod" in line 12.'
+            }], { openOutput: true })}
 
 ## Helpful Things
 
 ### Getting flowR to Talk
 
 When using flowR from the CLI, you can use the ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'verbose')} option to get more information about what flowR is doing.
-While coding, however, you can use the ${(0, doc_types_1.shortLink)(log_1.setMinLevelOfAllLogs.name, testInfo)} function to set the minimum level of logs to be displayed (this works with the ${(0, doc_types_1.shortLink)(log_2.FlowrLogger.name, info)} abstraction).
-In general, you can configure the levels of individual logs, such as the general \`log\` (obtained with ${(0, doc_types_1.shortLink)('getActiveLog', info)}) or the ${(0, doc_types_1.shortLink)('parseLog', info)}.
+While coding, however, you can use the ${ctx.link(log_1.setMinLevelOfAllLogs)} function to set the minimum level of logs to be displayed (this works with the ${ctx.link(log_2.FlowrLogger)} abstraction).
+In general, you can configure the levels of individual logs, such as the general \`log\` (obtained with ${ctx.link('getActiveLog')}) or the ${ctx.link('parseLog')}.
 Please note that flowR makes no guarantees that log outputs are persistent across versions, and it is up to the implementors to provide sensible logging.
 If you are an implementor and want to add logging, please make sure there are no larger runtime impliciations when logging is disabled. 
-Have a look at the ${(0, doc_types_1.shortLink)(log_2.expensiveTrace.name, info)} function for example, which uses a function to generate the log message only when the log level is reached.
+Have a look at the ${ctx.link(log_2.expensiveTrace)} function for example, which uses a function to generate the log message only when the log level is reached.
 
 `;
+    }
 }
-/** if we run this script, we want a Markdown representation of the capabilities */
-if (require.main === module) {
-    void tree_sitter_executor_1.TreeSitterExecutor.initTreeSitter().then(() => {
-        (0, log_1.setMinLevelOfAllLogs)(6 /* LogLevel.Fatal */);
-        const shell = new shell_1.RShell();
-        void getText(shell).then(str => {
-            console.log(str);
-        }).finally(() => {
-            shell.close();
-        });
-    });
-}
-//# sourceMappingURL=print-core-wiki.js.map
+exports.WikiCore = WikiCore;
+//# sourceMappingURL=wiki-core.js.map