Skip to content

dSeq

While the Input-Processing-Output (IPO) paradigm is self-explanatory, it's crucial to elucidate certain terms and concepts within this framework. One such concept is the dSeq (direct sequence), which embodies the structured execution flow in mDm, encapsulating the phases of the IPO model within a single, cohesive construct.

A typical dSeq is structured as follows:

data, process, result

Key Characteristics of dSeqs:

  • Tripartite Structure: Each dSeq consists invariably of three steps: INPUT, PROCESSING, OUTPUT. The separation of these steps is marked by commas, and each step is known as a dState.
  • Sequential Execution: dSeqs are self-contained and always transition sequentially from one dState to the next, ensuring that inputs or parameters for an operation precede the processing, and the results are instantly available at the output.
  • Nesting and Modularity: dSeqs can be nested within parentheses (INPUT, PROCESSING, OUTPUT) to be used recursively within other dSeqs. This nesting enhances the language's functionality and allows the output of one dSeq to be utilized in different parts of the program or in other program components.
  • Fundamental Computational Step: In mDm, every type definition, function, or complete program is essentially a dSeq, making it the sole and fundamental computational step.

Declaration and Implementation in dSeqs:

dSeqs can be used for both declarative purposes and implementation. In the programming context, they differ as follows: - Declaration: (input types), function name, (output types) - Implementation: (input variables), (process logic), function name

Examples of Nesting:

Nesting dSeqs can take forms like:

((dState, dState, dState), dState, dState)

or

((dSeq, dState, dState), dSeq, dState)

These structures extend the functionality of the language, allowing intricate and modular programming constructs.

Practical Implementation:

The use of file extensions to distinguish between declarations and implementations in mDm offers a practical and elegant solution with multiple benefits: - Clear Separation: Using .mdmD for declarations and .mdmI for implementations aids in the immediate recognition of interfaces versus implementation details. - Dependency Management: This distinction helps developers and tools easily identify dependencies that are interface-based (and thus potentially interchangeable) from those that require specific implementations. - Multiple Implementations: Different implementations of the same interface can be handled by using distinct .mdmI files, useful for platform-specific implementations or optimizations. - Enhanced Tool Support: Development environments and build tools can provide features like auto-generation of implementation skeletons based on declarations, or verification of conformity between declarations and implementations.

Example Usage:

Suppose we have a function addiere defined in math.mdmD and implemented in math.mdmI.

Declaration in math.mdmD might look like:

(int, int), addiere, (int)

Implementation in math.mdmI could contain:

(a, b), (a + b), addiere

An import in another module might specifically refer to one of these files, depending on the need for just the interface or the implementation:

import "math.mdmD" // Imports only the declaration

This methodology promotes modularity and abstraction by clearly separating interfaces from their implementations. It also supports the principle of least knowledge by allowing dependencies to be restricted to what is truly needed.