@eagleoutice/flowr 2.10.4 → 2.10.5

package/documentation/wiki-absint.js

@@ -3,8 +3,10 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.WikiAbsint = void 0;
 const absint_visitor_1 = require("../abstract-interpretation/absint-visitor");
 const abstract_domain_1 = require("../abstract-interpretation/domains/abstract-domain");
+const bounded_set_domain_1 = require("../abstract-interpretation/domains/bounded-set-domain");
 const interval_domain_1 = require("../abstract-interpretation/domains/interval-domain");
 const lattice_1 = require("../abstract-interpretation/domains/lattice");
+const multi_value_state_domain_1 = require("../abstract-interpretation/domains/multi-value-state-domain");
 const state_abstract_domain_1 = require("../abstract-interpretation/domains/state-abstract-domain");
 const semantic_cfg_guided_visitor_1 = require("../control-flow/semantic-cfg-guided-visitor");
 const identifier_1 = require("../dataflow/environments/identifier");
@@ -15,10 +17,13 @@ const doc_code_1 = require("./doc-util/doc-code");
 const doc_structure_1 = require("./doc-util/doc-structure");
 const doc_maker_1 = require("./wiki-mk/doc-maker");
 class IntervalInferenceVisitor extends absint_visitor_1.AbstractInterpretationVisitor {
+    constructor(config) {
+        super(config, state_abstract_domain_1.StateAbstractDomain.top(interval_domain_1.IntervalDomain.top()));
+    }
     onNumberConstant({ vertex, node }) {
         super.onNumberConstant({ vertex, node });
         const interval = new interval_domain_1.IntervalDomain([node.content.num, node.content.num]);
-        this.updateState(node.info.id, interval);
+        this.currentState.set(node.info.id, interval);
     }
     onFunctionCall({ call }) {
         super.onFunctionCall({ call });
@@ -32,9 +37,9 @@ class IntervalInferenceVisitor extends absint_visitor_1.AbstractInterpretationVi
             // We map the numerical operation to the resulting interval after applying the abstract semantics of the operation
             switch (identifier_1.Identifier.getName(call.name)) {
                 case '+':
-                    return this.updateState(call.id, left.add(right));
+                    return this.currentState.set(call.id, left.add(right));
                 case '-':
-                    return this.updateState(call.id, left.subtract(right));
+                    return this.currentState.set(call.id, left.subtract(right));
             }
         }
     }
@@ -52,7 +57,7 @@ async function inferIntervals() {
     const dfg = (await analyzer.dataflow()).graph;
     const cfg = await analyzer.controlflow(undefined, cfg_kind_1.CfgKind.NoFunctionDefs);
     const ctx = analyzer.inspectContext();
-    const inference = new IntervalInferenceVisitor({ controlFlow: cfg, dfg: dfg, normalizedAst: ast, ctx: ctx }, interval_domain_1.IntervalDomain.top());
+    const inference = new IntervalInferenceVisitor({ controlFlow: cfg, dfg: dfg, normalizedAst: ast, ctx: ctx });
     inference.start();
     const result = inference.getEndState();
     return result.isValue() ? result.value.entries().toArray()
@@ -63,6 +68,21 @@ function nodeIdToSlicingCriterion(id, idMap) {
     const node = idMap.get(id);
     return `${node?.location?.[0]}@${node?.lexeme}`;
 }
+function multiValueExample() {
+    const domain = {
+        number: new interval_domain_1.IntervalDomain(interval_domain_1.IntervalTop),
+        string: new bounded_set_domain_1.BoundedSetDomain(lattice_1.Top)
+    };
+    const reduction = ({ number, string }) => {
+        if (number?.isBottom() || string?.isBottom()) {
+            return { number: domain.number.bottom(), string: domain.string.bottom() };
+        }
+        return { number, string };
+    };
+    const state = new multi_value_state_domain_1.MultiValueStateDomain(new Map(), domain, [reduction]);
+    state.setValue(0, 'number', new interval_domain_1.IntervalDomain([42, 42]));
+    state.setValue(1, 'string', new bounded_set_domain_1.BoundedSetDomain(new Set(['Hello world!'])));
+}
 class WikiAbsint extends doc_maker_1.DocMaker {
     constructor() {
         super('wiki/Abstract Interpretation.md', module.filename, 'abstract interpretation framework');
@@ -113,30 +133,34 @@ All boxes link to their respective implementation in the source code.
 ${(0, doc_code_1.codeBlock)('mermaid', ctx.mermaid(abstract_domain_1.AbstractDomain, { simplify: true, reverse: true }))}
 `.trim())}
 
+Multiple abstract domains can be combined using a ${ctx.link(multi_value_state_domain_1.MultiValueDomain)} (for example, to use an interval domain for numbers and bounded set domain for strings at the same time). A multi-value state domain (${ctx.link(multi_value_state_domain_1.MultiValueStateDomain)}) as state domain of a multi-value domain can be used to track the state of multiple value domains in a program. Additionally, is enables to define reductions on the multi-value domain to refine the inferred value for a value domain based on the other value domains in the multi-value domain. For example, the following example shows how a multi-value state domain can be defined to track numbers and strings at the same time with a simple reduction that sets both domains to bottom if one domain is bottom.
+
+${ctx.code(multiValueExample, { dropLinesStart: 1, dropLinesEnd: 1 })}
+
 ${(0, doc_structure_1.section)('Abstract Interpretation', 2, 'abstract-interpretation')}
 
 We perform abstract interpretation by forward-traversing the ${ctx.linkPage('wiki/Control Flow Graph', 'control flow graph')} of _flowR_ using an ${ctx.link(absint_visitor_1.AbstractInterpretationVisitor)}. For each visited control flow vertex, the visitor retrieves the current abstract state by joining the abstract states of the predecessors, applies the abstract semantics of the visited control flow vertex to the current state, and updates the abstract state of the currently visited vertex to the current state. The visitor already handles assignments and (delayed) widening at widening points. However, the visitor does not yet support interprocedural abstract interpretation.
 
-To implement a custom abstract interpretation analysis, we can just create a new class and extend the ${ctx.link(absint_visitor_1.AbstractInterpretationVisitor)}. The abstract interpretation visitor uses a ${ctx.link(state_abstract_domain_1.StateAbstractDomain)} to capture the current abstract state at each vertex in the control flow graph. Hence, the abstract interpretation visitor requires a value abstract domain \`Domain\` as type parameter to specify the state abstract domain. We can then extend the callback functions of the ${ctx.link(absint_visitor_1.AbstractInterpretationVisitor)} to implement the abstract semantics of expressions, such as ${ctx.link(`${semantic_cfg_guided_visitor_1.SemanticCfgGuidedVisitor.name}:::onNumberConstant`)}, ${ctx.link(`${absint_visitor_1.AbstractInterpretationVisitor.name}:::onFunctionCall`)}, and ${ctx.link(`${semantic_cfg_guided_visitor_1.SemanticCfgGuidedVisitor.name}:::onReplacementCall`)} (make sure to still call the respective super function). The abstract interpretation visitor provides the following functions to retrieve the currently inferred values:
+To implement a custom abstract interpretation analysis, we can just create a new class and extend the ${ctx.link(absint_visitor_1.AbstractInterpretationVisitor)}. The abstract interpretation visitor uses a \`StateDomain\` (e.g., a ${ctx.link(state_abstract_domain_1.StateAbstractDomain)}) to capture the current abstract state at each vertex in the control flow graph. We can then extend the callback functions of the ${ctx.link(absint_visitor_1.AbstractInterpretationVisitor)} to implement the abstract semantics of expressions, such as ${ctx.link(`${semantic_cfg_guided_visitor_1.SemanticCfgGuidedVisitor.name}:::onNumberConstant`)}, ${ctx.link(`${absint_visitor_1.AbstractInterpretationVisitor.name}:::onFunctionCall`)} and ${ctx.link(`${semantic_cfg_guided_visitor_1.SemanticCfgGuidedVisitor.name}:::onReplacementCall`)} (make sure to still call the respective super function). The abstract interpretation visitor provides the following functions to retrieve the currently inferred values:
 
  * ${ctx.linkM(absint_visitor_1.AbstractInterpretationVisitor, 'getAbstractValue')} to resolve the inferred abstract value for an AST node (this includes resolving symbols, pipes, and if expressions)
  * ${ctx.linkM(absint_visitor_1.AbstractInterpretationVisitor, 'getAbstractState')} to get the inferred abstract state at an AST node mapping AST nodes to abstract values
  * ${ctx.linkM(absint_visitor_1.AbstractInterpretationVisitor, 'getAbstractTrace')} to get the complete abstract trace mapping AST nodes to abstract states at the respective node
  * ${ctx.linkM(absint_visitor_1.AbstractInterpretationVisitor, 'getEndState')} to get the inferred abstract state at the end of the program (at the exit points of the control flow graph)
 
-For example, if we want to perform a (very basic) interval analysis using abstract interpretation in _flowR_, we can implement the following ${ctx.link(IntervalInferenceVisitor)} that extends ${ctx.link(absint_visitor_1.AbstractInterpretationVisitor)} using the ${ctx.link(interval_domain_1.IntervalDomain)}:
+For example, if we want to perform a (very basic) interval analysis using abstract interpretation in _flowR_, we can implement the following ${ctx.link(IntervalInferenceVisitor)} that extends ${ctx.link(absint_visitor_1.AbstractInterpretationVisitor)} using a ${ctx.link(state_abstract_domain_1.StateAbstractDomain)} for the ${ctx.link(interval_domain_1.IntervalDomain)}:
 
-${ctx.code(IntervalInferenceVisitor)}
+${ctx.code(inferIntervals, { dropLinesStart: 1, dropLinesEnd: 5 })}
 
-The interval inference visitor first overrides the ${ctx.link(`${semantic_cfg_guided_visitor_1.SemanticCfgGuidedVisitor.name}:::onNumberConstant`)} function to infer intervals for visited control flow vertices that represent numeric constants. For numeric constants, the resulting interval consists just of the number value of the constant. We then update the current abstract state of the visitor via ${ctx.linkM(absint_visitor_1.AbstractInterpretationVisitor, 'updateState', { hideClass: true })} by setting the inferred abstract value of the currently visited control flow vertex to the new interval.
+The interval inference visitor first overrides the ${ctx.link(`${semantic_cfg_guided_visitor_1.SemanticCfgGuidedVisitor.name}:::onNumberConstant`)} function to infer intervals for visited control flow vertices that represent numeric constants. For numeric constants, the resulting interval consists just of the number value of the constant. We then update the current abstract state of the visitor by setting the inferred abstract value of the currently visited control flow vertex to the new interval.
 
-In this simple example, we only want to support the addition and subtraction of numeric values. Therefore, we override the ${ctx.link(`${absint_visitor_1.AbstractInterpretationVisitor.name}:::onFunctionCall`)} function to apply the abstract semantics of additions and subtraction with resprect to the interval domain. For the addition and subtraction, we are only interested in function calls with exactly two non-empty arguments. We first resolve the currently inferred abstract value for the left and right operand of the function call. If we have no inferred value for one of the operands, this function call might not be a numeric function call and we ignore it. Otherwise, we check whether the function call represents an addition or subtraction and apply the abstract semantics of the operation to the left and right operand. We then again update the current abstract state of the visitor via ${ctx.linkM(absint_visitor_1.AbstractInterpretationVisitor, 'updateState', { hideClass: true })} by setting the inferred abstract value of the currently visited function call vertex to the abstract value resulting from applying the abstract semantics of the operation to the operands.
+In this simple example, we only want to support the addition and subtraction of numeric values. Therefore, we override the ${ctx.link(`${absint_visitor_1.AbstractInterpretationVisitor.name}:::onFunctionCall`)} function to apply the abstract semantics of additions and subtraction with resprect to the interval domain. For the addition and subtraction, we are only interested in function calls with exactly two non-empty arguments. We first resolve the currently inferred abstract value for the left and right operand of the function call. If we have not inferred a value for one of the operands, this function call might not be a numeric function call and we ignore it. Otherwise, we check whether the function call represents an addition or subtraction and apply the abstract semantics of the operation to the left and right operand. We then again update the current abstract state of the visitor by setting the inferred abstract value of the currently visited function call vertex to the abstract value resulting from applying the abstract semantics of the operation to the operands.
 
 If we now want to run the interval inference, we can write the following code:
 
 ${ctx.code(inferIntervals, { dropLinesStart: 1, dropLinesEnd: 5 })}
 
-We first need a ${ctx.linkPage('wiki/Analyzer', 'flowR analyzer')} (in this case, using the ${ctx.linkPage('wiki/Engines', 'tree-sitter engine')}). In this example, we want to analyze a small example code that assigns \`42\` to the variable \`x\`, randomly assigns \`6\` or \`12\` to the variable \`y\`, and assignes the sum of \`x\` and \`y\` to the variable \`z\`. For the abstract interpretation visitor, we need to retrieve the ${ctx.linkPage('wiki/Normalized AST', 'normalized AST')}, ${ctx.linkPage('wiki/Dataflow Graph', 'dataflow graph')}, ${ctx.linkPage('wiki/Control Flow Graph', 'control flow graph')}, context of the flowR anaylzer, and provide a value domain for the state domain. For performance reasons, we construct the control flow graph without simplification passes, data flow information, and function definitions. We then create a new ${ctx.link(IntervalInferenceVisitor)} using the control flow graph, dataflow graph, normalized AST, and analyzer context, and start the visitor using ${ctx.linkM(absint_visitor_1.AbstractInterpretationVisitor, 'start', { hideClass: true })}. After the visitor is finished, we retrieve the inferred abstract state at the end of the program using ${ctx.linkM(absint_visitor_1.AbstractInterpretationVisitor, 'getEndState', { hideClass: true })}.
+We first need a ${ctx.linkPage('wiki/Analyzer', 'flowR analyzer')} (in this case, using the ${ctx.linkPage('wiki/Engines', 'tree-sitter engine')}). In this example, we want to analyze a small example code that assigns \`42\` to the variable \`x\`, randomly assigns \`6\` or \`12\` to the variable \`y\`, and assignes the sum of \`x\` and \`y\` to the variable \`z\`. For the abstract interpretation visitor, we need to retrieve the ${ctx.linkPage('wiki/Normalized AST', 'normalized AST')}, ${ctx.linkPage('wiki/Dataflow Graph', 'dataflow graph')}, ${ctx.linkPage('wiki/Control Flow Graph', 'control flow graph')}, and context of the flowR anaylzer. For performance reasons, we construct the control flow graph without simplification passes, data flow information, and function definitions. We then create a new ${ctx.link(IntervalInferenceVisitor)} using the control flow graph, dataflow graph, normalized AST, and analyzer context, and start the visitor using ${ctx.linkM(absint_visitor_1.AbstractInterpretationVisitor, 'start', { hideClass: true })}. After the visitor is finished, we retrieve the inferred abstract state at the end of the program using ${ctx.linkM(absint_visitor_1.AbstractInterpretationVisitor, 'getEndState', { hideClass: true })}.
 
 If we now print the inferred abstract state at the end of the program, we get the following output:
 

package/documentation/wiki-analyzer.js

@@ -22,7 +22,6 @@ const flowr_analyzer_loading_order_context_1 = require("../project/context/flowr
 const flowr_analyzer_dependencies_context_1 = require("../project/context/flowr-analyzer-dependencies-context");
 const flowr_analyzer_cache_1 = require("../project/cache/flowr-analyzer-cache");
 const pipeline_executor_1 = require("../core/pipeline-executor");
-const flowr_analyzer_plugin_defaults_1 = require("../project/plugins/flowr-analyzer-plugin-defaults");
 const doc_maker_1 = require("./wiki-mk/doc-maker");
 const flowr_analyzer_rmd_file_plugin_1 = require("../project/plugins/file-plugins/notebooks/flowr-analyzer-rmd-file-plugin");
 const flowr_analyzer_plugin_1 = require("../project/plugins/flowr-analyzer-plugin");
@@ -219,7 +218,7 @@ This indicates three ways to add a new plugin:
 3. By providing a tuple of the plugin name and its constructor arguments (e.g., \`['file:rmd', [/.*.rmd/i]]\` for the ${ctx.link(flowr_analyzer_rmd_file_plugin_1.FlowrAnalyzerRmdFilePlugin)}).\\
    This will also use the ${ctx.link(plugin_registry_1.makePlugin)} function under the hood to create the plugin instance.
 
-Please note, that by passing \`false\` to the builder constructor, no default plugins (see ${ctx.link(flowr_analyzer_plugin_defaults_1.FlowrAnalyzerPluginDefaults)}) are registered (otherwise, all of the plugins in the example above would be registered by default).
+Please note, that by passing \`false\` to the builder constructor, no default plugins (see ${ctx.link('FlowrDefaultPlugins')}) are registered (otherwise, all of the plugins in the example above would be registered by default).
 If you want to unregister specific plugins, you can use the ${ctx.linkM(flowr_analyzer_builder_1.FlowrAnalyzerBuilder, 'unregisterPlugins')} method.
 
 ${(0, doc_structure_1.block)({
@@ -251,7 +250,7 @@ Plugins allow you to extend the capabilities of the analyzer in many different w
 For example, they can be used to support other file formats, or to provide new algorithms to determine the loading order of files in a project.
 All plugins have to extend the ${ctx.link(flowr_analyzer_plugin_1.FlowrAnalyzerPlugin)} base class and specify their ${ctx.link('PluginType')}.
 During the analysis, the analyzer will apply all registered plugins of the different types at the appropriate stages of the analysis.
-If you just want to _use_ these plugins, you can usually ignore their [type](#plugin-types) and just register them with the builder as described 
+If you just want to _use_ these plugins, you can usually ignore their [type](#plugin-types) and just register them with the builder as described
 in the [Builder Configuration](#builder-configuration) section above.
 However, if you want to _create_ new plugins, you should be aware of the different plugin types and when they are applied during the analysis.
 
@@ -285,7 +284,7 @@ ${(0, doc_structure_1.section)('Project Discovery', 4)}
 
 These plugins trigger when confronted with a project analysis request (see, ${ctx.link('RProjectAnalysisRequest')}).
 Their job is to identify the files that belong to the project and add them to the analysis.
-flowR provides the ${ctx.link(flowr_analyzer_project_discovery_plugin_1.FlowrAnalyzerProjectDiscoveryPlugin)} with a 
+flowR provides the ${ctx.link(flowr_analyzer_project_discovery_plugin_1.FlowrAnalyzerProjectDiscoveryPlugin)} with a
 ${ctx.link(flowr_analyzer_project_discovery_plugin_1.FlowrAnalyzerProjectDiscoveryPlugin.defaultPlugin.name)} as the default implementation that simply collects all R source files in the given folder.
 
 Please note that all project discovery plugins should conform to the ${ctx.link(flowr_analyzer_project_discovery_plugin_1.FlowrAnalyzerProjectDiscoveryPlugin)} base class.

package/documentation/wiki-interface.js

@@ -20,6 +20,7 @@ const doc_structure_1 = require("./doc-util/doc-structure");
 const doc_maker_1 = require("./wiki-mk/doc-maker");
 const doc_writing_code_1 = require("./data/interface/doc-writing-code");
 const built_in_proc_name_1 = require("../dataflow/environments/built-in-proc-name");
+const flowr_analyzer_1 = require("../project/flowr-analyzer");
 async function explainServer(parser) {
     (0, doc_data_server_messages_1.documentAllServerMessages)();
     return `
@@ -42,7 +43,7 @@ ${await (0, doc_server_message_1.printServerMessages)(parser)}
 ### 📡 Ways of Connecting
 
 If you are interested in clients that communicate with _flowR_, please check out the [R adapter](${doc_files_1.FlowrGithubBaseRef}/flowr-r-adapter)
-as well as the [Visual Studio Code extension](${doc_files_1.FlowrGithubBaseRef}/vscode-flowr). 
+as well as the [Visual Studio Code extension](${doc_files_1.FlowrGithubBaseRef}/vscode-flowr).
 
 <ol>
 
@@ -99,9 +100,9 @@ async function explainRepl(parser, ctx) {
 > To execute arbitrary R commands with a repl request, _flowR_ has to be started explicitly with ${ctx.cliOption('flowr', 'r-session-access')}.
 > Please be aware that this introduces a security risk and note that this relies on the ${ctx.linkPage('wiki/Engines', '`r-shell` engine')} .
 
-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, 
+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.
@@ -111,7 +112,7 @@ The best command to get started with the REPL is ${ctx.replCmd('help')}.
 Besides, you can leave the REPL either with the command ${ctx.replCmd('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. 
+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]
@@ -144,7 +145,7 @@ can be used to also modify the currently active configuration of _flowR_ within
 
 ### Example: Retrieving the Dataflow Graph
 
-To retrieve a URL to the [mermaid](https://mermaid.js.org/) diagram of the dataflow of a given expression, 
+To retrieve a URL to the [mermaid](https://mermaid.js.org/) diagram of the dataflow of a given expression,
 use ${ctx.replCmd('dataflow*')} (or ${ctx.replCmd('dataflow')} to get the mermaid code in the cli):
 
 ${await (0, doc_repl_1.documentReplSession)(parser, [{
@@ -163,8 +164,8 @@ For the slicing with ${ctx.replCmd('slicer')}, you have access to the same [magi
 
 ### Example: Interfacing with the File System
 
-Many commands that allow for an R-expression (like ${ctx.replCmd('dataflow*')}) allow for a file as well 
-if the argument starts with \`${retriever_1.fileProtocol}\`. 
+Many commands that allow for an R-expression (like ${ctx.replCmd('dataflow*')}) allow for a file as well
+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 ${ctx.replCmd('parse')} command:
 
 ${await (0, doc_repl_1.documentReplSession)(parser, [{
@@ -179,7 +180,7 @@ ${(0, doc_code_1.codeBlock)('r', (0, doc_files_1.getFileContentFromRoot)('test/t
 
 </details>
 
-As _flowR_ directly transforms this AST the output focuses on being human-readable instead of being machine-readable. 
+As _flowR_ directly transforms this AST the output focuses on being human-readable instead of being machine-readable.
 		`
         }])}
 
@@ -203,8 +204,8 @@ For more information on the available queries, please check out the ${ctx.linkPa
 function explainConfigFile(ctx) {
     return `
 
-When running _flowR_, you may want to specify some behaviors with a dedicated configuration file. 
-By default, flowR looks for a file named \`${flowr_main_options_1.defaultConfigFile}\` in the current working directory (or any higher directory). 
+When running _flowR_, you may want to specify some behaviors with a dedicated configuration file.
+By default, flowR looks for a file named \`${flowr_main_options_1.defaultConfigFile}\` in the current working directory (or any higher directory).
 You can also specify a different file with ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'config-file')} or pass the configuration inline using ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'config-json')}.
 To inspect the current configuration, you can run flowr with the ${(0, doc_cli_option_1.getCliLongOptionOf)('flowr', 'verbose')} flag, or use the \`config\` [Query](${doc_files_1.FlowrWikiBaseRef}/Query%20API).
 Within the REPL this works by running the following:
@@ -216,13 +217,15 @@ ${ctx.linkO(config_1.FlowrConfig, 'amend')}.
 The following summarizes the configuration options:
 
 - \`ignoreSourceCalls\`: If set to \`true\`, _flowR_ will ignore source calls when analyzing the code, i.e., ignoring the inclusion of other files.
-- \`semantics\`: allows to configure the way _flowR_ handles R, although we currently only support \`semantics/environment/overwriteBuiltIns\`. 
-  You may use this to overwrite _flowR_'s handling of built-in function and even completely clear the preset definitions shipped with flowR. 
+- \`semantics\`: allows to configure the way _flowR_ handles R, although we currently only support \`semantics/environment/overwriteBuiltIns\`.
+  You may use this to overwrite _flowR_'s handling of built-in function and even completely clear the preset definitions shipped with flowR.
   See [Configure BuiltIn Semantics](#configure-builtin-semantics) for more information.
 - \`solver\`: allows to configure how _flowR_ resolves variables and their values (currently we support: ${Object.values(config_1.VariableResolve).map(v => `\`${v}\``).join(', ')}), as well as if pointer analysis should be active.
 - \`engines\`: allows to configure the engines used by _flowR_ to interact with R code. See the [Engines wiki page](${doc_files_1.FlowrWikiBaseRef}/Engines) for more information.
 - \`defaultEngine\`: allows to specify the default engine to use for interacting with R code. If not set, an arbitrary engine from the specified list will be used.
 - \`abstractInterpretation\`: allows to configure how _flowR_ performs abstract interpretation, although we currently only support data frame shape inference through abstract interpretation.
+- \`defaultPlugins\`: allows to configure which plugins to load by default when creating a new ${ctx.link(flowr_analyzer_1.FlowrAnalyzer)} instance.
+- \`repl.plugins\`: allows to configure which plugins to load in the _flowR_ REPL. Use \`flowr:default\` to reference the plugins specified by \`defaultPlugins\`.
 
 So you can configure _flowR_ by adding a file like the following:
 
@@ -241,9 +244,11 @@ ${(0, doc_code_1.codeBlock)('json', JSON.stringify({
                 }
             }
         },
+        defaultPlugins: ['file:description', 'versions:description'],
         repl: {
             quickStats: false,
-            dfProcessorHeat: false
+            dfProcessorHeat: false,
+            plugins: ['flowr:default']
         },
         project: {
             resolveUnknownPathsOnDisk: true
@@ -277,9 +282,9 @@ ${(0, doc_code_1.codeBlock)('json', JSON.stringify({
 
 </details>
 
-<details> 
+<details>
 <a id='configure-builtin-semantics'></a>
-<summary>Configure Built-In Semantics</summary> 
+<summary>Configure Built-In Semantics</summary>
 
 
 \`semantics/environment/overwriteBuiltins\` accepts two keys:

package/linter/linter-rules.d.ts

@@ -283,14 +283,14 @@ export declare const LintingRules: {
     };
     readonly 'problematic-inputs': {
         readonly createSearch: (config: import("./rules/problematic-inputs").ProblematicInputsConfig) => import("../search/flowr-search-builder").FlowrSearchBuilder<"from-query", [], import("../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation, import("../search/flowr-search").FlowrSearchElements<import("../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation, import("../search/flowr-search").FlowrSearchElement<import("../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation>[]>>;
-        readonly processSearchResult: (elements: import("../search/flowr-search").FlowrSearchElements<import("../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation, import("../search/flowr-search").FlowrSearchElement<import("../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation>[]>, _config: import("./rules/problematic-inputs").ProblematicInputsConfig, data: {
+        readonly processSearchResult: (elements: import("../search/flowr-search").FlowrSearchElements<import("../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation, import("../search/flowr-search").FlowrSearchElement<import("../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation>[]>, config: import("./rules/problematic-inputs").ProblematicInputsConfig, data: {
             normalize: import("../r-bridge/lang-4.x/ast/model/processing/decorate").NormalizedAst;
             dataflow: import("../dataflow/info").DataflowInformation;
             cfg: import("../control-flow/control-flow-graph").ControlFlowInformation;
             analyzer: import("../project/flowr-analyzer").ReadonlyFlowrAnalysisProvider;
         }) => Promise<{
             results: import("./rules/problematic-inputs").ProblematicInputsResult[];
-            ".meta": import("./rules/problematic-inputs").ProblematicInputsMetadata;
+            '.meta': {};
         }>;
         readonly prettyPrint: {
             readonly query: (result: import("./rules/problematic-inputs").ProblematicInputsResult) => string;

package/linter/rules/problematic-inputs.d.ts

@@ -2,7 +2,7 @@ import { type LintingResult, LintingRuleCertainty } from '../linter-format';
 import type { MergeableRecord } from '../../util/objects';
 import { SourceLocation } from '../../util/range';
 import { LintingRuleTag } from '../linter-tags';
-import type { InputSources } from '../../queries/catalog/input-sources-query/simple-input-classifier';
+import type { InputClassifierConfig, InputSources } from '../../queries/catalog/input-sources-query/simple-input-classifier';
 /**
  * Describes a linting result for a problematic eval usage, including the location of the eval call and the computed input sources that lead to it.
  */
@@ -13,18 +13,19 @@ export interface ProblematicInputsResult extends LintingResult {
 }
 export interface ProblematicInputsConfig extends MergeableRecord {
     consider?: string | string[];
+    inputFns?: InputClassifierConfig;
 }
 export type ProblematicInputsMetadata = MergeableRecord;
 export declare const PROBLEMATIC_INPUTS: {
     readonly createSearch: (config: ProblematicInputsConfig) => import("../../search/flowr-search-builder").FlowrSearchBuilder<"from-query", [], import("../../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation, import("../../search/flowr-search").FlowrSearchElements<import("../../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation, import("../../search/flowr-search").FlowrSearchElement<import("../../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation>[]>>;
-    readonly processSearchResult: (elements: import("../../search/flowr-search").FlowrSearchElements<import("../../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation, import("../../search/flowr-search").FlowrSearchElement<import("../../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation>[]>, _config: ProblematicInputsConfig, data: {
+    readonly processSearchResult: (elements: import("../../search/flowr-search").FlowrSearchElements<import("../../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation, import("../../search/flowr-search").FlowrSearchElement<import("../../r-bridge/lang-4.x/ast/model/processing/decorate").ParentInformation>[]>, config: ProblematicInputsConfig, data: {
         normalize: import("../../r-bridge/lang-4.x/ast/model/processing/decorate").NormalizedAst;
         dataflow: import("../../dataflow/info").DataflowInformation;
         cfg: import("../../control-flow/control-flow-graph").ControlFlowInformation;
         analyzer: import("../../project/flowr-analyzer").ReadonlyFlowrAnalysisProvider;
     }) => Promise<{
         results: ProblematicInputsResult[];
-        ".meta": ProblematicInputsMetadata;
+        '.meta': {};
     }>;
     readonly prettyPrint: {
         readonly query: (result: ProblematicInputsResult) => string;

package/linter/rules/problematic-inputs.js

@@ -49,8 +49,7 @@ function isProblematicForAllowed(sources, allowed) {
 }
 exports.PROBLEMATIC_INPUTS = {
     createSearch: config => {
-        const cfg = config;
-        const considerArr = normalizeConsider(cfg);
+        const considerArr = normalizeConsider(config);
         const queries = considerArr.map((name, i) => ({
             type: 'call-context',
             callName: name,
@@ -59,13 +58,13 @@ exports.PROBLEMATIC_INPUTS = {
         }));
         return flowr_search_builder_1.Q.fromQuery(...queries);
     },
-    processSearchResult: async (elements, _config, data) => {
+    processSearchResult: async (elements, config, data) => {
         const results = [];
         const defaultAccept = [simple_input_classifier_1.InputType.Constant, simple_input_classifier_1.InputType.DerivedConstant];
         for (const element of elements.getElements()) {
             const nid = element.node.info.id;
             const criterion = parse_1.SlicingCriterion.fromId(nid);
-            const q = { type: 'input-sources', criterion };
+            const q = { type: 'input-sources', criterion, config: config.inputFns };
             const all = await data.analyzer.query([q]);
             const inputSourcesResult = all['input-sources'];
             const sources = inputSourcesResult?.results?.[criterion] ?? [];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eagleoutice/flowr",
-  "version": "2.10.4",
+  "version": "2.10.5",
   "description": "Static Dataflow Analyzer and Program Slicer for the R Programming Language",
   "types": "dist/src/index.d.ts",
   "repository": {
@@ -170,7 +170,7 @@
     "@eagleoutice/eslint-config-flowr": "^1.0.40",
     "@eslint/eslintrc": "^3.3.3",
     "@eslint/js": "^9.39.2",
-    "@j-ulrich/release-it-regex-bumper": "^5.3.0",
+    "@j-ulrich/release-it-regex-bumper": "^5.4.0",
     "@types/command-line-args": "^5.2.3",
     "@types/command-line-usage": "^5.0.4",
     "@types/commonmark": "^0.27.10",
@@ -188,7 +188,7 @@
     "eslint": "^9.39.2",
     "license-checker-rseidelsohn": "^4.4.2",
     "npm-run-all": "^4.1.5",
-    "release-it": "^19.2.3",
+    "release-it": "^20.0.0",
     "ts-node": "^10.9.2",
     "typedoc": "^0.28.17",
     "typedoc-plugin-missing-exports": "^4.1.2",

package/project/flowr-analyzer-builder.d.ts

@@ -34,11 +34,12 @@ export declare class FlowrAnalyzerBuilder {
     private parser?;
     private input?;
     private readonly plugins;
+    private readonly withDefaultPlugins;
     /**
      * Creates a new builder for the {@link FlowrAnalyzer}.
-     * By default, the standard set of plugins as returned by {@link FlowrAnalyzerPluginDefaults} are registered.
+     * By default, the standard set of plugins as returned by {@link FlowrConfig#defaultPlugins} are registered.
      * @param withDefaultPlugins - Whether to register the default plugins upon creation. Default is `true`.
-     * @see {@link FlowrAnalyzerPluginDefaults} - for the default plugin set.
+     * @see {@link FlowrDefaultPlugins} - for the default plugin set.
      * @see {@link FlowrAnalyzerBuilder#registerPlugins} - to add more plugins.
      * @see {@link FlowrAnalyzerBuilder#unregisterPlugins} - to remove plugins.
      */
@@ -53,6 +54,8 @@ export declare class FlowrAnalyzerBuilder {
     amendConfig(func: (config: DeepWritable<FlowrConfig>) => FlowrConfig | void): this;
     /**
      * Overwrite the configuration used by the resulting analyzer.
+     * This also unloads all default plugins and reloads them as set in the new config
+     * if the withDefaultPlugins flag was set in the constructor
      * @param config - The new configuration.
      */
     setConfig(config: FlowrConfig): this;
@@ -78,7 +81,7 @@ export declare class FlowrAnalyzerBuilder {
     setInput(input: Omit<NormalizeRequiredInput, 'context'>): this;
     /**
      * Register one or multiple additional plugins.
-     * For the default plugin set, please refer to {@link FlowrAnalyzerPluginDefaults}, they can be registered
+     * For the default plugin set, please refer to {@link FlowrDefaultPlugins}, they can be registered
      * by passing `true` to the {@link FlowrAnalyzerBuilder} constructor.
      * @param plugin - One or multiple plugins to register.
      * @see {@link FlowrAnalyzerBuilder#unregisterPlugins} to remove plugins.

package/project/flowr-analyzer-builder.js

@@ -7,7 +7,6 @@ const engines_1 = require("../engines");
 const assert_1 = require("../util/assert");
 const flowr_analyzer_context_1 = require("./context/flowr-analyzer-context");
 const flowr_analyzer_cache_1 = require("./cache/flowr-analyzer-cache");
-const flowr_analyzer_plugin_defaults_1 = require("./plugins/flowr-analyzer-plugin-defaults");
 const plugin_registry_1 = require("./plugins/plugin-registry");
 /**
  * Builder for the {@link FlowrAnalyzer}, use it to configure all analysis aspects before creating the analyzer instance
@@ -37,17 +36,19 @@ class FlowrAnalyzerBuilder {
     parser;
     input;
     plugins = new Map();
+    withDefaultPlugins;
     /**
      * Creates a new builder for the {@link FlowrAnalyzer}.
-     * By default, the standard set of plugins as returned by {@link FlowrAnalyzerPluginDefaults} are registered.
+     * By default, the standard set of plugins as returned by {@link FlowrConfig#defaultPlugins} are registered.
      * @param withDefaultPlugins - Whether to register the default plugins upon creation. Default is `true`.
-     * @see {@link FlowrAnalyzerPluginDefaults} - for the default plugin set.
+     * @see {@link FlowrDefaultPlugins} - for the default plugin set.
      * @see {@link FlowrAnalyzerBuilder#registerPlugins} - to add more plugins.
      * @see {@link FlowrAnalyzerBuilder#unregisterPlugins} - to remove plugins.
      */
     constructor(withDefaultPlugins = true) {
+        this.withDefaultPlugins = withDefaultPlugins;
         if (withDefaultPlugins) {
-            this.registerPlugins(...(0, flowr_analyzer_plugin_defaults_1.FlowrAnalyzerPluginDefaults)());
+            this.registerPlugins(...this.flowrConfig.defaultPlugins);
         }
     }
     /**
@@ -64,9 +65,15 @@ class FlowrAnalyzerBuilder {
     }
     /**
      * Overwrite the configuration used by the resulting analyzer.
+     * This also unloads all default plugins and reloads them as set in the new config
+     * if the withDefaultPlugins flag was set in the constructor
      * @param config - The new configuration.
      */
     setConfig(config) {
+        if (this.withDefaultPlugins) {
+            this.unregisterPlugins(...this.flowrConfig.defaultPlugins.map(p => Array.isArray(p) ? p[0] : p));
+            this.registerPlugins(...config.defaultPlugins);
+        }
         this.flowrConfig = config;
         return this;
     }
@@ -104,7 +111,7 @@ class FlowrAnalyzerBuilder {
     }
     /**
      * Register one or multiple additional plugins.
-     * For the default plugin set, please refer to {@link FlowrAnalyzerPluginDefaults}, they can be registered
+     * For the default plugin set, please refer to {@link FlowrDefaultPlugins}, they can be registered
      * by passing `true` to the {@link FlowrAnalyzerBuilder} constructor.
      * @param plugin - One or multiple plugins to register.
      * @see {@link FlowrAnalyzerBuilder#unregisterPlugins} to remove plugins.

package/project/plugins/file-plugins/files/flowr-rmarkdown-file.d.ts

@@ -3,7 +3,7 @@ import { FlowrFile } from '../../../context/flowr-file';
 import { type Node } from 'commonmark';
 /**
  * This decorates a text file and parses its contents as a R Markdown file.
- * Finnaly, it provides access to the single cells, and all cells fused together as one R file.
+ * Finally, it provides access to the single cells, and all cells fused together as one R file.
  */
 export declare class FlowrRMarkdownFile extends FlowrFile<string> {
     private data?;
@@ -24,8 +24,9 @@ export declare class FlowrRMarkdownFile extends FlowrFile<string> {
     protected loadContent(): string;
     static from(file: FlowrFileProvider<string> | FlowrRMarkdownFile): FlowrRMarkdownFile;
 }
+export type CodeBlockOptions = Map<string, string>;
 export interface CodeBlock {
-    options: string;
+    options: CodeBlockOptions;
     code: string;
 }
 export type CodeBlockEx = CodeBlock & {
@@ -59,4 +60,4 @@ export declare function restoreBlocksWithoutMd(blocks: CodeBlockEx[], totalLines
 /**
  * Parses the options of an R code block from its header and content
  */
-export declare function parseCodeBlockOptions(header: string, content: string): string;
+export declare function parseCodeBlockOptions(header: string, content: string): CodeBlockOptions;

package/project/plugins/file-plugins/files/flowr-rmarkdown-file.js

@@ -15,7 +15,7 @@ const gray_matter_1 = __importDefault(require("gray-matter"));
 const log_1 = require("../../../../util/log");
 /**
  * This decorates a text file and parses its contents as a R Markdown file.
- * Finnaly, it provides access to the single cells, and all cells fused together as one R file.
+ * Finally, it provides access to the single cells, and all cells fused together as one R file.
  */
 class FlowrRMarkdownFile extends flowr_file_1.FlowrFile {
     data;
@@ -78,9 +78,14 @@ function parseRMarkdownFile(raw) {
         if (!isRCodeBlock(node)) {
             continue;
         }
+        const options = parseCodeBlockOptions(node.info, node.literal);
+        const engineOpt = options.get('engine');
+        if (engineOpt !== undefined && engineOpt.trim().toLowerCase() !== 'r') {
+            continue;
+        }
         blocks.push({
             code: node.literal,
-            options: parseCodeBlockOptions(node.info, node.literal),
+            options: options,
             startpos: { line: node.sourcepos[0][0] + 1, col: 0 }
         });
     }
@@ -91,6 +96,7 @@ function parseRMarkdownFile(raw) {
         options: frontmatter?.data ?? {}
     };
 }
+// We need the [\s,] part, otherwise {rust} would also match
 const RTagRegex = /{[rR](?:[\s,][^}]*)?}/;
 /**
  * Checks whether a CommonMark node is an R code block
@@ -123,6 +129,7 @@ function restoreBlocksWithoutMd(blocks, totalLines) {
     goToLine(totalLines + 1);
     return output;
 }
+const OptionsRegex = /([\w_.-]*)\s*[:=]\s*["']?([^,"']*)/g;
 /**
  * Parses the options of an R code block from its header and content
  */
@@ -135,9 +142,15 @@ function parseCodeBlockOptions(header, content) {
         if (!line.trim().startsWith('#|')) {
             break;
         }
-        const opt = line.substring(3);
+        const opt = line.substring(2).trim();
         opts += opts.length === 0 ? opt : `, ${opt}`;
     }
-    return opts;
+    const parsedOptions = new Map();
+    for (const match of opts.matchAll(OptionsRegex)) {
+        if (match[1] && match[2] !== undefined) { // key must not be empty, but value can be empty string for example
+            parsedOptions.set(match[1], match[2]);
+        }
+    }
+    return parsedOptions;
 }
 //# sourceMappingURL=flowr-rmarkdown-file.js.map

package/project/plugins/flowr-analyzer-plugin.d.ts

@@ -73,7 +73,7 @@ export interface FlowrAnalyzerPluginInterface<In = unknown, Out = In> {
  * For example, if you want to create a plugin that determines the loading order of files, extend {@link FlowrAnalyzerLoadingOrderPlugin} instead.
  * These classes also provide sensible overrides of {@link FlowrAnalyzerPlugin.defaultPlugin} to be used when no plugin of this type is registered or triggered.
  *
- * For a collection of default plugins, see {@link FlowrAnalyzerPluginDefaults}.
+ * For a collection of default plugins, see {@link FlowrDefaultPlugins}.
  */
 export declare abstract class FlowrAnalyzerPlugin<In = unknown, Out extends AsyncOrSync<unknown> = In> implements FlowrAnalyzerPluginInterface<In, Out> {
     abstract readonly name: string;

package/project/plugins/flowr-analyzer-plugin.js

@@ -53,7 +53,7 @@ const generalPluginLog = log_1.log.getSubLogger({ name: 'plugins' });
  * For example, if you want to create a plugin that determines the loading order of files, extend {@link FlowrAnalyzerLoadingOrderPlugin} instead.
  * These classes also provide sensible overrides of {@link FlowrAnalyzerPlugin.defaultPlugin} to be used when no plugin of this type is registered or triggered.
  *
- * For a collection of default plugins, see {@link FlowrAnalyzerPluginDefaults}.
+ * For a collection of default plugins, see {@link FlowrDefaultPlugins}.
  */
 class FlowrAnalyzerPlugin {
     /**

package/queries/catalog/input-sources-query/input-source-functions.d.ts

@@ -0,0 +1,6 @@
+import type { Identifier } from '../../../dataflow/environments/identifier';
+export declare const PureFunctions: Identifier[];
+export declare const SystemFunctions: Identifier[];
+export declare const FfiFunctions: Identifier[];
+export declare const LangFunctions: Identifier[];
+export declare const OptionsFunctions: Identifier[];