@eagleoutice/flowr 2.6.2 → 2.6.3

package/documentation/wiki-engine.d.ts

@@ -0,0 +1,9 @@
+import type { DocMakerArgs } from './wiki-mk/doc-maker';
+import { DocMaker } from './wiki-mk/doc-maker';
+/**
+ * https://github.com/flowr-analysis/flowr/wiki/Engines
+ */
+export declare class WikiEngine extends DocMaker {
+    constructor();
+    text({ ctx }: DocMakerArgs): string;
+}

package/documentation/{print-engines-wiki.js → wiki-engine.js}

@@ -1,43 +1,38 @@
 "use strict";
-var __importDefault = (this && this.__importDefault) || function (mod) {
-    return (mod && mod.__esModule) ? mod : { "default": mod };
-};
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.WikiEngine = void 0;
 const shell_1 = require("../r-bridge/shell");
-const log_1 = require("../../test/functionality/_helper/log");
-const doc_auto_gen_1 = require("./doc-util/doc-auto-gen");
-const doc_types_1 = require("./doc-util/doc-types");
-const path_1 = __importDefault(require("path"));
 const shell_executor_1 = require("../r-bridge/shell-executor");
 const tree_sitter_executor_1 = require("../r-bridge/lang-4.x/tree-sitter/tree-sitter-executor");
 const doc_files_1 = require("./doc-util/doc-files");
 const doc_cli_option_1 = require("./doc-util/doc-cli-option");
 const doc_structure_1 = require("./doc-util/doc-structure");
-async function getText(shell) {
-    const rversion = (await shell.usedRVersion())?.format() ?? 'unknown';
-    const types = (0, doc_types_1.getTypesFromFolder)({
-        rootFolder: path_1.default.resolve('src/r-bridge/lang-4.x/tree-sitter/'),
-        files: [path_1.default.resolve('./src/config.ts'), path_1.default.resolve('./src/r-bridge/shell.ts'), path_1.default.resolve('./src/r-bridge/shell-executor.ts')],
-        inlineTypes: doc_types_1.mermaidHide
-    });
-    return `${(0, doc_auto_gen_1.autoGenHeader)({ filename: module.filename, purpose: 'engines', rVersion: rversion })}
-
+const doc_maker_1 = require("./wiki-mk/doc-maker");
+/**
+ * https://github.com/flowr-analysis/flowr/wiki/Engines
+ */
+class WikiEngine extends doc_maker_1.DocMaker {
+    constructor() {
+        super('wiki/Engines.md', module.filename, 'engines');
+    }
+    text({ ctx }) {
+        return `
 To analyze R scripts, flowR needs to parse the R code and for that, we require a parser.
-Originally, flowR shipped with an ${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info)}, an asynchronous interface to the R interpreter, still available today.
-Later we extended this with the ${(0, doc_types_1.shortLink)(shell_executor_1.RShellExecutor.name, types.info)}, the synchronous counterpart to the ${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info)}.
-However, these interfaces are relatively slow as they require communication with an underlying R interpreter. 
+Originally, flowR shipped with an ${ctx.link(shell_1.RShell)}, an asynchronous interface to the R interpreter, still available today.
+Later we extended this with the ${ctx.link(shell_executor_1.RShellExecutor)}, the synchronous counterpart to the ${ctx.link(shell_1.RShell)}.
+However, these interfaces are relatively slow as they require communication with an underlying R interpreter.
 Using [tree-sitter](https://tree-sitter.github.io/tree-sitter/), with its [node bindings](https://github.com/tree-sitter/node-tree-sitter)
-and [R grammar](https://github.com/r-lib/tree-sitter-r), we can provide the ${(0, doc_types_1.shortLink)(tree_sitter_executor_1.TreeSitterExecutor.name, types.info)} which
+and [R grammar](https://github.com/r-lib/tree-sitter-r), we can provide the ${ctx.link(tree_sitter_executor_1.TreeSitterExecutor)} which
 is synchronous, faster, and no longer needs an R installation, but requires the appropriate bindings.
 To allow users of R to freely choose their backend between the R interpreter and the tree-sitter parser,
-we provide the concept of engines. 
+we provide the concept of engines.
 
 Engines can be loaded with [flowR's configuration file](${doc_files_1.FlowrWikiBaseRef}/Interface#configuring-flowr). Additionally, they
 are exposed with some command line options (e.g., when using the docker image of flowR):
 
-- ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'engine.r-shell.disabled', false)} to disable the ${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info)} engine
+- ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'engine.r-shell.disabled', false)} to disable the ${ctx.link(shell_1.RShell)} engine
 - ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'engine.r-shell.r-path', false)} (which is the canonical version of ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'r-path')})
-- ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'engine.tree-sitter.disabled', false)} to disable the ${(0, doc_types_1.shortLink)(tree_sitter_executor_1.TreeSitterExecutor.name, types.info)} engine
+- ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'engine.tree-sitter.disabled', false)} to disable the ${ctx.link(tree_sitter_executor_1.TreeSitterExecutor)} engine
 - ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'engine.tree-sitter.lax', false)} to use lax parsing with tree-sitter
 - ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'engine.tree-sitter.wasm-path', false)} pass the path to the wasm of the r grammar of tree-sitter (see [below](#tree-sitter))
 - ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'engine.tree-sitter.tree-sitter-wasm-path', false)} pass the path to the wasm of tree-sitter (see [below](#tree-sitter))
@@ -47,36 +42,26 @@ are exposed with some command line options (e.g., when using the docker image of
 ## Dealing with the Tree-Sitter Engine
 
 ${(0, doc_structure_1.block)({
-        type: 'WARNING',
-        content: 'As the tree-sitter engine is only for parsing, it cannot execute R code. This engine is now the default.'
-    })}
+            type: 'WARNING',
+            content: 'As the tree-sitter engine is only for parsing, it cannot execute R code. This engine is now the default.'
+        })}
 
-In general, there is no need for you to pass custom paths using either 
+In general, there is no need for you to pass custom paths using either
 ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'engine.tree-sitter.wasm-path', false)} or
 ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'engine.tree-sitter.tree-sitter-wasm-path', false)}.
 However, you may want to experiment with the R grammar or provide a newer
-one in case that of _flowR_ is outdated. 
+one in case that of _flowR_ is outdated.
 
 To use a newer [R grammar](https://github.com/r-lib/tree-sitter-r),
 you first must build the new wasm file. For this you have to:
 
 1. Install the dependencies with \`npm ci\` in the tree-sitter-r repository.
-2. Build the wasm using \`tree-sitter build --wasm .\` the [tree sitter cli](https://github.com/tree-sitter/tree-sitter)
-   which should be a dev dependency.
+2. Build the wasm using \`tree-sitter build --wasm .\` the [tree sitter cli](https://github.com/tree-sitter/tree-sitter) which should be a dev dependency.
 3. Pass the \`tree-sitter-r.wasm\` to flowR. 
 
 For tree-sitter, please rely on the [releases](https://github.com/tree-sitter/tree-sitter/releases).
-
 `;
+    }
 }
-/** 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-engines-wiki.js.map
+exports.WikiEngine = WikiEngine;
+//# sourceMappingURL=wiki-engine.js.map

package/documentation/wiki-faq.d.ts

@@ -0,0 +1,8 @@
+import { DocMaker } from './wiki-mk/doc-maker';
+/**
+ * https://github.com/flowr-analysis/flowr/wiki/FAQ
+ */
+export declare class WikiFaq extends DocMaker {
+    constructor();
+    text(): string;
+}

package/documentation/wiki-faq.js

@@ -0,0 +1,22 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.WikiFaq = void 0;
+const faqs_1 = require("./data/faq/faqs");
+const doc_maker_1 = require("./wiki-mk/doc-maker");
+/**
+ * https://github.com/flowr-analysis/flowr/wiki/FAQ
+ */
+class WikiFaq extends doc_maker_1.DocMaker {
+    constructor() {
+        super('wiki/FAQ.md', module.filename, 'frequently asked questions');
+    }
+    text() {
+        const faqs = (0, faqs_1.registerFaqs)();
+        return `
+	${faqs.toMarkdown()}
+
+    `.trim();
+    }
+}
+exports.WikiFaq = WikiFaq;
+//# sourceMappingURL=wiki-faq.js.map

package/documentation/wiki-interface.d.ts

@@ -0,0 +1,9 @@
+import type { DocMakerArgs } from './wiki-mk/doc-maker';
+import { DocMaker } from './wiki-mk/doc-maker';
+/**
+ * https://github.com/flowr-analysis/flowr/wiki/Interface
+ */
+export declare class WikiInterface extends DocMaker {
+    constructor();
+    protected text({ shell, ctx, treeSitter }: DocMakerArgs): Promise<string>;
+}

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

@@ -1,12 +1,8 @@
 "use strict";
-var __importDefault = (this && this.__importDefault) || function (mod) {
-    return (mod && mod.__esModule) ? mod : { "default": mod };
-};
 Object.defineProperty(exports, "__esModule", { value: true });
+exports.WikiInterface = void 0;
 const shell_1 = require("../r-bridge/shell");
-const log_1 = require("../../test/functionality/_helper/log");
 const doc_files_1 = require("./doc-util/doc-files");
-const doc_auto_gen_1 = require("./doc-util/doc-auto-gen");
 const doc_cli_option_1 = require("./doc-util/doc-cli-option");
 const doc_server_message_1 = require("./doc-util/doc-server-message");
 const doc_data_server_messages_1 = require("./data/server/doc-data-server-messages");
@@ -22,11 +18,10 @@ const flowr_main_options_1 = require("../cli/flowr-main-options");
 const doc_issue_1 = require("./doc-util/doc-issue");
 const pipeline_executor_1 = require("../core/pipeline-executor");
 const doc_structure_1 = require("./doc-util/doc-structure");
-const doc_types_1 = require("./doc-util/doc-types");
-const path_1 = __importDefault(require("path"));
 const tree_sitter_executor_1 = require("../r-bridge/lang-4.x/tree-sitter/tree-sitter-executor");
 const flowr_analyzer_1 = require("../project/flowr-analyzer");
-async function explainServer(shell) {
+const doc_maker_1 = require("./wiki-mk/doc-maker");
+async function explainServer(parser) {
     (0, doc_data_server_messages_1.documentAllServerMessages)();
     return `
 As explained in the [Overview](${doc_files_1.FlowrWikiBaseRef}/Overview), you can simply run the [TCP](https://de.wikipedia.org/wiki/Transmission_Control_Protocol)&nbsp;server by adding the ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'server', true)} flag (and, due to the interactive mode, exit with the conventional <kbd>CTRL</kbd>+<kbd>C</kbd>).
@@ -43,7 +38,7 @@ connection. If you want _flowR_ to expose a [WebSocket](https://de.wikipedia.org
 			`
     })}
 
-${await (0, doc_server_message_1.printServerMessages)(shell)}
+${await (0, doc_server_message_1.printServerMessages)(parser)}
 
 ### 📡 Ways of Connecting
 
@@ -99,23 +94,26 @@ with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
 
 `;
 }
-async function explainRepl(shell) {
+async function explainRepl(parser) {
     return `
 > [!NOTE]
 > To execute arbitrary R commands with a repl request, _flowR_ has to be started explicitly with ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'r-session-access')}.
 > Please be aware that this introduces a security risk and note that this relies on the [\`r-shell\` engine](${doc_files_1.FlowrWikiBaseRef}/Engines).
 
-
 Although primarily meant for users to explore, 
 there is nothing which forbids simply calling _flowR_ as a subprocess to use standard-in, -output, and -error 
 for communication (although you can access the REPL using the server as well, 
 with the [REPL Request](#message-request-repl-execution) message).
 
 The read-eval-print loop&nbsp;(REPL) works relatively simple.
-You can submit an expression (using enter),
+You can submit an expression (using <kbd>Enter</kbd>),
 which is interpreted as an R&nbsp;expression by default but interpreted as a *command* if it starts with a colon (\`:\`).
 The best command to get started with the REPL is ${(0, doc_cli_option_1.getReplCommand)('help')}.
-Besides, you can leave the REPL either with the command ${(0, doc_cli_option_1.getReplCommand)('quit')} or by pressing <kbd>CTRL</kbd>+<kbd>C</kbd> twice.
+Besides, you can leave the REPL either with the command ${(0, doc_cli_option_1.getReplCommand)('quit')} or by pressing <kbd>Ctrl</kbd>+<kbd>C</kbd> twice.
+When writing a *command*, you may press <kbd>Tab</kbd> to get a list of completions, if available.
+Multiple commands can be entered in a single line by separating them with a semicolon (\`;\`), e.g. \`:parse "x<-2"; :df*\`.
+If a command is given without R code, the REPL will re-use R code given in a previous command. 
+The prior example will hence return first the parsed AST of the program and then the dataflow graph for \`"x <- 2"\`.
 
 > [!NOTE]
 > If you develop flowR, you may want to launch the repl using the \`npm run main-dev\` command, this way, you get a non-minified version of flowR with debug information and hot-reloading of source files.
@@ -129,15 +127,26 @@ ${(0, doc_repl_1.printReplHelpAsMarkdownTable)()}
 
 </details>
 
+${(0, doc_structure_1.block)({
+        type: 'TIP',
+        content: `
+As indicated by the examples before, all REPL commands that operate on code keep track of the state.
+Hence, if you run a command like ${(0, doc_cli_option_1.getReplCommand)('dataflow*')} without providing R code,
+the REPL will re-use the R code provided in a previous command.
+Likewise, doing this will benefit from incrementality!
+If you request the dataflow graph with \`:df* x <- 2 * y\` and then want to see the parsed AST with \`:parse\`,
+the REPL will re-use previously obtained information and not re-parse the code again.
+		`
+    })}
 
 ### Example: Retrieving the Dataflow Graph
 
 To retrieve a URL to the [mermaid](https://mermaid.js.org/) diagram of the dataflow of a given expression, 
 use ${(0, doc_cli_option_1.getReplCommand)('dataflow*')} (or ${(0, doc_cli_option_1.getReplCommand)('dataflow')} to get the mermaid code in the cli):
 
-${await (0, doc_repl_1.documentReplSession)(shell, [{
+${await (0, doc_repl_1.documentReplSession)(parser, [{
             command: ':dataflow* y <- 1 + x',
-            description: `Retrieve the dataflow graph of the expression \`y <- 1 + x\`. It looks like this:\n${await (0, doc_dfg_1.printDfGraphForCode)(shell, 'y <- 1 + x')}`
+            description: `Retrieve the dataflow graph of the expression \`y <- 1 + x\`. It looks like this:\n${await (0, doc_dfg_1.printDfGraphForCode)(parser, 'y <- 1 + x')}`
         }])}
 
 For the slicing with ${(0, doc_cli_option_1.getReplCommand)('slicer')}, you have access to the same [magic comments](#slice-magic-comments) as with the [slice request](#message-request-slice).
@@ -148,7 +157,7 @@ Many commands that allow for an R-expression (like ${(0, doc_cli_option_1.getRep
 if the argument starts with \`${retriever_1.fileProtocol}\`. 
 If you are working from the root directory of the _flowR_ repository, the following gives you the parsed AST of the example file using the ${(0, doc_cli_option_1.getReplCommand)('parse')} command:
 
-${await (0, doc_repl_1.documentReplSession)(shell, [{
+${await (0, doc_repl_1.documentReplSession)(parser, [{
             command: `:parse ${retriever_1.fileProtocol}test/testfiles/example.R`,
             description: `Retrieve the parsed AST of the example file.
 
@@ -204,6 +213,9 @@ ${(0, doc_code_1.codeBlock)('json', JSON.stringify({
                 }
             }
         },
+        project: {
+            resolveUnknownPathsOnDisk: true
+        },
         engines: [{ type: 'r-shell' }],
         solver: {
             variables: config_1.VariableResolve.Alias,
@@ -262,43 +274,38 @@ ${(0, schema_1.describeSchema)(config_1.flowrConfigFileSchema, ansi_1.markdownFo
 
 	`;
 }
-function explainWritingCode(shell) {
-    const types = (0, doc_types_1.getTypesFromFolder)({
-        rootFolder: path_1.default.resolve('./src/'),
-        files: [path_1.default.resolve('./src/core/pipeline-executor.ts'), path_1.default.resolve('./src/core/steps/pipeline/default-pipelines.ts')],
-        inlineTypes: doc_types_1.mermaidHide
-    });
+function explainWritingCode(shell, ctx) {
     return `
 _flowR_ can be used as a [module](${doc_files_1.FlowrNpmRef}) and offers several main classes and interfaces that are interesting for extension writers 
 (see the [Visual Studio Code extension](${doc_files_1.FlowrGithubBaseRef}/vscode-flowr) or the [core](${doc_files_1.FlowrWikiBaseRef}/Core) wiki page for more information).
 
-### Using the ${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info)} to Interact with R
+### Using the ${ctx.link(shell_1.RShell)} to Interact with R
 
-The ${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info)} class allows interfacing with the \`R\`&nbsp;ecosystem installed on the host system.
-Please have a look at [flowR's engines](${doc_files_1.FlowrWikiBaseRef}/Engines) for more information on alterantives (for example, the ${(0, doc_types_1.shortLink)(tree_sitter_executor_1.TreeSitterExecutor.name, types.info)}).
+The ${ctx.link(shell_1.RShell.name)} class allows interfacing with the \`R\`&nbsp;ecosystem installed on the host system.
+Please have a look at [flowR's engines](${doc_files_1.FlowrWikiBaseRef}/Engines) for more information on alterantives (for example, the ${ctx.link(tree_sitter_executor_1.TreeSitterExecutor)}).
 
 ${(0, doc_structure_1.block)({
         type: 'IMPORTANT',
         content: `
-Each ${(0, doc_types_1.shortLink)(shell_1.RShell.name, types.info)} controls a new instance of the R&nbsp;interpreter, 
-make sure to call ${(0, doc_code_1.codeInline)((0, doc_types_1.shortLink)(shell_1.RShell.name + '::' + shell.close.name, types.info, false, 'i') + '()')} when you are done.`
+Each ${ctx.link(shell_1.RShell.name)} controls a new instance of the R&nbsp;interpreter, 
+make sure to call ${(0, doc_code_1.codeInline)(ctx.linkM(shell_1.RShell, 'close', { codeFont: false, realNameWrapper: 'i' }) + '()')} when you are done.`
     })}
 
-You can start a new "session" simply by constructing a new object with ${(0, doc_code_1.codeInline)('new ' + (0, doc_types_1.shortLink)(shell_1.RShell.name, types.info, false) + '()')}.
+You can start a new "session" simply by constructing a new object with ${(0, doc_code_1.codeInline)('new ' + ctx.link(shell_1.RShell, { codeFont: false }) + '()')}.
 
 However, there are several options that may be of interest 
 (e.g., to automatically revive the shell in case of errors or to control the name location of the R process on the system).
 
-With a shell object (let's call it \`shell\`), you can execute R code by using ${(0, doc_types_1.shortLink)(shell_1.RShell.name + '::' + shell.sendCommand.name, types.info, true, 'i')}, 
-for example ${(0, doc_code_1.codeInline)('shell.' + (0, doc_types_1.shortLink)(shell_1.RShell.name + ':::' + shell.sendCommand.name, types.info, false) + '("1 + 1")')}. 
+With a shell object (let's call it \`shell\`), you can execute R code by using ${ctx.linkM(shell_1.RShell, 'sendCommand', { realNameWrapper: 'i' })}, 
+for example ${(0, doc_code_1.codeInline)('shell.' + ctx.linkM(shell_1.RShell, 'sendCommand', { codeFont: false, hideClass: true }) + '("1 + 1")')}. 
 However, this does not return anything, so if you want to collect the output of your command, use
-${(0, doc_types_1.shortLink)(shell_1.RShell.name + '::' + shell.sendCommandWithOutput.name, types.info, true, 'i')} instead.
+${ctx.linkM(shell_1.RShell, 'sendCommandWithOutput', { realNameWrapper: 'i' })} instead.
 
-Besides that, the command ${(0, doc_types_1.shortLink)(shell_1.RShell.name + '::' + shell.tryToInjectHomeLibPath.name, types.info)} may be of interest, as it enables all libraries available on the host system.
+Besides that, the command ${ctx.linkM(shell_1.RShell, 'tryToInjectHomeLibPath')} may be of interest, as it enables all libraries available on the host system.
 
 ### Creating _flowR_ analyses
 
-Nowadays, instances of ${(0, doc_types_1.shortLink)(flowr_analyzer_1.FlowrAnalyzer.name, types.info)} should be used as central frontend to get analysis results from _flowR_.
+Nowadays, instances of ${ctx.link(flowr_analyzer_1.FlowrAnalyzer)} should be used as central frontend to get analysis results from _flowR_.
 For example, a program slice can be created like this:
 
 ${(0, doc_code_1.codeBlock)('ts', `
@@ -315,10 +322,10 @@ const result = await analyzer.query([
 ### The Pipeline Executor
 
 Once, in the beginning, _flowR_ was meant to produce a dataflow graph merely to provide *program slices*. 
-However, with continuous updates, the [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow%20Graph) repeatedly proves to be the more interesting part.
+However, with continuous updates, the [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow-Graph) repeatedly proves to be the more interesting part.
 With this, we restructured _flowR_'s originally *hardcoded* pipeline to be far more flexible. 
 Now, it can be theoretically extended or replaced with arbitrary steps, optional steps, and what we call 'decorations' of these steps. 
-In short, a slicing pipeline using the ${(0, doc_types_1.shortLink)(pipeline_executor_1.PipelineExecutor.name, types.info)} looks like this:
+In short, a slicing pipeline using the ${ctx.link(pipeline_executor_1.PipelineExecutor)} looks like this:
 
 ${(0, doc_code_1.codeBlock)('ts', `
 const slicer = new ${pipeline_executor_1.PipelineExecutor.name}(DEFAULT_SLICING_PIPELINE, {
@@ -333,9 +340,9 @@ const slice = await slicer.allRemainingSteps()
 ${(0, doc_structure_1.details)('More Information', `
 
 If you compare this, with what you would have done with the old (and removed) \`SteppingSlicer\`, 
-this essentially just requires you to replace the \`SteppingSlicer\` with the ${(0, doc_types_1.shortLink)(pipeline_executor_1.PipelineExecutor.name, types.info)}
-and to pass the ${(0, doc_types_1.shortLink)('DEFAULT_SLICING_PIPELINE', types.info)} as the first argument.
-The ${(0, doc_types_1.shortLink)(pipeline_executor_1.PipelineExecutor.name, types.info)}...
+this essentially just requires you to replace the \`SteppingSlicer\` with the ${ctx.link(pipeline_executor_1.PipelineExecutor)}
+and to pass the ${ctx.link('DEFAULT_SLICING_PIPELINE')} as the first argument.
+The ${ctx.link(pipeline_executor_1.PipelineExecutor)}...
 
 1. Provides structures to investigate the results of all intermediate steps
 2. Can be executed step-by-step
@@ -420,10 +427,15 @@ We use \`example.name\` to avoid duplication with the name that we’ve assigned
 </details>
 	`;
 }
-async function getText(shell) {
-    const rversion = (await shell.usedRVersion())?.format() ?? 'unknown';
-    return `${(0, doc_auto_gen_1.autoGenHeader)({ filename: module.filename, purpose: 'interfaces', rVersion: rversion })}
-
+/**
+ * https://github.com/flowr-analysis/flowr/wiki/Interface
+ */
+class WikiInterface extends doc_maker_1.DocMaker {
+    constructor() {
+        super('wiki/Interface.md', module.filename, 'interface');
+    }
+    async text({ shell, ctx, treeSitter }) {
+        return `
 Although far from being as detailed as the in-depth explanation of
 [_flowR_](${doc_files_1.FlowrWikiBaseRef}/Core),
 this wiki page explains how to interface with _flowR_ in more detail.
@@ -442,7 +454,7 @@ ${await explainServer(shell)}
 <a id='using-the-repl'></a>
 ## 💻 Using the REPL
 
-${await explainRepl(shell)}
+${await explainRepl(treeSitter)}
 
 <a id='configuring-flowr'></a>
 ## ⚙️ Configuring FlowR
@@ -452,18 +464,9 @@ ${explainConfigFile()}
 <a id='writing-code'></a>
 ## ⚒️ Writing Code
 
-${explainWritingCode(shell)}
-
+${explainWritingCode(shell, ctx)}
 `;
+    }
 }
-/** 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-interface-wiki.js.map
+exports.WikiInterface = WikiInterface;
+//# sourceMappingURL=wiki-interface.js.map

package/documentation/wiki-linter.d.ts

@@ -0,0 +1,9 @@
+import type { DocMakerArgs } from './wiki-mk/doc-maker';
+import { DocMaker } from './wiki-mk/doc-maker';
+/**
+ * https://github.com/flowr-analysis/flowr/wiki/Linter
+ */
+export declare class WikiLinter extends DocMaker {
+    constructor();
+    protected text({ treeSitter }: DocMakerArgs): Promise<string>;
+}