@eagleoutice/flowr 2.6.1 → 2.6.3

package/documentation/{print-dataflow-graph-wiki.js → wiki-dataflow-graph.js}

@@ -3,15 +3,14 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
     return (mod && mod.__esModule) ? mod : { "default": mod };
 };
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.WikiDataflowGraph = void 0;
 const graph_1 = require("../dataflow/graph/graph");
-const shell_1 = require("../r-bridge/shell");
 const vertex_1 = require("../dataflow/graph/vertex");
 const edge_1 = require("../dataflow/graph/edge");
 const dataflowgraph_builder_1 = require("../dataflow/graph/dataflowgraph-builder");
 const assert_1 = require("../util/assert");
 const doc_dfg_1 = require("./doc-util/doc-dfg");
 const doc_files_1 = require("./doc-util/doc-files");
-const retriever_1 = require("../r-bridge/retriever");
 const json_1 = require("../util/json");
 const doc_env_1 = require("./doc-util/doc-env");
 const doc_data_dfg_util_1 = require("./data/dfg/doc-data-dfg-util");
@@ -26,9 +25,7 @@ const identifier_1 = require("../dataflow/environments/identifier");
 const r_function_call_1 = require("../r-bridge/lang-4.x/ast/model/nodes/r-function-call");
 const resolve_by_name_1 = require("../dataflow/environments/resolve-by-name");
 const default_pipelines_1 = require("../core/steps/pipeline/default-pipelines");
-const doc_auto_gen_1 = require("./doc-util/doc-auto-gen");
 const text_1 = require("../util/text/text");
-const log_1 = require("../../test/functionality/_helper/log");
 const linker_1 = require("../dataflow/internal/linker");
 const doc_normalized_ast_1 = require("./doc-util/doc-normalized-ast");
 const dfg_get_origin_1 = require("../dataflow/origin/dfg-get-origin");
@@ -37,10 +34,11 @@ const alias_tracking_1 = require("../dataflow/eval/resolve/alias-tracking");
 const doc_issue_1 = require("./doc-util/doc-issue");
 const unnamed_call_handling_1 = require("../dataflow/internal/process/functions/call/unnamed-call-handling");
 const environment_builder_1 = require("../../test/functionality/_helper/dataflow/environment-builder");
-const config_1 = require("../config");
 const flowr_analyzer_builder_1 = require("../project/flowr-analyzer-builder");
-async function subExplanation(shell, { description, code, expectedSubgraph }) {
-    expectedSubgraph = await (0, doc_dfg_1.verifyExpectedSubgraph)(shell, code, expectedSubgraph);
+const flowr_analyzer_context_1 = require("../project/context/flowr-analyzer-context");
+const doc_maker_1 = require("./wiki-mk/doc-maker");
+async function subExplanation(parser, { description, code, expectedSubgraph }) {
+    expectedSubgraph = await (0, doc_dfg_1.verifyExpectedSubgraph)(parser, code, expectedSubgraph);
     const marks = [];
     for (const [id] of expectedSubgraph.vertices(true)) {
         marks.push(id);
@@ -51,11 +49,11 @@ async function subExplanation(shell, { description, code, expectedSubgraph }) {
         }
     }
     return `
-${await (0, doc_dfg_1.printDfGraphForCode)(shell, code, { mark: new Set(marks) })}
+${await (0, doc_dfg_1.printDfGraphForCode)(parser, code, { mark: new Set(marks) })}
 
 ${description}`;
 }
-async function printAllSubExplanations(shell, expls) {
+async function printAllSubExplanations(parser, expls) {
     let result = `
 <details>
 
@@ -64,21 +62,21 @@ async function printAllSubExplanations(shell, expls) {
 `;
     for (const sub of expls) {
         result += `#### ${sub.name}\n`;
-        result += await subExplanation(shell, sub) + '\n';
+        result += await subExplanation(parser, sub) + '\n';
     }
     return result + '\n\n</details>';
 }
-async function explanation({ shell, name, type, description, code, expectedSubgraph }, index, ...subExplanations) {
-    await (0, doc_dfg_1.verifyExpectedSubgraph)(shell, code, expectedSubgraph);
+async function explanation({ name, type, description, code, expectedSubgraph }, parser, index, ...subExplanations) {
+    await (0, doc_dfg_1.verifyExpectedSubgraph)(parser, code, expectedSubgraph);
     return `
 <a id='${name.toLowerCase().replaceAll(' ', '-')}'> </a>
 ### ${index}) ${name}
 
 Type: \`${type}\` (this is the bit-flag value, e.g., when looking at the serialization)
 
-${await subExplanation(shell, { name, description, code, expectedSubgraph })}
+${await subExplanation(parser, { name, description, code, expectedSubgraph })}
 
-${subExplanations.length > 0 ? await printAllSubExplanations(shell, subExplanations) : ''}
+${subExplanations.length > 0 ? await printAllSubExplanations(parser, subExplanations) : ''}
 	`;
 }
 function edgeTypeToId(edgeType) {
@@ -87,18 +85,17 @@ function edgeTypeToId(edgeType) {
 function linkEdgeName(edgeType, page = '') {
     return `[\`${(0, edge_1.edgeTypeToName)(edgeType)}\`](${page}#${edgeTypeToId(edgeType)})`;
 }
-async function getVertexExplanations(shell, vertexType) {
+async function getVertexExplanations(parser, ctx) {
     /* we use the map to ensure order easily :D */
     const vertexExplanations = new Map();
     vertexExplanations.set(vertex_1.VertexType.Value, [{
-            shell,
             name: 'Value Vertex',
             type: vertex_1.VertexType.Value,
             description: `
 Describes a constant value (numbers, booleans/logicals, strings, ...).
 In general, the respective vertex is more or less a dummy vertex as you can see from its implementation.
 
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowGraphVertexValue' })}
+${ctx.hierarchy('DataflowGraphVertexValue')}
 
 ${(0, doc_structure_1.block)({
                 type: 'NOTE',
@@ -112,14 +109,13 @@ and ask for the value associated with it.
 Please be aware that such nodes may be the result from language semantics as well, and not just from constants directly in the source.
 For example, an access operation like \`df$column\` will treat the column name as a constant value.
 
-${(0, doc_structure_1.details)('Example: Semantics Create a Value', `In the following graph, the original type printed by mermaid is still \`RSymbol\` (from the [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized%20AST)), however, the shape of the vertex signals to you that the symbol is in-fact treated as a constant! If you do not know what \`df$column\` even means, please refer to the [R topic](https://rdrr.io/r/base/Extract.html).\n` +
-                await (0, doc_dfg_1.printDfGraphForCode)(shell, 'df$column', { mark: new Set([1]) }))}
+${(0, doc_structure_1.details)('Example: Semantics Create a Value', `In the following graph, the original type printed by mermaid is still \`RSymbol\` (from the [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized-AST)), however, the shape of the vertex signals to you that the symbol is in-fact treated as a constant! If you do not know what \`df$column\` even means, please refer to the [R topic](https://rdrr.io/r/base/Extract.html).\n` +
+                await (0, doc_dfg_1.printDfGraphForCode)(parser, 'df$column', { mark: new Set([1]) }))}
 		`,
             code: '42',
             expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().constant('0')
         }, []]);
     vertexExplanations.set(vertex_1.VertexType.Use, [{
-            shell,
             name: 'Use Vertex',
             type: vertex_1.VertexType.Use,
             description: `
@@ -128,7 +124,7 @@ Describes symbol/variable references which are read (or potentially read at a gi
 Similar to the [value vertex](#value-vertex) described above, this is more a marker vertex as 
 you can see from the implementation.
 
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowGraphVertexUse' })}
+${ctx.hierarchy('DataflowGraphVertexUse')}
 
 ${(0, doc_structure_1.block)({
                 type: 'NOTE',
@@ -148,26 +144,26 @@ Consider a case, in which we refer to a variable with a string, as in \`get("x")
 ${(0, doc_structure_1.details)('Example: Semantics Create a Symbol', `In the following graph, the original type printed by mermaid is still \`RString\` (from the [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized%20AST)), however, the shape of the vertex signals to you that the symbol is in-fact treated as a variable use! ` +
                 'If you are unsure what `get` does, refer to the [documentation](https://www.rdocumentation.org/packages/base/versions/3.6.2/topics/get). ' +
                 'Please note, that the lexeme being printed as `"x"` may be misleading (after all it is recovered from the AST), the quotes are not part of the reference.\n' +
-                await (0, doc_dfg_1.printDfGraphForCode)(shell, 'get("x")', { mark: new Set([1]) }))}
+                await (0, doc_dfg_1.printDfGraphForCode)(parser, 'get("x")', { mark: new Set([1]) }))}
 
 But now to the interesting stuff: how do we actually know which values are read by the respective variable use?
 This usually involves a [variable definition](#variable-definition-vertex) and a [reads edge](#reads-edge) linking the two.
 
 ${(0, doc_structure_1.details)('Example: Reads Edge Identifying a Single Definition', 'In the following graph, the `x` is read from the definition `x <- 1`.\n' +
-                await (0, doc_dfg_1.printDfGraphForCode)(shell, 'x <- 1\nprint(x)', { mark: new Set([3, '0->3']), codeOpen: true }))}
+                await (0, doc_dfg_1.printDfGraphForCode)(parser, 'x <- 1\nprint(x)', { mark: new Set([3, '0->3']), codeOpen: true }))}
 
 In general, there may be many such edges, identifying every possible definition of the variable.
 
-${(0, doc_structure_1.details)('Example: Reads Edge Identifying Multiple Definitions (conditional)', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'x <- 1\nif(u) x <- 2\nprint(x)', { mark: new Set([10, '10->0', '10->4']), codeOpen: true }))}
-${(0, doc_structure_1.details)('Example: Reads Edge Identifying Multiple Definitions (loop)', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'x <- 1\nfor(i in v) x <- 2\nprint(x)', { mark: new Set([11, '11->0', '11->5']), codeOpen: true }))}
-${(0, doc_structure_1.details)('Example: Reads Edge Identifying Multiple Definitions (side-effect)', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'f <- function() x <<- 2\nx <- 2\nif(u) f()\nprint(x)', { mark: new Set([16, '16->1', '16->7']), codeOpen: true }))}
+${(0, doc_structure_1.details)('Example: Reads Edge Identifying Multiple Definitions (conditional)', await (0, doc_dfg_1.printDfGraphForCode)(parser, 'x <- 1\nif(u) x <- 2\nprint(x)', { mark: new Set([10, '10->0', '10->4']), codeOpen: true }))}
+${(0, doc_structure_1.details)('Example: Reads Edge Identifying Multiple Definitions (loop)', await (0, doc_dfg_1.printDfGraphForCode)(parser, 'x <- 1\nfor(i in v) x <- 2\nprint(x)', { mark: new Set([11, '11->0', '11->5']), codeOpen: true }))}
+${(0, doc_structure_1.details)('Example: Reads Edge Identifying Multiple Definitions (side-effect)', await (0, doc_dfg_1.printDfGraphForCode)(parser, 'f <- function() x <<- 2\nx <- 2\nif(u) f()\nprint(x)', { mark: new Set([16, '16->1', '16->7']), codeOpen: true }))}
 
 ${(0, doc_structure_1.block)({
                 type: 'IMPORTANT',
                 content: `
 	If you want to obtain the locations where a variable is defined, or read, or re-defined, refrain from tracking these details manually in the dataflow graph
 	as there are some edge-cases that require special attention.
-	In general, the ${(0, doc_types_1.shortLink)(dfg_get_origin_1.getOriginInDfg.name, vertexType.info)} function explained below in [working with the dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Working%20with%20the%20Dataflow%20Graph) will help you to get the information you need.
+	In general, the ${ctx.link(dfg_get_origin_1.getOriginInDfg)} function explained below in [working with the dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow%20Graph#working-with-the-dataflow-graph) will help you to get the information you need.
 	`
             })}
 
@@ -176,7 +172,6 @@ ${(0, doc_structure_1.block)({
             expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().use('1@x', 'x')
         }, []]);
     vertexExplanations.set(vertex_1.VertexType.FunctionCall, [{
-            shell,
             name: 'Function Call Vertex',
             type: vertex_1.VertexType.FunctionCall,
             description: `
@@ -187,20 +182,19 @@ the _name_ of the called function, the passed _arguments_, and the _environment_
 However, the implementation reveals that it may hold an additional \`onlyBuiltin\` flag to indicate that the call is only calling builtin functions &mdash; however, this is only a flag to improve performance,
 and it should not be relied on as it may under-approximate the actual calling targets (e.g., being \`false\` even though all calls resolve to builtins).
 	 
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowGraphVertexFunctionCall' })}
+${ctx.hierarchy('DataflowGraphVertexFunctionCall')}
+
 The related function argument references are defined like this:
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'FunctionArgument' })}
+${ctx.hierarchy('FunctionArgument')}
 
 There is another element of potential interest to you, the \`origin\` property which records how flowR created the respective function call.
-These origins may hold the name of any processor that is part of the ${(0, doc_types_1.shortLink)('BuiltInProcessorMapper', vertexType.info)} to signal that the respective processor was responsible for creating the vertex.
+These origins may hold the name of any processor that is part of the ${ctx.link('BuiltInProcessorMapper')} to signal that the respective processor was responsible for creating the vertex.
 The entry \`function\` signals that flowR used a processor for a user-defined function defined within the source code, \`unnamed\` signals that the function as an anonymous function definition.
 However, in general, flowR may use any fitting handler as an origin. For example, within a access definition, flowR will correspondingly redefine the meaning of \`:=\` to that of the \`table:assign\`. 
 
-
-
 ${(0, doc_structure_1.details)('Example: Simple Function Call (unresolved)', await (async () => {
                 const code = 'foo(x,3,y=3,)';
-                const [text, info] = await (0, doc_dfg_1.printDfGraphForCode)(shell, code, { mark: new Set([8]), exposeResult: true });
+                const [text, info] = await (0, doc_dfg_1.printDfGraphForCode)(parser, code, { mark: new Set([8]), exposeResult: true });
                 const callInfo = [...info.dataflow.graph.vertices(true)].find(([, vertex]) => vertex.tag === vertex_1.VertexType.FunctionCall && vertex.name === 'foo');
                 (0, assert_1.guard)(callInfo !== undefined, () => `Could not find call vertex for ${code}`);
                 const [callId, callVert] = callInfo;
@@ -251,13 +245,13 @@ ${(0, doc_structure_1.details)('1) the function resolves only to builtin definit
 
 Let's have a look at a simple assignment:
 
-${await (0, doc_dfg_1.printDfGraphForCode)(shell, 'x <- 2')}
+${await (0, doc_dfg_1.printDfGraphForCode)(parser, 'x <- 2')}
 
 In this case, the call does not have a single ${linkEdgeName(edge_1.EdgeType.Calls)} edge, which in general means (i.e., if the analysis is done and you are not looking at an intermediate result) it is bound to anything
 global beyond the scope of the given script. _flowR_ generally (theoretically at least) does not know if the call really refers to a built-in variable or function,
 as any code that is not part of the analysis could cause the semantics to change. 
 However, it is (in most cases) safe to assume we call a builtin if there is a builtin function with the given name and if there is no ${linkEdgeName(edge_1.EdgeType.Calls)} edge attached to a call.
-If you want to check the resolve targets, refer to ${(0, doc_types_1.shortLink)(resolve_by_name_1.resolveByName.name, vertexType.info)}.
+If you want to check the resolve targets, refer to ${ctx.link(resolve_by_name_1.resolveByName)}.
 `)}
 
 ${(0, doc_structure_1.details)('2) the function only resolves to definitions that are present in the program', `
@@ -266,7 +260,7 @@ Let's have a look at a call to a function named \`foo\` which is defined in the
 
 ${await (async () => {
                     const code = 'foo <- function() 3\nfoo()';
-                    const [text, info] = await (0, doc_dfg_1.printDfGraphForCode)(shell, code, { exposeResult: true, mark: new Set([6, '6->0', '6->1', '6->3']) });
+                    const [text, info] = await (0, doc_dfg_1.printDfGraphForCode)(parser, code, { exposeResult: true, mark: new Set([6, '6->0', '6->1', '6->3']) });
                     const numberOfEdges = [...info.dataflow.graph.edges()].flatMap(e => [...e[1].keys()]).length;
                     const callVertex = info.dataflow.graph.vertices(true).find(([, vertex]) => vertex.tag === vertex_1.VertexType.FunctionCall && vertex.name === 'foo');
                     (0, assert_1.guard)(callVertex !== undefined, () => `Could not find call vertex for ${code}`);
@@ -281,12 +275,12 @@ While it seems to be somewhat redundant given the ${linkEdgeName(edge_1.EdgeType
 you have to consider cases in which aliases are involved in the call resolution (e.g., with higher order functions).
 
 ${(0, doc_structure_1.details)('Example: Alias in Call Resolution', `In the following example, \`g\` ${linkEdgeName(edge_1.EdgeType.Reads)} the previous definition, but ${linkEdgeName(edge_1.EdgeType.Calls)} the function assigned to \`f\`.\n`
-                        + await (0, doc_dfg_1.printDfGraphForCode)(shell, 'f <- function() 3\ng <- f\ng()', { mark: new Set(['9', '9->5', '9->3']) }))}
+                        + await (0, doc_dfg_1.printDfGraphForCode)(parser, 'f <- function() 3\ng <- f\ng()', { mark: new Set(['9', '9->5', '9->3']) }))}
 			
 Lastly, the ${linkEdgeName(edge_1.EdgeType.Returns)} edge links the call to the return vertices(s) of the function.
 Please be aware, that these multiple exit points may be counter intuitive as they often appear with a nested call (usually a call to the built-in \`{\` function).
 
- ${(0, doc_structure_1.details)('(Advanced) Example: Multiple Exit Points May Still Reflect As One', await (0, doc_dfg_1.printDfGraphForCode)(shell, `
+ ${(0, doc_structure_1.details)('(Advanced) Example: Multiple Exit Points May Still Reflect As One', await (0, doc_dfg_1.printDfGraphForCode)(parser, `
 f <- function() {
 	if(u) return(3)
 	if(v) return(2)
@@ -299,7 +293,6 @@ But you have to beware that \`{\` is a function call as well (see below) and it
 In this scenario we show two types of such returns (or exit points): _explicit_ returns with the \`return\` function and _implicit_ returns (the result of the last evaluated expression).
 However, they are actually linked with the call of the built-in function \`{\` (and, in fact, they are highlighted in the mermaid graph).
 `)}
-
 		`;
                 })()}
 
@@ -314,7 +307,7 @@ Users may write… interesting pieces of code - for reasons we should not be int
 Consider a case in which you have a built-in function (like the assignment operator \`<-\`) and a user that wants to redefine the meaning of the function call _sometimes_:
 
 ${await (async () => {
-                    const [text, info] = await (0, doc_dfg_1.printDfGraphForCode)(shell, 'x <- 2\nif(u) `<-` <- `*`\nx <- 3', { switchCodeAndGraph: true, mark: new Set([9, '9->0', '9->10']), exposeResult: true });
+                    const [text, info] = await (0, doc_dfg_1.printDfGraphForCode)(parser, 'x <- 2\nif(u) `<-` <- `*`\nx <- 3', { switchCodeAndGraph: true, mark: new Set([9, '9->0', '9->10']), exposeResult: true });
                     const interestingUseOfAssignment = [...info.dataflow.graph.vertices(true)].find(([, vertex]) => vertex.id === 11);
                     (0, assert_1.guard)(interestingUseOfAssignment !== undefined, () => 'Could not find interesting assignment vertex for the code');
                     const [id, interestingVertex] = interestingUseOfAssignment;
@@ -323,7 +316,7 @@ ${await (async () => {
                     const name = interestingVertex.name;
                     (0, assert_1.guard)(name !== undefined, () => 'Could not find name for interesting assignment vertex');
                     return `
-${text}		
+${text}
 
 Interesting program, right? Running this with \`u <- TRUE\` will cause the last line to evaluate to \`6\` because we redefined the assignment
 operator to mean multiplication, while with \`u <- FALSE\` causes \`x\` to be assigned to \`3\`.
@@ -336,10 +329,10 @@ For starters, let's have a look at the environment of the call to \`<-\` in the
 ${(0, doc_env_1.printEnvironmentToMarkdown)(env.current)}
 
 Great, you should see a definition of \`<-\` which is constraint by the [control dependency](#control-dependencies) to the \`if\`.
-Hence, trying to re-resolve the call using \`${linker_1.getAllFunctionCallTargets.name}\` (defined in ${(0, doc_files_1.getFilePathMd)('../dataflow/internal/linker.ts')}) with the id \`${id}\` of the call as starting point will present you with
+Hence, trying to re-resolve the call using ${ctx.link(linker_1.getAllFunctionCallTargets)} (defined in ${(0, doc_files_1.getFilePathMd)('../dataflow/internal/linker.ts')}) with the id \`${id}\` of the call as starting point will present you with
 the following target ids: { \`${[...(0, linker_1.getAllFunctionCallTargets)(id, info.dataflow.graph)].join('`, `')}\` }.
 This way we know that the call may refer to the built-in assignment operator or to the multiplication.
-Similarly, trying to resolve the name with \`${resolve_by_name_1.resolveByName.name}\` using the environment attached to the call vertex (filtering for any reference type) returns (in a similar fashion): 
+Similarly, trying to resolve the name with ${ctx.link(resolve_by_name_1.resolveByName)}\` using the environment attached to the call vertex (filtering for any reference type) returns (in a similar fashion): 
 { \`${(0, resolve_by_name_1.resolveByName)(name, env)?.map(d => d.nodeId).join('`, `')}\` } (however, the latter will not trace aliases).
 
 	`;
@@ -348,26 +341,26 @@ Similarly, trying to resolve the name with \`${resolve_by_name_1.resolveByName.n
 `)}
 
 
-Similar to finding the definitions read by a variable use, please use the ${(0, doc_types_1.shortLink)(linker_1.getAllFunctionCallTargets.name, vertexType.info)} function to find all possible definitions of a function call,
-as explained in the [working with the dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Working%20with%20the%20Dataflow%20Graph) section.`
+Similar to finding the definitions read by a variable use, please use the ${ctx.link(linker_1.getAllFunctionCallTargets)} function to find all possible definitions of a function call,
+as explained in the [working with the dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow%20Graph#working-with-the-dataflow-graph) section.`
             })}
 
 Function calls are the most complicated mechanism in R as essentially everything is a function call.
 Even **control structures** like \`if(p) a else b\` are desugared into function calls (e.g., as \`\` \`if\`(p, a, b) \`\`).
-${(0, doc_structure_1.details)('Example: <code>if</code> as a Function Call', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'if(p) a else b'))}
+${(0, doc_structure_1.details)('Example: <code>if</code> as a Function Call', await (0, doc_dfg_1.printDfGraphForCode)(parser, 'if(p) a else b'))}
 
 Similarly, you should be aware of calls to **anonymous functions**, which may appear given directly (e.g. as \`(function() 1)()\`) or indirectly, with code
 directly calling the return of another function call: \`foo()()\`.
-${(0, doc_structure_1.details)('Example: Anonymous Function Call (given directly)', await (0, doc_dfg_1.printDfGraphForCode)(shell, '(function() 1)()', { mark: new Set([6, '6->4']) }))}
+${(0, doc_structure_1.details)('Example: Anonymous Function Call (given directly)', await (0, doc_dfg_1.printDfGraphForCode)(parser, '(function() 1)()', { mark: new Set([6, '6->4']) }))}
 
-${(0, doc_structure_1.details)('Example: Anonymous Function Call (given indirectly)', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'foo <- function() return(function() 3)\nfoo()()', { mark: new Set([12, '12->4']) }))}
+${(0, doc_structure_1.details)('Example: Anonymous Function Call (given indirectly)', await (0, doc_dfg_1.printDfGraphForCode)(parser, 'foo <- function() return(function() 3)\nfoo()()', { mark: new Set([12, '12->4']) }))}
 
 ${(0, doc_structure_1.block)({
                 type: 'NOTE',
                 content: `Now you might be asking yourself how to differentiate anonymous and named functions and what you have to keep in mind when working with them?
 
 Unnamed functions have an array of signatures which you can use to identify them. 
-But in short: the \`origin\` attribute of the ${(0, doc_types_1.shortLink)('DataflowGraphVertexFunctionCall', vertexType.info)} is \`${unnamed_call_handling_1.UnnamedFunctionCallOrigin}\`.
+But in short: the \`origin\` attribute of the ${ctx.link('DataflowGraphVertexFunctionCall')} is \`${unnamed_call_handling_1.UnnamedFunctionCallOrigin}\`.
 Please be aware that unnamed functions still have a \`name\` property to give it a unique identifier that can be used for debugging and reference.
 This name _always_ starts with \`${unnamed_call_handling_1.UnnamedFunctionCallPrefix}\`.
 
@@ -379,39 +372,38 @@ To know which function is called, please rely on the ${linkEdgeName(edge_1.EdgeT
 
 Another interesting case is a function with **side effects**, most prominently with the super-assignment \`<<-\`.
 In this case, you may encounter the ${linkEdgeName(edge_1.EdgeType.SideEffectOnCall)} as exemplified below.
-${(0, doc_structure_1.details)('Example: Function Call with a Side-Effect', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'f <- function() x <<- 3\n f()', { mark: new Set([8, '1->8']) }))}
+${(0, doc_structure_1.details)('Example: Function Call with a Side-Effect', await (0, doc_dfg_1.printDfGraphForCode)(parser, 'f <- function() x <<- 3\n f()', { mark: new Set([8, '1->8']) }))}
  
 `,
             code: 'foo()',
             expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().call('1@foo', 'foo', [])
         }, []]);
     vertexExplanations.set(vertex_1.VertexType.VariableDefinition, [{
-            shell,
             name: 'Variable Definition Vertex',
             type: vertex_1.VertexType.VariableDefinition,
             description: `
 Defined variables most commonly occur in the context of an assignment, for example, with the \`<-\` operator as shown above.
 
-${(0, doc_structure_1.details)('Example: Super Definition (<code><<-</code>)', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'x <<- 1', { mark: new Set([0]) }))}
+${(0, doc_structure_1.details)('Example: Super Definition (<code><<-</code>)', await (0, doc_dfg_1.printDfGraphForCode)(parser, 'x <<- 1', { mark: new Set([0]) }))}
 
 The implementation is relatively sparse and similar to the other marker vertices:
 
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowGraphVertexVariableDefinition' })}
+${ctx.hierarchy('DataflowGraphVertexVariableDefinition')}
 
 Of course, there are not just operators that define variables, but also functions, like \`assign\`.
 
-${(0, doc_structure_1.details)('Example: Using <code>assign</code>', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'assign("x", 1)\nx', { mark: new Set([1]) })
+${(0, doc_structure_1.details)('Example: Using <code>assign</code>', await (0, doc_dfg_1.printDfGraphForCode)(parser, 'assign("x", 1)\nx', { mark: new Set([1]) })
                 + `\nThe example may be misleading as the visualization uses \`${node_id_1.recoverName.name}\` to print the lexeme of the variable. However, this actually defines the variable \`x\` (without the quotes) as you can see with the ${linkEdgeName(edge_1.EdgeType.Reads)} edge.`)}
 
 Please be aware, that the name of the symbol defined may differ from what you read in the program as R allows the assignments to strings, escaped names, and more:
 
-${(0, doc_structure_1.details)('Example: Assigning with an Escaped Name', await (0, doc_dfg_1.printDfGraphForCode)(shell, '`x` <- 1\nx', { mark: new Set([0]) }))}
-${(0, doc_structure_1.details)('Example: Assigning with a String', await (0, doc_dfg_1.printDfGraphForCode)(shell, '"x" <- 1\nx', { mark: new Set([0]) }))}
+${(0, doc_structure_1.details)('Example: Assigning with an Escaped Name', await (0, doc_dfg_1.printDfGraphForCode)(parser, '`x` <- 1\nx', { mark: new Set([0]) }))}
+${(0, doc_structure_1.details)('Example: Assigning with a String', await (0, doc_dfg_1.printDfGraphForCode)(parser, '"x" <- 1\nx', { mark: new Set([0]) }))}
 
 Definitions may be constrained by conditionals (_flowR_ takes care of calculating the dominating front for you).
 
 ${(0, doc_structure_1.details)('Conditional Assignments', await (async () => {
-                const constrainedDefinitions = await (0, doc_dfg_1.printDfGraphForCode)(shell, 'x <- 0\nif(u) x <- 1 else x <- 2\nx', { exposeResult: true });
+                const constrainedDefinitions = await (0, doc_dfg_1.printDfGraphForCode)(parser, 'x <- 0\nif(u) x <- 1 else x <- 2\nx', { exposeResult: true });
                 const [text, info] = constrainedDefinitions;
                 const finalEnvironment = (0, doc_env_1.printEnvironmentToMarkdown)(info.dataflow.environment.current);
                 return `
@@ -430,18 +422,17 @@ As you can see, _flowR_ is able to recognize that the initial definition of \`x\
             expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().defineVariable('1@x', 'x')
         }, []]);
     vertexExplanations.set(vertex_1.VertexType.FunctionDefinition, [{
-            shell,
             name: 'Function Definition Vertex',
             type: vertex_1.VertexType.FunctionDefinition,
             description: `
 Defining a function does do a lot of things: 1) it creates a new scope, 2) it may introduce parameters which act as promises and which are only evaluated if they are actually required in the body, 3) it may access the enclosing environments and the callstack.
 The vertex object in the dataflow graph stores multiple things, including all exit points, the enclosing environment if necessary, and the information of the subflow (the "body" of the function).
 
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowGraphVertexFunctionDefinition' })}
+${ctx.hierarchy('DataflowGraphVertexFunctionDefinition')}
 The subflow is defined like this:
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowFunctionFlowInformation' })}
+${ctx.hierarchy('DataflowFunctionFlowInformation')}
 And if you are interested in the exit points, they are defined like this:
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'ExitPoint' })}
+${ctx.hierarchy('ExitPoint')}
 
 
 Whenever we visualize a function definition, we use a dedicated node to represent the anonymous function object,
@@ -457,7 +448,7 @@ the actual dataflow graph is flat, and you can query all root vertices (i.e., th
 vertices of function definitions or not (e.g., \`${new graph_1.DataflowGraph(undefined).vertices.name}\`)
 
 ${(0, doc_structure_1.details)('Example: Nested Function Definitions', await (async () => {
-                    const [text, info] = await (0, doc_dfg_1.printDfGraphForCode)(shell, 'f <- function() { g <- function() 3 }', { mark: new Set([9, 6]), exposeResult: true });
+                    const [text, info] = await (0, doc_dfg_1.printDfGraphForCode)(parser, 'f <- function() { g <- function() 3 }', { mark: new Set([9, 6]), exposeResult: true });
                     const definitions = info.dataflow.graph.vertices(true)
                         .filter(([, vertex]) => vertex.tag === vertex_1.VertexType.FunctionDefinition)
                         .map(([id, vertex]) => `| \`${id}\` | { \`${[...vertex.subflow.graph].join('`, `')}\` } |`)
@@ -480,8 +471,8 @@ However, you can use the [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normal
 
 ${(0, doc_structure_1.details)('Example: Parameters of a Function', await (async () => {
                     const code = 'f <- function(x, y = 3) x + y';
-                    const [text, info] = await (0, doc_dfg_1.printDfGraphForCode)(shell, code, { mark: new Set([10, 1, 3]), exposeResult: true });
-                    const ast = await (0, doc_normalized_ast_1.printNormalizedAstForCode)(shell, code, { prefix: 'flowchart LR\n', showCode: false });
+                    const [text, info] = await (0, doc_dfg_1.printDfGraphForCode)(parser, code, { mark: new Set([10, 1, 3]), exposeResult: true });
+                    const ast = await (0, doc_normalized_ast_1.printNormalizedAstForCode)(parser, code, { prefix: 'flowchart LR\n', showCode: false });
                     const functionDefinition = [...info.dataflow.graph.vertices(true)].find(([, vertex]) => vertex.tag === vertex_1.VertexType.FunctionDefinition);
                     (0, assert_1.guard)(functionDefinition !== undefined, () => `Could not find function definition for ${code}`);
                     const [id] = functionDefinition;
@@ -502,7 +493,7 @@ ${ast}
 
 Last but not least, please keep in mind that R offers another way of writing anonymous functions (using the backslash): 
 
-${await (0, doc_dfg_1.printDfGraphForCode)(shell, '\\(x) x + 1', { switchCodeAndGraph: true })}
+${await (0, doc_dfg_1.printDfGraphForCode)(parser, '\\(x) x + 1', { switchCodeAndGraph: true })}
 
 Besides this being a theoretically "shorter" way of defining a function, this behaves similarly to the use of \`function\`. 
 
@@ -516,14 +507,13 @@ Besides this being a theoretically "shorter" way of defining a function, this be
         const get = vertexExplanations.get(vertex);
         (0, assert_1.guard)(get !== undefined, () => `No explanation for vertex type ${vertex}`);
         const [expl, subExplanations] = get;
-        results.push(await explanation(expl, ++i, ...subExplanations));
+        results.push(await explanation(expl, parser, ++i, ...subExplanations));
     }
     return results.join('\n');
 }
-async function getEdgesExplanations(shell, vertexType) {
+async function getEdgesExplanations(parser, ctx) {
     const edgeExplanations = new Map();
     edgeExplanations.set(edge_1.EdgeType.Reads, [{
-            shell,
             name: 'Reads Edge',
             type: edge_1.EdgeType.Reads,
             description: `
@@ -534,20 +524,20 @@ ${(0, doc_structure_1.block)({
                 content: `
 A ${linkEdgeName(edge_1.EdgeType.Reads)} edge is not a transitive closure and only links the "directly read" definition(s).
 Our abstract domains resolving transitive ${linkEdgeName(edge_1.EdgeType.Reads)} edges (and for that matter, following ${linkEdgeName(edge_1.EdgeType.Returns)} as well)
-are currently tailored to what we need in _flowR_. Hence, we offer a function like ${(0, doc_types_1.shortLink)(linker_1.getAllFunctionCallTargets.name, vertexType.info)},
-as well as ${(0, doc_types_1.shortLink)(resolve_by_name_1.resolvesToBuiltInConstant.name, vertexType.info)} which do this for specific cases.
-Refer to ${(0, doc_types_1.shortLink)(dfg_get_origin_1.getOriginInDfg.name, vertexType.info)} for a more general solution, as explained in [working with the dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Working%20with%20the%20Dataflow%20Graph).
+are currently tailored to what we need in _flowR_. Hence, we offer a function like ${ctx.link(linker_1.getAllFunctionCallTargets)},
+as well as ${ctx.link(resolve_by_name_1.resolvesToBuiltInConstant)} which do this for specific cases.
+Refer to ${ctx.link(dfg_get_origin_1.getOriginInDfg)} for a more general solution, as explained in [working with the dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow%20Graph#working-with-the-dataflow-graph).
 
-${(0, doc_structure_1.details)('Example: Multi-Level Reads', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'x <- 3\ny <- x\nprint(y)', { mark: new Set(['9->7', '7->3', '4->0']) }))}
+${(0, doc_structure_1.details)('Example: Multi-Level Reads', await (0, doc_dfg_1.printDfGraphForCode)(parser, 'x <- 3\ny <- x\nprint(y)', { mark: new Set(['9->7', '7->3', '4->0']) }))}
 
 Similarly, ${linkEdgeName(edge_1.EdgeType.Reads)} can be cyclic, for example in the context of loops:
 
-${(0, doc_structure_1.details)('Example: Cyclic Reads', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'for(i in v) x <- x + 1', { mark: new Set(['3->2']) }))}
+${(0, doc_structure_1.details)('Example: Cyclic Reads', await (0, doc_dfg_1.printDfGraphForCode)(parser, 'for(i in v) x <- x + 1', { mark: new Set(['3->2']) }))}
 				`
             })}
 
 Reads edges may point to built-in definitions as well, to signal that something relates to a built-in element of flowR.
-Their targets are not part of the ${(0, doc_types_1.shortLink)(graph_1.DataflowGraph.name, vertexType.info)} but only markers to signal that the respective definition is a built-in.
+Their targets are not part of the ${ctx.link(graph_1.DataflowGraph)} but only markers to signal that the respective definition is a built-in.
 
  
 Please refer to the explanation of the respective vertices for more information.
@@ -566,12 +556,11 @@ Please refer to the explanation of the respective vertices for more information.
                 expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().reads('1:20', '1@x')
             }]]);
     edgeExplanations.set(edge_1.EdgeType.DefinedBy, [{
-            shell,
             name: 'DefinedBy Edge', /* concat for link generation */
             type: edge_1.EdgeType.DefinedBy,
             description: `
 The source vertex is usually a [\`variable definition\`](#variable-definition-vertex) linking the defined symbol to the entry point of the resulting side.
-${(0, doc_structure_1.details)('In general, this does not have to be the right hand side of the operator.', await (0, doc_dfg_1.printDfGraphForCode)(shell, '3 -> x', { mark: new Set([0]) }))}
+${(0, doc_structure_1.details)('In general, this does not have to be the right hand side of the operator.', await (0, doc_dfg_1.printDfGraphForCode)(parser, '3 -> x', { mark: new Set([0]) }))}
 
 However, nested definitions can carry it (in the nested case, \`x\` is defined by the return value of <code>\\\`<-\\\`(y, z)</code>). Additionally, we link the assignment function.
 
@@ -590,16 +579,14 @@ However, nested definitions can carry it (in the nested case, \`x\` is defined b
                 expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().definedBy('1@x', '1:8')
             }]]);
     edgeExplanations.set(edge_1.EdgeType.Calls, [{
-            shell,
             name: 'Calls Edge',
             type: edge_1.EdgeType.Calls,
             description: `Link the [function call](#function-call-vertex) to the [function definition](#function-definition-vertex) that is called. To find all called definitions, 
-		please use the ${(0, doc_types_1.shortLink)(dfg_get_origin_1.getOriginInDfg.name, vertexType.info)} function, as explained in [working with the dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Working%20with%20the%20Dataflow%20Graph).`,
+		please use the ${ctx.link(dfg_get_origin_1.getOriginInDfg.name)} function, as explained in [working with the dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Working%20with%20the%20Dataflow%20Graph).`,
             code: 'foo <- function() {}\nfoo()',
             expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().calls('2@foo', '1@function')
         }, []]);
     edgeExplanations.set(edge_1.EdgeType.Returns, [{
-            shell,
             name: 'Returns Edge',
             type: edge_1.EdgeType.Returns,
             description: `Link the [function call](#function-call-vertex) to the exit points of the target definition (this may incorporate the call-context).
@@ -607,17 +594,17 @@ As you can see in the example, this happens for user-defined functions (like \`f
 However, these edges are specific to scenarios in which flowR knows that a specific element is returned. 
 For contrast, compare this to a use of, for example, \`+\`:
 		
-${(0, doc_structure_1.details)('Example: No returns edge for +', await (0, doc_dfg_1.printDfGraphForCode)(shell, '1 + 1'))}
+${(0, doc_structure_1.details)('Example: No returns edge for +', await (0, doc_dfg_1.printDfGraphForCode)(parser, '1 + 1'))}
 
 Here, we do not get a ${linkEdgeName(edge_1.EdgeType.Returns)} edge as this function call creates a new value based on its arguments.
-In these scenarios you should rely on the \`args\` property of the ${(0, doc_types_1.shortLink)('DataflowGraphVertexFunctionCall', vertexType.info)} 
+In these scenarios you should rely on the \`args\` property of the ${ctx.link('DataflowGraphVertexFunctionCall')} 
 and use the arguments to calculate what you need to know. Alternatively, you can track the ${linkEdgeName(edge_1.EdgeType.Argument)} edges.
 
 In general, the ${linkEdgeName(edge_1.EdgeType.Returns)} edge already does most of the heavy lifting for you, by respecting control flow influences and
 (as long as flowR is able to detect it) dead code.
 
 ${(0, doc_structure_1.details)('Example: Tricky Returns', `We show the _simplified_ DFG for simplicity and highlight all ${linkEdgeName(edge_1.EdgeType.Returns)} edges involved in tracking the return of a call to \`f\` (as ${linkEdgeName(edge_1.EdgeType.Returns)} are never transitive and must hence be followed):\n` +
-                await (0, doc_dfg_1.printDfGraphForCode)(shell, 'f <- function() { if(u) { return(3); 2 } else 42 }\nf()', {
+                await (0, doc_dfg_1.printDfGraphForCode)(parser, 'f <- function() { if(u) { return(3); 2 } else 42 }\nf()', {
                     simplified: true,
                     mark: new Set(['19->15', '15->14', '14->12', '14->11', '11->9', '9->7'])
                 })
@@ -642,9 +629,8 @@ f <- function() x
 x <- 3
 f()
 	`.trim();
-    const dfInfo = await (0, doc_dfg_1.printDfGraphForCode)(shell, lateBindingExample, { switchCodeAndGraph: true, codeOpen: true, mark: new Set([1, '1->5', '9->5']) });
+    const dfInfo = await (0, doc_dfg_1.printDfGraphForCode)(parser, lateBindingExample, { switchCodeAndGraph: true, codeOpen: true, mark: new Set([1, '1->5', '9->5']) });
     edgeExplanations.set(edge_1.EdgeType.DefinesOnCall, [{
-            shell,
             name: 'DefinesOnCall Edge',
             type: edge_1.EdgeType.DefinesOnCall,
             description: `*This edge is usually joined with ${linkEdgeName(edge_1.EdgeType.DefinedByOnCall)}!*
@@ -668,7 +654,6 @@ ${dfInfo}
             expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().definesOnCall('$11', '$1').definedByOnCall('$1', '$11')
         }, []]);
     edgeExplanations.set(edge_1.EdgeType.DefinedByOnCall, [{
-            shell,
             name: 'DefinedByOnCall Edge',
             type: edge_1.EdgeType.DefinedByOnCall,
             description: `*This edge is usually joined with ${linkEdgeName(edge_1.EdgeType.DefinesOnCall)}!*
@@ -678,7 +663,6 @@ ${dfInfo}
             expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().definesOnCall('$11', '$1').definedByOnCall('$1', '$11')
         }, []]);
     edgeExplanations.set(edge_1.EdgeType.Argument, [{
-            shell,
             name: 'Argument Edge',
             type: edge_1.EdgeType.Argument,
             description: `Links a [function call](#function-call-vertex) to the entry point of its arguments. If we do not know the target of such a call, we automatically assume that all arguments are read by the call as well!
@@ -689,7 +673,6 @@ The exception to this is the [function definition](#function-definition-vertex)
             expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().argument('1@f', '1@x').reads('1@f', '1@x').argument('1@f', '1@y').reads('1@f', '1@y')
         }, []]);
     edgeExplanations.set(edge_1.EdgeType.SideEffectOnCall, [{
-            shell,
             name: 'SideEffectOnCall Edge',
             type: edge_1.EdgeType.SideEffectOnCall,
             description: 'Links a global side effect to an affected function call (e.g., a super definition within the function body)',
@@ -697,7 +680,6 @@ The exception to this is the [function definition](#function-definition-vertex)
             expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().sideEffectOnCall('1@x', '2@f')
         }, []]);
     edgeExplanations.set(edge_1.EdgeType.NonStandardEvaluation, [{
-            shell,
             name: 'NonStandardEvaluation Edge',
             type: edge_1.EdgeType.NonStandardEvaluation,
             description: `
@@ -714,9 +696,8 @@ Yet, you may choose to follow these references for other queries. For now, _flow
 Besides the obvious quotation there are other cases in which _flowR_ may choose to create a ${linkEdgeName(edge_1.EdgeType.NonStandardEvaluation)} edge, there are
 some that may appear to be counter-intuitive. For example, a for-loop body, as in the following example.
 
-${(0, doc_structure_1.details)('Example: For-Loop Body', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'for(i in v) b', { mark: new Set([2, '4->2']) }))}	
-${(0, doc_structure_1.details)('Example: While-Loop Body', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'while(TRUE) b', { mark: new Set([1, '3->1']) }))}	
-
+${(0, doc_structure_1.details)('Example: For-Loop Body', await (0, doc_dfg_1.printDfGraphForCode)(parser, 'for(i in v) b', { mark: new Set([2, '4->2']) }))}
+${(0, doc_structure_1.details)('Example: While-Loop Body', await (0, doc_dfg_1.printDfGraphForCode)(parser, 'while(TRUE) b', { mark: new Set([1, '3->1']) }))}
 				`
             })}
 `,
@@ -737,33 +718,28 @@ ${(0, doc_structure_1.details)('Example: While-Loop Body', await (0, doc_dfg_1.p
         const get = edgeExplanations.get(edge);
         (0, assert_1.guard)(get !== undefined, () => `No explanation for edge type ${edge}`);
         const [expl, subExplanations] = get;
-        results.push(`<a id='${edgeTypeToId(edge)}'></a>` + await explanation(expl, ++i, ...subExplanations));
+        results.push(`<a id='${edgeTypeToId(edge)}'></a>` + await explanation(expl, parser, ++i, ...subExplanations));
     }
     return results.join('\n');
 }
 async function dummyDataflow() {
-    const analyzer = await new flowr_analyzer_builder_1.FlowrAnalyzerBuilder((0, retriever_1.requestFromInput)('x <- 1\nx + 1')).build();
+    const analyzer = await new flowr_analyzer_builder_1.FlowrAnalyzerBuilder().build();
+    analyzer.addRequest('x <- 1\nx + 1');
     const result = await analyzer.dataflow();
     analyzer.close();
     return result;
 }
-async function getText(shell) {
-    const rversion = (await shell.usedRVersion())?.format() ?? 'unknown';
-    /* we collect type information on the graph */
-    const vertexType = (0, doc_types_1.getTypesFromFolder)({
-        rootFolder: path_1.default.resolve('./src/'),
-        typeNameForMermaid: 'DataflowGraphVertexInfo',
-        inlineTypes: ['MergeableRecord']
-    });
-    const edgeType = (0, doc_types_1.getTypesFromFolder)({
-        files: [path_1.default.resolve('./src/dataflow/graph/edge.ts'), path_1.default.resolve('./src/dataflow/graph/graph.ts'), path_1.default.resolve('./src/dataflow/environments/identifier.ts'), path_1.default.resolve('./src/dataflow/info.ts')],
-        typeNameForMermaid: 'EdgeType',
-        inlineTypes: ['MergeableRecord']
-    });
-    return `${(0, doc_auto_gen_1.autoGenHeader)({ filename: module.filename, purpose: 'dataflow graph', rVersion: rversion })}
-
-This page briefly summarizes flowR's dataflow graph, represented by the ${(0, doc_types_1.shortLink)(graph_1.DataflowGraph.name, vertexType.info)} class within the code.
-In case you want to manually build such a graph (e.g., for testing), you can use the ${(0, doc_types_1.shortLink)(dataflowgraph_builder_1.DataflowGraphBuilder.name, vertexType.info)}.
+/**
+ * https://github.com/flowr-analysis/flowr/wiki/Dataflow-Graph
+ */
+class WikiDataflowGraph extends doc_maker_1.DocMaker {
+    constructor() {
+        super('wiki/Dataflow Graph.md', module.filename, 'dataflow graph');
+    }
+    async text({ ctx, treeSitter }) {
+        return `
+This page briefly summarizes flowR's dataflow graph, represented by the ${ctx.link(graph_1.DataflowGraph)} class within the code.
+In case you want to manually build such a graph (e.g., for testing), you can use the ${ctx.link(dataflowgraph_builder_1.DataflowGraphBuilder)}.
 If you are interested in which features we support and which features are still to be worked on, please refer to our [capabilities](${doc_files_1.FlowrWikiBaseRef}/Capabilities) page.
 In summary, we discuss the following topics:
 
@@ -774,7 +750,7 @@ In summary, we discuss the following topics:
 	- [Unknown Side Effects](#unknown-side-effects)
 - [Working with the Dataflow Graph](#dfg-working)
 
-Please be aware that the accompanied [dataflow information](#dataflow-information) (${(0, doc_types_1.shortLink)('DataflowInformation', vertexType.info)}) returned by _flowR_ contains things besides the graph,
+Please be aware that the accompanied [dataflow information](#dataflow-information) (${ctx.link('DataflowInformation')}) returned by _flowR_ contains things besides the graph,
 like the entry and exit points of the subgraphs, and currently active references (see [below](#dataflow-information)).
 Additionally, you may be interested in the set of [Unknown Side Effects](#unknown-side-effects), marking calls which _flowR_ is unable to handle correctly.
 
@@ -788,9 +764,11 @@ wiki page if you are unsure.
 > There is also a simplified perspective available with ${(0, doc_cli_option_1.getReplCommand)('dataflowsimple*')} that does not show everything but is easier to read.
 > When using _flowR_ as a library, you may use the functions in ${(0, doc_files_1.getFilePathMd)('../util/mermaid/dfg.ts')}.
 > 
-> If you receive a dataflow graph in its serialized form (e.g., by talking to a [_flowR_ server](${doc_files_1.FlowrWikiBaseRef}/Interface)), you can use ${(0, doc_types_1.shortLink)(`${graph_1.DataflowGraph.name}::${graph_1.DataflowGraph.fromJson.name}`, vertexType.info, true, 'i')} to retrieve the graph from the JSON representation.
+> If you receive a dataflow graph in its serialized form (e.g., by talking to a [_flowR_ server](${doc_files_1.FlowrWikiBaseRef}/Interface)), you can use ${ctx.link(`${graph_1.DataflowGraph.name}::${graph_1.DataflowGraph.fromJson.name}`, { realNameWrapper: 'i', codeFont: true })} to retrieve the graph from the JSON representation.
+>
+> Also, check out the [${doc_files_1.FlowrGithubGroupName}/sample-analyzer-df-diff](${doc_files_1.FlowrGithubBaseRef}/sample-analyzer-df-diff) repository for a complete example project creating and comparing dataflow graphs.
 
-${await (0, doc_dfg_1.printDfGraphForCode)(shell, 'x <- 3\ny <- x + 1\ny')}
+${await (0, doc_dfg_1.printDfGraphForCode)(treeSitter, 'x <- 3\ny <- x + 1\ny')}
 
 
 The above dataflow graph showcases the general gist. We define a dataflow graph as a directed graph G = (V, E), differentiating between ${(0, doc_data_dfg_util_1.getAllVertices)().length} types of vertices V and
@@ -806,7 +784,7 @@ The following vertices types exist:
 
 1. ${(0, doc_data_dfg_util_1.getAllVertices)().map(([k, v], index) => `[\`${k}\`](#${index + 1}-${v.toLowerCase().replace(/\s/g, '-')}-vertex)`).join('\n1. ')}
 
-${vertexType.mermaid.trim().length > 0 ? (0, doc_structure_1.details)('Class Diagram', 'All boxes should link to their respective implementation:\n' + (0, doc_code_1.codeBlock)('mermaid', vertexType.mermaid)) : ''}
+${(0, doc_structure_1.details)('Class Diagram', 'All boxes should link to their respective implementation:\n' + (0, doc_code_1.codeBlock)('mermaid', ctx.mermaid('DataflowGraphVertexInfo', ['MergeableRecord'])))}
 
 </details>
 
@@ -818,7 +796,7 @@ The following edges types exist, internally we use bitmasks to represent multipl
 
 1. ${(0, doc_data_dfg_util_1.getAllEdges)().map(([k, v], index) => `[\`${k}\` (${v})](#${index + 1}-${k.toLowerCase().replace(/\s/g, '-')}-edge)`).join('\n1. ')}
 
-${edgeType.mermaid.trim().length > 0 ? (0, doc_structure_1.details)('Class Diagram', 'All boxes should link to their respective implementation:\n' + (0, doc_code_1.codeBlock)('mermaid', edgeType.mermaid)) : ''}
+${(0, doc_structure_1.details)('Class Diagram', 'All boxes should link to their respective implementation:\n' + (0, doc_code_1.codeBlock)('mermaid', ctx.mermaid('EdgeType', ['MergeableRecord'])))}
 
 </details>
 
@@ -830,9 +808,9 @@ The following sections present details on the different types of vertices and ed
 > [!NOTE]
 > Every dataflow vertex holds an \`id\` which links it to the respective node in the [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized-AST).
 > So if you want more information about the respective vertex, you can usually access more information
-> using the <code>${(0, doc_types_1.shortLink)(`${graph_1.DataflowGraph.name}`, vertexType.info, false, 'i')}::idMap</code> linked to the dataflow graph:
+> using the <code>${ctx.link(`${graph_1.DataflowGraph.name}`, { codeFont: false, realNameWrapper: 'i' })}::idMap</code> linked to the dataflow graph:
 ${(0, doc_general_1.prefixLines)((0, doc_code_1.codeBlock)('ts', 'const node = graph.idMap.get(id);'), '> ')}
-> In case you just need the name (\`lexeme\`) of the respective vertex, ${(0, doc_types_1.shortLink)(node_id_1.recoverName.name, vertexType.info)} can help you out:
+> In case you just need the name (\`lexeme\`) of the respective vertex, ${ctx.link(node_id_1.recoverName)} can help you out:
 ${(0, doc_general_1.prefixLines)((0, doc_code_1.codeBlock)('ts', `const name = ${node_id_1.recoverName.name}(id, graph.idMap);`), '> ')}
 >
 > Please note, that not every node in the [normalized AST](${doc_files_1.FlowrWikiBaseRef}/Normalized-AST) is represented in the dataflow graph.
@@ -846,32 +824,32 @@ ${(0, doc_structure_1.section)('Vertices', 2, 'vertices')}
 
 1. ${(0, doc_data_dfg_util_1.getAllVertices)().map(([k, v], index) => `[\`${k}\`](#${index + 1}-${v.toLowerCase().replace(/\s/g, '-')}-vertex)`).join('\n1. ')}
 
-${await getVertexExplanations(shell, vertexType)}
+${await getVertexExplanations(treeSitter, ctx)}
 
 ${(0, doc_structure_1.section)('Edges', 2, 'edges')}
 
 1. ${(0, doc_data_dfg_util_1.getAllEdges)().map(([k, v], index) => `[\`${k}\` (${v})](#${index + 1}-${k.toLowerCase().replace(/\s/g, '-')}-edge)`).join('\n1. ')}
 
-${await getEdgesExplanations(shell, vertexType)}
+${await getEdgesExplanations(treeSitter, ctx)}
 
 ${(0, doc_structure_1.section)('Control Dependencies', 2, 'control-dependencies')}
 
 Each vertex may have a list of active control dependencies.
-They hold the ${(0, doc_types_1.shortLink)('NodeId', vertexType.info)} of all nodes that effect if the current vertex is part of the execution or not,
+They hold the ${ctx.link('NodeId')} of all nodes that effect if the current vertex is part of the execution or not,
 and a boolean flag \`when\` to indicate if the control dependency is active when the condition is \`true\` or \`false\`.
 
 As an example, consider the following dataflow graph:
 
-${await (0, doc_dfg_1.printDfGraphForCode)(shell, 'if(p) a else b')}
+${await (0, doc_dfg_1.printDfGraphForCode)(treeSitter, 'if(p) a else b')}
 
 Whenever we visualize a graph, we represent the control dependencies as grayed out edges with a \`CD\` prefix, followed
 by the \`when\` flag.
 In the above example, both \`a\` and \`b\` depend on the \`if\`. Please note that they are _not_ linked to the result of
 the condition itself as this is the more general linkage point (and harmonizes with other control structures, especially those which are user-defined).
 
-${(0, doc_structure_1.details)('Example: Multiple Vertices (Assignment)', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'if(p) a <- 1'))}
-${(0, doc_structure_1.details)('Example: Multiple Vertices (Arithmetic Expression)', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'if(p) 3 + 2'))}
-${(0, doc_structure_1.details)('Example: Nested Conditionals', await (0, doc_dfg_1.printDfGraphForCode)(shell, 'if(x) { if(y) a else b } else c'))}
+${(0, doc_structure_1.details)('Example: Multiple Vertices (Assignment)', await (0, doc_dfg_1.printDfGraphForCode)(treeSitter, 'if(p) a <- 1'))}
+${(0, doc_structure_1.details)('Example: Multiple Vertices (Arithmetic Expression)', await (0, doc_dfg_1.printDfGraphForCode)(treeSitter, 'if(p) 3 + 2'))}
+${(0, doc_structure_1.details)('Example: Nested Conditionals', await (0, doc_dfg_1.printDfGraphForCode)(treeSitter, 'if(x) { if(y) a else b } else c'))}
 
 
 ${(0, doc_structure_1.section)('Dataflow Information', 2, 'dataflow-information')}
@@ -898,9 +876,9 @@ ${(0, doc_code_1.codeBlock)('ts', dummyDataflow.toString())}
 Now, you can find the dataflow _information_ with \`result.dataflow\`. More specifically, the graph is stored in \`result.dataflow.graph\` and looks like this:
 
 ${await (async () => {
-        const result = await dummyDataflow();
-        const dfGraphString = (0, doc_dfg_1.printDfGraph)(result.graph);
-        return `
+            const result = await dummyDataflow();
+            const dfGraphString = (0, doc_dfg_1.printDfGraph)(result.graph);
+            return `
 ${dfGraphString}
 
 However, the dataflow information contains more, quite a lot of information in fact.
@@ -916,15 +894,15 @@ ${(0, doc_code_1.codeBlock)('text', JSON.stringify(result, json_1.jsonReplacer))
 
 You may be interested in its implementation:
 
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'DataflowInformation' })}
+${ctx.hierarchy('DataflowInformation')}
 
 Let's start by looking at the properties of the dataflow information object: ${Object.keys(result).map(k => `\`${k}\``).join(', ')}.
 
 ${(() => {
-            /* this includes the meta field for timing and the quick CFG in order to enable re-use and improve performance */
-            (0, assert_1.guard)(Object.keys(result).length === 9, () => 'Update Dataflow Documentation!');
-            return '';
-        })()}
+                /* this includes the meta field for timing and the quick CFG in order to enable re-use and improve performance */
+                (0, assert_1.guard)(Object.keys(result).length === 9, () => 'Update Dataflow Documentation!');
+                return '';
+            })()}
 
 There are three sets of references.
 **in** (ids: ${JSON.stringify(new Set(result.in.map(n => n.nodeId)), json_1.jsonReplacer)}) and **out** (ids: ${JSON.stringify(new Set(result.out.map(n => n.nodeId)), json_1.jsonReplacer)}) contain the 
@@ -951,7 +929,7 @@ In case _flowR_ encounters a function call that it cannot handle, it marks the c
 You can find these as part of the dataflow graph, specifically as \`unknownSideEffects\` (with a leading underscore if sesrialized as JSON).
 In the following graph, _flowR_ realizes that it is unable to correctly handle the impacts of the \`load\` call and therefore marks it as such (marked in bright red):
 
-${await (0, doc_dfg_1.printDfGraphForCode)(shell, 'load("file")\nprint(x + y)')}
+${await (0, doc_dfg_1.printDfGraphForCode)(treeSitter, 'load("file")\nprint(x + y)')}
 
 In general, as we cannot handle these correctly, we leave it up to other analyses (and [queries](${doc_files_1.FlowrWikiBaseRef}/Query%20API)) to handle these cases
 as they see fit.
@@ -963,27 +941,27 @@ Consider R's basic [\`graphics\`](https://www.rdocumentation.org/packages/graphi
 implicitly draws on the current device and does not explicitly link a function like \`points\` to the last call opening a new graphic device. In such a scenario, we use a linked side effect to mark the relation:
 
 ${await (async () => {
-            const [result, df] = await (0, doc_dfg_1.printDfGraphForCode)(shell, 'plot(data)\npoints(data2)', { exposeResult: true });
-            return `
+                const [result, df] = await (0, doc_dfg_1.printDfGraphForCode)(treeSitter, 'plot(data)\npoints(data2)', { exposeResult: true });
+                return `
 ${result}
 
 Such side effects are not marked explicitly (with a big edge) but they are part of the unknown side effects: [${[...df.dataflow.graph.unknownSideEffects].map(doc_dfg_1.formatSideEffect).join(',')}].
 Additionally, we express this by a ${linkEdgeName(edge_1.EdgeType.Reads)} edge.
 	`;
-        })()}
+            })()}
  
 ${(0, doc_structure_1.section)('Working with the Dataflow Graph', 2, 'dfg-working')}
 
-The ${(0, doc_types_1.shortLink)('DataflowInformation', vertexType.info)} is the core result of _flowR_ and summarizes a lot of information.
+The ${ctx.link('DataflowInformation')} is the core result of _flowR_ and summarizes a lot of information.
 Depending on what you are interested in, there exists a plethora of functions and queries to help you out, answering the most important questions:
 
 * The **[Query API](${doc_files_1.FlowrWikiBaseRef}/Query%20API)** provides many functions to query the dataflow graph for specific information (dependencies, calls, slices, clusters, ...)
 * The **[Search API](${doc_files_1.FlowrWikiBaseRef}/Search%20API)** allows you to search for specific vertices or edges in the dataflow graph or the original program
-* ${(0, doc_types_1.shortLink)(node_id_1.recoverName.name, vertexType.info)} and ${(0, doc_types_1.shortLink)(node_id_1.recoverContent.name, vertexType.info)} to get the name or content of a vertex in the dataflow graph
-* ${(0, doc_types_1.shortLink)(alias_tracking_1.resolveIdToValue.name, vertexType.info)} to resolve the value of a variable or id (if possible, see [below](#dfg-resolving-values))
-* ${(0, doc_types_1.shortLink)(edge_1.edgeIncludesType.name, vertexType.info)} to check if an edge includes a specific type and ${(0, doc_types_1.shortLink)(edge_1.splitEdgeTypes.name, vertexType.info)} to split the bitmask of edges into its types (see [below](#dfg-resolving-values))
-* ${(0, doc_types_1.shortLink)(identify_link_to_last_call_relation_1.getValueOfArgument.name, vertexType.info)} to get the (syntactical) value of an argument in a function call 
-* ${(0, doc_types_1.shortLink)(dfg_get_origin_1.getOriginInDfg.name, vertexType.info)} to get information about where a read, call, ... comes from (see [below](#dfg-resolving-values))
+* ${ctx.link(node_id_1.recoverName.name)} and ${ctx.link(node_id_1.recoverContent.name)} to get the name or content of a vertex in the dataflow graph
+* ${ctx.link(alias_tracking_1.resolveIdToValue.name)} to resolve the value of a variable or id (if possible, see [below](#dfg-resolving-values))
+* ${ctx.link(edge_1.edgeIncludesType.name)} to check if an edge includes a specific type and ${ctx.link(edge_1.splitEdgeTypes.name)} to split the bitmask of edges into its types (see [below](#dfg-resolving-values))
+* ${ctx.link(identify_link_to_last_call_relation_1.getValueOfArgument.name)} to get the (syntactical) value of an argument in a function call 
+* ${ctx.link(dfg_get_origin_1.getOriginInDfg.name)} to get information about where a read, call, ... comes from (see [below](#dfg-resolving-values))
 
 Some of these functions have been explained in their respective wiki pages. However, some are part of the [Dataflow Graph API](${doc_files_1.FlowrWikiBaseRef}/Dataflow-Graph) and so we explain them here.
 If you are interested in which features we support and which features are still to be worked on, please refer to our [capabilities](${doc_files_1.FlowrWikiBaseRef}/Capabilities) page.
@@ -993,12 +971,12 @@ ${(0, doc_structure_1.section)('Resolving Values', 3, 'dfg-resolving-values')}
 FlowR supports a [configurable](${doc_files_1.FlowrWikiBaseRef}/Interface#configuring-flowr) level of value tracking&mdash;all with the goal of knowing the static value domain of a variable.
 These capabilities are exposed by the [resolve value Query](${doc_files_1.FlowrWikiBaseRef}/Query-API#resolve-value-query) and backed by two important functions:
 
-${(0, doc_types_1.shortLink)(alias_tracking_1.resolveIdToValue.name, vertexType.info)} provides an environment-sensitive (see ${(0, doc_types_1.shortLink)('REnvironmentInformation', vertexType.info)})
+${ctx.link(alias_tracking_1.resolveIdToValue.name)} provides an environment-sensitive (see ${ctx.link('REnvironmentInformation')})
 value resolution depending on if the environment is provided.
-The idea of ${(0, doc_types_1.shortLink)(alias_tracking_1.resolveIdToValue.name, vertexType.info)} is to provide a compromise between precision and performance, to
+The idea of ${ctx.link(alias_tracking_1.resolveIdToValue.name)} is to provide a compromise between precision and performance, to
 be used _during_ and _after_ the core analysis. After the dataflow analysis completes, there are much more expensive queries possible (such as the resolution of the data frame shape, see the [Query API](${doc_files_1.FlowrWikiBaseRef}/Query-API)).
 
-Additionally, to ${(0, doc_types_1.shortLink)(alias_tracking_1.resolveIdToValue.name, vertexType.info)}, we offer the aforementioned ${(0, doc_types_1.shortLink)(identify_link_to_last_call_relation_1.getValueOfArgument.name, vertexType.info)} to retrieve the value of an argument in a function call.
+Additionally, to ${ctx.link(alias_tracking_1.resolveIdToValue.name)}, we offer the aforementioned ${ctx.link(identify_link_to_last_call_relation_1.getValueOfArgument.name)} to retrieve the value of an argument in a function call.
 Be aware, that this function is currently not optimized for speed, so if you frequently require the values of multiple arguments of the same function call, you may want to open [an issue](${doc_issue_1.NewIssueUrl}) to request support for resolving
 multiple arguments at once.
 
@@ -1008,54 +986,46 @@ The [edges](#edges) of the dataflow graph use bitmasks to represent an edge with
 difficult to check whether a given edge is a read edge. 
 Consider the following example:
 
-${await (0, doc_dfg_1.printDfGraphForCode)(shell, 'print(x)', { mark: new Set(['3->1']) })}
+${await (0, doc_dfg_1.printDfGraphForCode)(treeSitter, 'print(x)', { mark: new Set(['3->1']) })}
 
 Retrieving the _types_ of the edge from the print call to its argument returns:
 ${await (async () => {
-            const dfg = await (0, default_pipelines_1.createDataflowPipeline)(shell, {
-                request: (0, retriever_1.requestFromInput)('print(x)')
-            }, config_1.defaultConfigOptions).allRemainingSteps();
-            const edge = dfg.dataflow.graph.outgoingEdges(3);
-            if (edge) {
-                const wanted = edge.get(1);
-                if (wanted) {
-                    return '`' + wanted.types + '`';
+                const dfg = await (0, default_pipelines_1.createDataflowPipeline)(treeSitter, {
+                    context: (0, flowr_analyzer_context_1.contextFromInput)('print(x)')
+                }).allRemainingSteps();
+                const edge = dfg.dataflow.graph.outgoingEdges(3);
+                if (edge) {
+                    const wanted = edge.get(1);
+                    if (wanted) {
+                        return '`' + wanted.types + '`';
+                    }
                 }
-            }
-            new Error('Could not find edge');
-        })()}&mdash;which is usually not very helpful.
-You can use ${(0, doc_types_1.shortLink)(edge_1.splitEdgeTypes.name, vertexType.info)} to get the individual bitmasks of all included types, and 
-${(0, doc_types_1.shortLink)(edge_1.edgeIncludesType.name, vertexType.info)} to check whether a specific type (or one of a collection of types) is included in the edge.
+                new Error('Could not find edge');
+            })()}&mdash;which is usually not very helpful.
+You can use ${ctx.link(edge_1.splitEdgeTypes.name)} to get the individual bitmasks of all included types, and 
+${ctx.link(edge_1.edgeIncludesType.name)} to check whether a specific type (or one of a collection of types) is included in the edge.
 
 ${(0, doc_structure_1.section)('Handling Origins', 3, 'dfg-handling-origins')}
 
 If you are writing another analysis on top of the dataflow graph, you probably want to know all definitions that serve as the source of a read, all functions
 that are called by an invocation, and more.
-For this, the ${(0, doc_types_1.shortLink)(dfg_get_origin_1.getOriginInDfg.name, vertexType.info)} function provides you with a collection of ${(0, doc_types_1.shortLink)('Origin', vertexType.info)} objects:
+For this, the ${ctx.link(dfg_get_origin_1.getOriginInDfg)} function provides you with a collection of ${ctx.link('Origin')} objects:
 
-${(0, doc_types_1.printHierarchy)({ program: vertexType.program, info: vertexType.info, root: 'Origin', openTop: true })}
+${ctx.hierarchy('Origin', { openTop: true })}
 
 Their respective uses are documented alongside their implementation:
 
-${['SimpleOrigin', 'FunctionCallOrigin', 'BuiltInFunctionOrigin'].sort().map(key => `- ${(0, doc_types_1.shortLink)(key, vertexType.info)}\\\n${(0, doc_types_1.getDocumentationForType)(key, vertexType.info, '', { type: 'interface' })}`).join('\n')}
+${['SimpleOrigin', 'FunctionCallOrigin', 'BuiltInFunctionOrigin'].sort().map(key => `- ${ctx.link(key)}\\\n${ctx.doc(key, { type: 'interface' })}`).join('\n')}
 
 Please note, the current structure of this function is biased by what implementations already exist in flowR.
 Hence, we do not just track definitions and constants, but also the origins of function calls, albeit we do not yet track the origins of values (only resorting to
 a constant origin). If you are confused by this please start a discussion&mdash;in a way we are still deciding on a good API for this.
 
 	`;
-    })()}
+        })()}
 
 `;
+    }
 }
-/** if we run this script, we want a Markdown representation of the capabilities */
-if (require.main === module) {
-    (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-dataflow-graph-wiki.js.map
+exports.WikiDataflowGraph = WikiDataflowGraph;
+//# sourceMappingURL=wiki-dataflow-graph.js.map