tomoyanonymous/ifc-2024-lambdammm
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

applied english proofreading

Browse Source
This commit is contained in:
松浦 知也 Matsuura Tomoya
2024-09-28 15:23:58 +00:00
parent 868c345430
commit 53aade123d
2 changed files with 61 additions and 68 deletions
Download Patch File Download Diff File Expand all files Collapse all files

129
src/content.tex
View File

@@ -1,46 +1,45 @@
\begin{abstract}
This paper proposes \lambdammm , a call-by-value, simply-typed lambda calculus-based intermediate representation for a music programming language, which handles synchronous signal processing, Additionally, it introduces a virtual machine and instruction set to execute \lambdammm . Digital signal processing is represented through a syntax that incorporates the internal states of delay and feedback into the lambda calculus. \lambdammm\ extends the lambda calculus, allowing users to construct generative signal processing graphs and execute them with consistent semantics. However, a challenge arises when handling higher-order functions, as users must determine whether execution occurs within the global environment or during DSP execution. This issue can potentially be resolved through multi-stage computation.
\end{abstract}
This paper proposes \lambdammm, a call-by-value, simply typed lambda calculus-based intermediate representation for a music programming language that handles synchronous signal processing and introduces a virtual machine and instruction set to execute \lambdammm. Digital signal processing is represented by a syntax that incorporates the internal states of delay and feedback into the lambda calculus. \lambdammm\ extends the lambda calculus, allowing users to construct generative signal processing graphs and execute them with consistent semantics. However, a challenge arises when handling higher-order functions because users must determine whether execution occurs within the global environment or during DSP execution. This issue can potentially be resolved through multi-stage computation.
\end{abstract}
\section{Introduction}
\label{sec:intro}
Many programming languages for sound and music have been developed, but only a few possess strongly formalized semantics. One language that is both rigorously formalized and practical is Faust \cite{Orlarey2004}, which combines blocks with inputs and outputs with five primitive operations: parallel, sequential, split, merge, and recursive connection. By providing basic arithmetic, conditionals, and delays as primitive blocks, almost any type of signal processing can be written in Faust. In a later extension, a macro based on a term rewriting system was introduced, allowing users to parameterize blocks with an arbitrary number of inputs and outputs \cite{graf2010}.
Many programming languages have been developed for sound and music; however, only a few possess strongly formalized semantics. A language that is both rigorously formalized and practical is Faust \cite{Orlarey2004}; it combines blocks with inputs and outputs with five primitive operations: parallel, sequential, split, merge, and recursive connection. Almost any type of signal processing can be written in Faust by providing basic arithmetic, conditionals, and delays as primitive blocks. In a later extension, a macro based on a term rewriting system was introduced that allowed users to parameterize blocks with an arbitrary number of inputs and outputs \cite{graf2010}.
This strong abstraction capability through formalization enables Faust to be translated to various backends, such as C, C++, Rust, and LLVM IR. On the other hand, Faust's Block Diagram Algebra (BDA) lacks theoretical and practical compatibility with common programming languages. Although it is possible to call external C functions in Faust, those functions are assumed to be pure functions that do not have any internal states. Therefore, while it is easy to embed Faust in another language, it is not easy to call another language from Faust.
This strong abstraction capability through formalization enables Faust to be translated into various backends, such as C, C++, Rust, and LLVM IR. On the other hand, Faust's Block Diagram Algebra (BDA) lacks theoretical and practical compatibility with common programming languages. Although it is possible to call external C functions in Faust, these functions are assumed to be pure functions that do not have internal states. Therefore, while it is easy to embed Faust in another language, it is not easy to call another language from Faust.
In addition, a macro for Faust is an independent term rewriting system that generates BDA based on pattern matching. As a result, the numeric arguments for pattern matching are implicitly required to be integers, which can sometimes lead to compile-time errors, despite the fact that BDA does not distinguish between real and integer types. These implicit typing rules are not intuitive for novice users.
In addition, a macro for Faust is an independent term rewriting system that generates a BDA based on pattern matching. Consequently, the numeric arguments for pattern matching are implicitly required to be integers, which can sometimes lead to compile-time errors despite the fact that BDA does not distinguish between real and integer types. However, the implicit typing rules are not intuitive for novice users.
Proposing a computational model for signal processing based on more generic computational models, such as lambda calculus, has the potential to enable interoperability between many different general-purpose languages, and also facilitate the appropriation of existing optimization methods and the implementation of compilers and run-time.
Proposing a computational model for signal processing based on more generic computational models such as lambda calculus has the potential to enable interoperability between many different general-purpose languages and facilitate the appropriation of existing optimization methods and the implementation of compilers and runtimes.
Currently, it has been demonstrated that BDA can be converted to a general-purpose functional language using an arrow, a higher-level abstraction of monads \cite{gaster2018}. However, higher-order functions in general-purpose functional languages are often implemented with dynamic memory allocation and deallocation, making them difficult to use in host languages designed for real-time signal processing.
It has been demonstrated that BDA can be converted into a general-purpose functional language using an arrow, which is a higher-level abstraction of monads \cite{gaster2018}. However, higher-order functions in general-purpose functional languages are often implemented using dynamic memory allocation and deallocation, making them difficult to use in host languages designed for real-time signal processing.
Additionally, Kronos \cite{norilo2015} and W-calculus \cite{arias2021} are examples of lambda calculus-based abstractions influenced by Faust. Kronos is based on the theoretical foundation of System-$F\omega$, a variation of lambda calculus in which types themselves can be abstracted (i.e., a function that takes a type as input and returns a new type can be defined). In Kronos, type calculations correspond to signal graph generation, while value calculations correspond to the actual processing. Delay is the only special primitive operation in Kronos, and feedback routing can be represented as a recursive function application in type calculations.
In addition, Kronos \cite{norilo2015} and W-calculus \cite{arias2021} are examples of lambda calculus-based abstractions influenced by Faust. Kronos is based on the theoretical foundation of the System-$F\omega$, a variation of lambda calculus in which the types themselves can be abstracted (i.e., a function that takes a type as input and returns a new type can be defined). In Kronos, type calculations correspond to signal graph generation, whereas the value calculations correspond to actual processing. Delay is the only special primitive operation in Kronos, and feedback routing can be represented as a recursive function application in type calculations.
W-calculus includes feedback as a primitive operation, along with the ability to access the value of a variable from the past (i.e., delay). W-calculus restricts systems to those that can represent linear-time-invariant processes, such as filters and reverberators, and it defines more formal semantics, aiming for automatic proofs of linearity and the identity of graph topologies.
W-calculus includes feedback as a primitive operation, along with the ability to access the value of a variable from the past (i.e., delay). W-calculus restricts systems to those that can represent linear-time-invariant processes, such as filters and reverberators, and defines more formal semantics, aiming for automatic proofs of linearity and the identity of graph topologies.
Previously, the author designed the music programming language \textit{mimium} \cite{matsuura2021a}. By incorporating basic operations such as delay and feedback into lambda calculus, signal processing can be concisely expressed while maintaining a syntax similar to that of general-purpose programming languages. Notably, \textit{mimium}'s syntax is designed to resemble the Rust programming language.
Previously, the author designed the music programming language \textit{mimium} \cite{matsuura2021a}. By incorporating basic operations such as delay and feedback into the lambda calculus, signal processing can be concisely expressed while maintaining a syntax similar to that of general-purpose programming languages. Notably, \textit{mimium}'s syntax was designed to resemble the Rust programming language.
One of the earlier issues with \textit{mimium} was its inability to compile code that contained combinations of recursive or higher-order functions with stateful functions involving delay or feedback, as the compiler could not determine the data size of the internal state used in signal processing.
In this paper, I propose the syntax and semantics of \lambdammm, an extended call-by-value simply-typed lambda calculus, as a computational model intended to serve as an intermediate representation for \textit{mimium}. Additionally, I propose a virtual machine and its instruction set, based on Lua's VM, to execute this computational model in practice. Finally, I discuss both the challenges and potential of the current \lambdammm\ model: one challenge is that users must differentiate whether a calculation occurs in a global context or during actual signal processing; another is that run-time interoperability with other programming languages could be easier than in existing DSP languages.
An earlier issue with \textit{mimium} was its inability to compile code that contained combinations of recursive or higher-order functions with stateful functions involving delay or feedback because the compiler could not determine the data size of the internal state used in signal processing.
In this paper, I propose the syntax and semantics of \lambdammm, an extended call-by-value simply typed lambda calculus, as a computational model intended to serve as an intermediate representation for \textit{mimium}. In addition, I propose a virtual machine and its instruction set, based on Lua's VM, to execute this computational model in practice. Finally, I discuss both the challenges and potential of the current \lambdammm\ model, one of which is that users must differentiate whether a calculation occurs in a global context or during actual signal processing; the other is that runtime interoperability with other programming languages could be easier than in existing DSP languages.
\section{Syntax}
\label{sec:syntax}
\input{syntax.tex}
The types and terms of \lambdammm\ are defined in Figure \ref{fig:syntax_v}.
The types and terms of \lambdammm\ are presented in Figure \ref{fig:syntax_v}.
Two terms are introduced in addition to the standard simply-typed lambda calculus: $delay\ n\ e_1\ e_2$, which refers to the previous value of $e_1$ by $e_2$ samples (with a maximum delay of $n$ to limit memory usage to a finite size), and $feed\ x.e$, an abstraction that allows the user to refer to the result of evaluating $e$ from one time unit earlier as $x$ during the evaluation of $e$ itself.
Two terms are introduced in addition to the standard simply typed lambda calculus: $delay\ n\ e_1\ e_2$, which refers to the previous value of $e_1$ by $e_2$ samples (with a maximum delay of $n$ to limit memory usage to a finite size), and $feed\ x.e$, an abstraction that allows the user to refer to the result of evaluating $e$ from one time unit earlier as $x$ during the evaluation of $e$ itself.
\subsection{Syntactic Sugar of the Feedback Expression in \textit{mimium}}
\label{sec:mimium}
The programming language \textit{mimium}, developed by the author, includes a keyword $self$ that can be used in function definitions to refer to the previous return value of the function. An example of a simple one-pole filter function, which mixes the input and the last output signal such that the sum of the input and feedback gains is 1, is shown in Listing \ref{lst:onepole}. This code can be expressed in \lambdammm\ as shown in Figure \ref{fig:onepole}.
The programming language \textit{mimium}, developed by the author, includes a keyword $self$ that can be used in function definitions to refer to the previous return value of the function. An example of a simple one-pole filter function, which mixes the input and last output signals such that the sum of the input and feedback gains is 1, is shown in Listing \ref{lst:onepole}. This code can be expressed in \lambdammm\ as illustrated in Figure \ref{fig:onepole}.
\begin{lstlisting}[float,floatplacement=H,label=lst:onepole,language=Rust,caption=\it Example of the code of one-pole filter in mimium.]
fn onepole(x,g){
@@ -64,55 +63,55 @@
\input{typing.tex}
Additional typing rules for the usual simply-typed lambda calculus are shown in Figure \ref{fig:typing}.
Additional typing rules for typical simply typed lambda calculus are shown in Figure \ref{fig:typing}.
The primitive types include a real number type, used in most signal processing, and a natural number type, which is used for the indices of delay.
The primitive types include a real number type, used in most signal processing, and a natural number type, used for the indices of delay.
In W-calculus, which directly inspired the design of \lambdammm, function types can only take tuples of real numbers and return tuples of real numbers. This restriction prevents the definition of higher-order functions. While this limitation is reasonable for a signal processing language—since higher-order functions require data structures like closures that depend on dynamic memory allocation—it also reduces the generality of the lambda calculus.
In W-calculus, which directly inspired the design of \ lambdammm, the function types can only take tuples of real numbers and return tuples of real numbers. This restriction prevents the definition of higher-order functions. While this limitation is reasonable for a signal processing language—since higher-order functions require data structures such as closures that depend on dynamic memory allocation—it also reduces the generality of lambda calculus.
In \lambdammm, the problem of memory allocation for closures is delegated to the runtime implementation (see Section \ref{sec:vm}), allowing the use of higher-order functions. However, the $feed$ abstraction does not permit function types as either input or output. Allowing function types in the $feed$ abstraction would enable the definition of functions whose behavior could change over time. While this is theoretically interesting, there are no practical examples in real-world signal processing, and such a feature would likely complicate implementations further.
In \lambdammm, the problem of memory allocation for closures is delegated to runtime implementation (see Section \ref{sec:vm}), which allows the use of higher-order functions. However, $feed$ abstraction does not permit function types to be either input or output. Allowing function types in the $feed$ abstraction enables the definition of functions whose behavior could change over time. While this is theoretically interesting, there are no practical examples in real-world signal processing, and such a feature would likely further complicate the implementation.
\section{Semantics}
\label{sec:semantics}
\input{semantics.tex}
An excerpt of the operational semantics for \lambdammm\ is shown in Figure \ref{fig:semantics}. This big-step semantics conceptually explains the evaluation process: when the current time is $n$, the evaluation environment from $t$ samples prior can be referred to as $E^{n-t}$. If the time is less than 0, any term is evaluated to the default value of its type (0 for numeric types).
An excerpt of the operational semantics for \lambdammm\ is shown in Figure \ref{fig:semantics}. This big-step semantics conceptually explains the evaluation process. When the current time is $n$, the evaluation environment from $t$ prior samples can be referred to as $E^{n-t}$. If the time is less than 0, any term is evaluated as the default value of its type (0 for numeric types).
Naturally, if we attempted to execute this semantics directly, we would need to recalculate from time 0 to the current time for every sample, saving all variable environments at each step. In practice, however, a virtual machine is defined that accounts for the internal memory space used by $delay$ and $feed$, and \lambdammm\ terms are compiled into instructions for this machine before execution.
Naturally, if we attempt to execute these semantics directly, we would need to recalculate from time 0 to the current time for every sample, saving all the variable environments at each step. However, in practice, a virtual machine is defined to account for the internal memory space used by $delay$ and $feed$, and \lambdammm\ terms are compiled into instructions for this machine before execution.
\section{VM Model and Instruction Set}
\label{sec:vm}
The virtual machine model and its instruction set for running \\ \lambdammm\ are based on the Lua version 5 VM \cite{ierusalimschy2005}.
The virtual machine model and its instruction set for running \\ \lambdammm\ are based on Lua version 5 VM \cite{ierusalimschy2005}.
When executing a computational model based on lambda calculus, a key challenge is handling the data structure known as a closure. A closure captures the variable environment in which the inner function is defined, allowing it to refer to variables from the outer function’s context. If the inner function is paired with a dictionary of variable names and values, the compiler (or interpreter) implementation is straightforward, but runtime performance is limited.
A key challenge when executing a computational model based on lambda calculus is handling the data structure, which is known as a closure. A closure captures the variable environment in which the inner function is defined, allowing it to refer to the variables from the outer function’s context. If the inner function is paired with a dictionary of variable names and values, the compiler (or interpreter) implementation is straightforward; however, the runtime performance is limited.
In contrast, runtime performance can be improved by using a process called closure conversion (or lambda lifting). This process analyzes all the outer variables referenced by the inner function and transforms the inner function by adding arguments so the outer variables can be referred to explicitly. However, implementing this transformation in the compiler is relatively complex.
Conversely, the runtime performance can be improved using a process called closure conversion (or lambda lifting). This process analyzes all the outer variables referenced by the inner function and transforms the inner function by adding arguments; thus, the outer variables can be referred to explicitly. However, the implementation of this transformation in the compiler is relatively complex.
The Lua VM adopts a middle-ground approach between these two methods by adding the VM instructions \texttt{GETUPVALUE} and \texttt{SETUPVALUE}, which allow outer variables to be dynamically referenced at runtime. The implementation of the compiler and VM using \textit{upvalues} is simpler than full closure conversion, while still avoiding significant performance degradation. In this approach, outer variables are accessed via the call stack, rather than heap memory, unless the closure escapes the original function's context \cite{nystrom2021}.
The Lua VM adopts a middle-ground approach between these two methods by adding the VM instructions \texttt{GETUPVALUE} and \texttt{SETUPVALUE}, which allow the outer variables to be dynamically referenced at runtime. The implementation of the compiler and VM using \textit{upvalues} is simpler than full closure conversion while still avoiding significant performance degradation. In this approach, the outer variables are accessed via the call stack rather than the heap memory unless the closure escapes the context of the original function \cite{nystrom2021}.
Additionally, \textit{upvalues} facilitate interoperability with other programming languages. Lua can be easily embedded through its C API, and when implementing external libraries in C, programmers can access the upvalues of the Lua runtime, not just the stack values available via the C API.
In addition, \textit{upvalues} facilitate interoperability with other programming languages. Lua can be easily embedded through its C API, and when implementing external libraries in C, programmers can access the upvalues of the Lua runtime, not just the stack values available via the C API.
\subsection{Instruction Set}
\label{sec:instruction}
The VM instructions for \lambdammm\ differ from those of the Lua VM in the following aspects.
The VM instructions for \lambdammm\ differ from those for the Lua VM in the following aspects:
\begin{enumerate}
\item Since mimium is a statically typed language, unlike Lua, instructions for basic arithmetic operations are provided for each type\footnote{In the actual implementation, instructions such as \texttt{MOVE} include an additional operand to specify the word size of values, particularly for handling aggregate types like tuples.}.
\item The call operation is split into normal function calls and closure calls, due to the static typing, and to manage higher-order stateful functions (see \ref{sec:vmstructure} for details).
\item The call operation is split into normal function calls and closure calls owing to the static typing and to manage higher-order stateful functions (see \ref{sec:vmstructure} for details).
\item Conditional statements are implemented using a combination of two instructions, \texttt{JMP} and \texttt{JMPIFNEG}, whereas the Lua VM employs a dedicated \texttt{TEST} instruction.
\item Instructions related to for-loops, the \texttt{SELF} instruction used in object-oriented programming, and the \texttt{TABLE}-related instructions for metadata references to variables are omitted in mimium as they are unnecessary.
\item Instructions related to list-like data structures are also excluded from this paper, as the implementation of data structures such as tuples and arrays is outside the scope of the \lambdammm\ description here.
\end{enumerate}
The VM for \lambdammm\ operates as a register machine, similar to the Lua VM (post version 5). However, unlike traditional register machines, it does not employ physical registers; instead, the register number simply refers to an offset index on the call stack relative to the base pointer during VM execution. The first operand of most instructions specifies the register number where the result of the operation will be stored.
The VM for \lambdammm\ operates as a register machine similar to the Lua VM (post version 5). However, unlike traditional register machines, it does not employ physical registers. Instead, the register number simply refers to an offset index on the call stack relative to the base pointer during VM execution. The first operand of most instructions specifies the register number where the result of the operation is stored.
The list of instructions is presented in Figure \ref{fig:instruction} (basic arithmetic operations are partially omitted). The notation for the instructions follows the format outlined in the Lua VM documentation \cite[p.13]{ierusalimschy2005}. From left to right, the operation name, a list of operands, and the pseudo-code of the operation are displayed. When each of the three operands is used as an unsigned 8-bit integer, they are represented as \texttt{A B C}. If an operand is used as a signed integer, it is prefixed with \texttt{s}. When two operand fields are combined into a 16-bit value, the suffix \texttt{x} is added. For example, when \texttt{B} and \texttt{C} are merged and treated as a signed 16-bit value, they are represented as \texttt{sBx}.
In the pseudo-code, \texttt{R(A)} denotes data being moved in and out of the register (or call stack) at the base pointer + \texttt{A} for the current function. \texttt{K(A)} refers to the \texttt{A}-th entry in the static variable section of the compiled program, and \texttt{U(A)} accesses the \texttt{A}-th upvalue of the current function.
A list of instructions is presented in Figure \ref{fig:instruction} (basic arithmetic operations are partially omitted). The notation for the instructions follows the format outlined in the Lua VM documentation \cite[p.13]{ierusalimschy2005}. The operation name, list of operands, and pseudocode of the operation are displayed from left to right. When each of the three operands is used as an unsigned 8-bit integer, it is represented as \texttt{A B C}. If an operand is used as a signed integer, then it is prefixed with \texttt{s}. When the two operand fields are combined into a 16-bit value, the suffix \texttt{x} is added. For example, when \texttt{B} and \texttt{C} are merged and treated as a signed 16-bit value, they are represented as \texttt{sBx}.
In the pseudocode, \texttt{R(A)} denotes the data being moved in and out of the register (or call stack) at the base pointer + \texttt{A} for the current function. \texttt{K(A)} refers to the \texttt{A}-th entry in the static variable section of the compiled program, and \texttt{U(A)} accesses the \texttt{A}-th upvalue of the current function.
In addition to Lua’s upvalue operations, four new operations— \texttt{GETSTATE}, \texttt{SETSTATE}, \texttt{SHIFTSTATE}, and \texttt{DELAY} —have been introduced to handle the compilation of the $delay$ and $feed$ expressions in \lambdammm.
\begin{figure*}[ht]
@@ -130,7 +129,7 @@
SHIFTSTATE* & sAx & SPos += sAx \\
DELAY* & A B C & R(A) := update\_ringbuffer(SPtr[SPos],R(B),R(C)) \\
\multicolumn{3}{l}{
\textit{ *((SPos,SPtr)= vm.closures[vm.statepos\_stack.top()].state }
\textit{ *(SPos,SPtr)= vm.closures[vm.statepos\_stack.top()].state }
}\\
\multicolumn{3}{l}{
\textit{\quad if vm.statepos\_stack is empty, use global state storage.)}
@@ -152,7 +151,7 @@
ADDI & A B C & R(A) := R(B) as int + R(C) as int \\
\ &
\multicolumn{2}{l}{
\textit{...Other basic arithmetics continues for each primitive types...}
\textit{...Other basic arithmetic continues for each primitive types...}
}
\end{tabular}
\caption{\label{fig:instruction}{\it Instruction sets for VM to run $\lambda_{mmm}$.}}
@@ -161,19 +160,19 @@
\subsection{Overview of the VM Structure}
\label{sec:vmstructure}
The overall structure of the virtual machine (VM), program, and instantiated closures for \lambdammm\ is depicted in Figure \ref{fig:vmstructure}. In addition to the usual call stack, the VM has a dedicated storage area (a flat array) to manage internal state data for feedback and delay.
The overall structure of the virtual machine (VM), program, and instantiated closures for \lambdammm\ is depicted in Figure \ref{fig:vmstructure}. In addition to the usual call stack, the VM has a dedicated storage area (a flat array) to manage the internal state data for feedback and delay.
This storage area is accompanied by pointers indicating the positions from which internal state data are retrieved via the \\ \texttt{GETSTATE} and \texttt{SETSTATE} instructions. These positions are shifted forward or backward using the \texttt{SHIFTSTATE} instruction. The actual data layout in the state storage memory is statically determined during compilation by analyzing function calls involving references to \texttt{self}, \texttt{delay}, and other stateful functions, including those that invoke such functions recursively. The \texttt{DELAY} operation takes two inputs: \texttt{B}, representing the input value, and \texttt{C}, representing the delay time in samples.
This storage area is accompanied by pointers that indicate the positions from which the internal state data are retrieved via the \\ \texttt{GETSTATE} and \texttt{SETSTATE} instructions. These positions are shifted forward or backward using the \texttt{SHIFTSTATE} instruction. The actual data layout in the state storage memory is statically determined during compilation by analyzing function calls involving references to \texttt{self}, \texttt{delay}, and other stateful functions, including those that recursively invoke such functions. The \texttt{DELAY} operation takes two inputs: \texttt{B}, representing the input value, and \texttt{C}, representing the delay time in the samples.
However, for higher-order functions—functions that take another function as an argument or return one—the internal state layout of the passed function is unknown at compile time. As a result, a separate internal state storage area is allocated for each instantiated closure, distinct from the global storage area maintained by the VM instance. The VM also uses an additional stack to keep track of pointers to the state storage of instantiated closures. Each time a \texttt{CALLCLS} operation is executed, the VM pushes the pointer to the closure's state storage onto the state stack. Upon completion of the closure call, the VM pops the state pointer off the stack.
However, for higher-order functions—functions that take another function as an argument or return one—the internal state layout of the passed function is unknown at compile time. Consequently, a separate internal state storage area is allocated to each instantiated closure, which is distinct from the global storage area maintained by the VM instance. The VM also uses an additional stack to keep track of the pointers in the state storage of instantiated closures. Each time a \texttt{CALLCLS} operation is executed, the VM pushes the pointer from the state storage of the closure onto the state stack. Upon completing the closure call, the VM pops the state pointer off the stack.
Instantiated closures also maintain their own storage area for upvalues. Until a closure exits the context of its parent function (known as an ``Open Closure''), its upvalues hold a negative offset that references the current execution's stack. This offset is determined at compile time and stored in the function's prototype in the program. Additionally, an upvalue may reference not only local variables but also upvalues from the parent function (a situation that arises when at least three functions are nested). Thus, the array of upvalue indices in the function prototype stores a pair of values: a tag indicating whether the value is a local stack variable or an upvalue from a parent function, and the corresponding index (either the negative stack offset or the parent function's upvalue index).
Instantiated closures also maintain their own storage areas for upvalues. Until a closure exits the context of its parent function (known as an ``Open Closure''), its upvalues hold a negative offset that references the current execution's stack. This offset is determined at compile time and stored in the function's prototype in the program. Furthermore, an upvalue may reference not only local variables but also upvalues from the parent function (a situation that arises when at least three functions are nested). Thus, the array of upvalue indices in the function prototype stores a pair of values: a tag indicating whether the value is a local stack variable or an upvalue from a parent function and the corresponding index (either the negative stack offset or the parent function's upvalue index).
For example, consider a scenario where the upvalue indices in the program are specified as \texttt{[upvalue(1), local(3)]}. In this case, the instruction \texttt{GETUPVALUE 6 1} indicates that the value located at index \texttt{3} from the upvalue list (referenced by \\ \texttt{upvalue(1)}) should be retrieved from \texttt{R(-3)} relative to the base pointer, and the result should be stored in \texttt{R(6)}.
When a closure escapes its original function context through the \texttt{RETURN} instruction, the inserted \texttt{CLOSE} instruction moves the active upvalues from the stack to the heap memory. These upvalues may be referenced from multiple locations, especially in cases involving nested closures. As such, a garbage collection mechanism is required to free memory once these upvalues are no longer in use.
When a closure escapes its original function context through the \texttt{RETURN} instruction, the inserted \texttt{CLOSE} instruction moves the active upvalues from the stack to heap memory. These upvalues may be referenced from multiple locations, particularly in cases involving nested closures. Thus, a garbage collection mechanism is required to free memory once these upvalues are no longer in use.
In \lambdammm's VM, since the paradigm is call-by-value and there is no reassignment expression, the \texttt{SETUPVALUE} instruction is omitted. If reassignment were allowed, the open upvalues would need to be implemented as shared memory cells, as the values might be accessed by multiple closures that could trigger a \texttt{CLOSE} operation.
In \lambdammm's VM, since the paradigm is call-by-value and there is no reassignment expression, the \texttt{SETUPVALUE} instruction is omitted. If reassignment is allowed, open upvalues would need to be implemented as shared memory cells, as the values might be accessed by multiple closures that could trigger a \texttt{CLOSE} operation.
\begin{figure*}[ht]
\centerline{\includegraphics[width=\hsize]{lambdammm_vm_structure}}
@@ -199,15 +198,15 @@
RETURN 3 1
\end{lstlisting}
Listing \ref{lst:bytecodes_onepole} shows a basic example of how the mimium code in Listing \ref{lst:onepole} is compiled into VM bytecode. When \texttt{self} is referenced, the value is retrieved using the \texttt{GETSTATE} instruction, and the internal state is updated by storing the return value with the \texttt{SETSTATE} instruction before returning it via the \texttt{RETURN} instruction. In this case, the actual return value is obtained by the second \texttt{GETSTATE} instruction, which ensures that the initial state value is returned when time = 0.
Listing \ref{lst:bytecodes_onepole} shows a basic example of how the mimium code in Listing \ref{lst:onepole} is compiled into VM bytecode. When \texttt{self} is referenced, the value is retrieved using the \texttt{GETSTATE} instruction, and the internal state is updated by storing the return value with the \texttt{SETSTATE} instruction before returning it via the \texttt{RETURN} instruction. In this case, the actual return value is obtained using the second \texttt{GETSTATE} instruction, which ensures that the initial state value is returned at time = 0.
For example, if a time counter is written as \texttt{| | {self + 1}}, the decision on whether the return value at time = 0 should be 0 or 1 is left to the compiler design. Though returning 1 does not strictly follow the semantics of E-FEED in Figure \ref{fig:semantics}, if the compiler is designed to return 1 at time = 0, the second \texttt{GETSTATE} instruction can be omitted, and the value for the \texttt{RETURN} instruction should be \texttt{R(2)}.
For example, if a time counter is written as \texttt{| | {self + 1}}, the decision on whether the return value at time = 0 should be 0 or 1 is left to the compiler design. Although returning 1 does not strictly follow the semantics of E-FEED in Figure \ref{fig:semantics}, if the compiler is designed to return 1 at time = 0, the second \texttt{GETSTATE} instruction can be omitted, and the value for the \texttt{RETURN} instruction should be \texttt{R(2)}.
A more complex example, along with its expected bytecode instructions, is shown in Listings \ref{lst:fbdelay} and \ref{lst:bytecodes_fbdelay}. The code defines a delay with feedback as \texttt{fbdelay}, while another function, \texttt{twodelay}, uses two feedback delays with different parameters. Finally, \texttt{dsp} uses two \texttt{twodelay} functions.
After each reference to \texttt{self} through the \texttt{GETSTATE} instruction, or after calling another stateful function, the \texttt{SHIFTSTATE} instruction is inserted to advance the state storage position in preparation for the next non-closure function call. Before the function exits, the state position is reset to where it was at the beginning of the current function context by using the \texttt{SHIFTSTATE} instruction. The total operand value for \texttt{SHIFTSTATE} within a function must always sum to 0. Figure \ref{fig:fbdelay_spos} illustrates how the state position shifts with \texttt{SHIFTSTATE} operations during the execution of the \texttt{twodelay} function.
After each reference to \texttt{self} through the \texttt{GETSTATE} instruction or after calling another stateful function, the \texttt{SHIFTSTATE} instruction is inserted to advance the state storage position in preparation for the next non-closure function call. Before the function exits, the state position is reset to where it was at the beginning of the current function context using the \texttt{SHIFTSTATE} instruction. The total operand value for \texttt{SHIFTSTATE} within a function must always sum to 0. Figure \ref{fig:fbdelay_spos} illustrates how the state position shifts with the \texttt{SHIFTSTATE} operations during the execution of the \texttt{twodelay} function.
By representing the internal state as a relative position within state storage, the state data can be stored as a flat array, simplifying the compiler implementation. This avoids the need to generate a tree structure from the root, which was required in the previous implementation of mimium. This approach is similar to how upvalues simplify compiler implementation by treating free variables as relative positions on the call stack.
The state data can be stored as a flat array by representing the internal state as a relative position within the state storage, thereby simplifying compiler implementation; this avoids the need to generate a tree structure from the root, which was required in the previous implementation of mimium. This approach is similar to how upvalues simplify the compiler implementation by treating free variables as relative positions on the call stack.
\begin{lstlisting}[float,floatplacement=H,label=lst:fbdelay,language=Rust,caption=\it Example code that combines self and delay without closure call.]
fn fbdelay(x,fb,dtime){
@@ -275,10 +274,9 @@
\caption{\label{fig:fbdelay_spos}{\it Image of how the state position moves while executing \texttt{twodelay} function in Listing \ref{lst:bytecodes_fbdelay}.}}
\end{figure}
Listing \ref{lst:filterbank_good} shows an example of a higher-order function \\ \texttt{filterbank}, which takes another function \texttt{filter}—accepting an input and a frequency as arguments—duplicates \texttt{n} instances of \texttt{filter} and adds them together. In the previous specification of mimium \cite{matsuura2021a}, the syntax for the variable binding and destructive assignment was the same (\texttt{x = a}). However, in the current syntax, variable binding uses the \texttt{let} keyword. In addition, because semantics follow a call-by-value paradigm, reassignment syntax is no longer used in the current implementation.
Listing \ref{lst:filterbank_good} shows an example of a higher-order function \\ \texttt{filterbank}, which takes another function \texttt{filter}—accepting an input and a frequency as arguments—duplicates \texttt{n} instances of \texttt{filter}, and adds them together. Note that in the previous specification of mimium \cite{matsuura2021a}, the syntax for variable binding and destructive assignment was the same (\texttt{x = a}). However, in the current syntax, variable binding now uses the \texttt{let} keyword. Additionally, since the semantics follow a call-by-value paradigm, reassignment syntax is no longer used in the current implementation.
The previous mimium compiler was unable to compile code that took a function with an internal state as an argument because the entire tree of internal states had to be statically determined at compile time. However, the VM in \lambdammm\ can manage this dynamically. Listing \ref{lst:bytecode_filterbank} shows the translated VM instructions for this code. Recursive calls on the first line of \texttt{filterbank}, as well as calls to functions passed as arguments or obtained through upvalues (like \texttt{filter}), are executed using the \texttt{CALLCLS} instruction rather than the \texttt{CALL} instruction. The \texttt{GETSTATE} and \texttt{SETSTATE} instructions are not used in this function, as the internal state storage is switched dynamically when the \texttt{CALLCLS} instruction is interpreted.
The previous mimium compiler was unable to compile code that took a function with an internal state as an argument because the entire tree of internal states had to be statically determined at compile time. However, the VM in \lambdammm\ can handle this dynamically. Listing \ref{lst:bytecode_filterbank} shows the translated VM instructions for this code. Recursive calls on the first line of \texttt{filterbank}, as well as calls to functions passed as arguments or obtained through upvalues (like \texttt{filter}), are executed using the \texttt{CALLCLS} instruction rather than the \texttt{CALL} instruction. The \texttt{GETSTATE} and \texttt{SETSTATE} instructions are not used in this function because the internal state storage is switched dynamically when the \texttt{CALLCLS} instruction is interpreted.
\begin{lstlisting}[float,floatplacement=H,label=lst:filterbank_good,language=Rust,caption=\it Example code that duplicates filter parametrically using a recursive function and closure.]
fn bandpass(x,freq){
@@ -346,14 +344,11 @@
\section{Discussion}
\label{sec:discussion}
Here’s the revised version of the text, ensuring that all references inside curly brackets remain unchanged:
As demonstrated in the example of the filterbank, in \lambdammm, a signal graph can be parametrically generated during the evaluation of the global context, whereas Faust uses a term-rewriting macro and Kronos employs type-level computation, as shown in Table \ref{tab:comparison}.
The ability to describe both the generation of parametric signal processing and its execution content within a single semantics makes it easier for novice users to grasp the mechanics of the language. Additionally, having a unified semantics may simplify run-time interoperability with other general-purpose languages.
The ability to describe both the generation of parametric signal processing and its execution content within single semantics makes it easier for novice users to understand the mechanics of the language. In addition, unified semantics may simplify runtime interoperability with other general-purpose languages.
However, there is a drawback: the unified semantics can cause \lambdammm\ to deviate from the behavior typically expected in standard lambda calculus.
However, there is a drawback: unified semantics can cause \lambdammm\ to deviate from the behavior typically expected in standard lambda calculus.
\begin{table}[ht]
\centering
@@ -369,15 +364,15 @@
\subsection{Different Behaviour Depending on the Location of Let Binding}
\label{sec:letbinding}
By using functions with internal states that change over time in mimium, there is a counterintuitive behavior when higher-order functions are used, compared to general functional programming languages.
By using functions with internal states that change over time in mimium, there is counterintuitive behavior when higher-order functions are used compared to general functional programming languages.
Listing \ref{lst:filterbank_bad} presents an example of incorrect code, slightly modified from the filterbank example in Listing \ref{lst:filterbank_good}. The main difference between Listing \ref{lst:filterbank_bad} and Listing \ref{lst:filterbank_good} is whether the recursive calls in the \texttt{filterbank} function are written directly or are bound using a \texttt{let} expression outside of the inner function. Similarly, in the \texttt{dsp} function, which is called by the audio driver in mimium, the difference lies in whether the \texttt{filterbank} function is executed within \texttt{dsp} or bound with \texttt{let} once in the global context.
Listing \ref{lst:filterbank_bad} presents an example of incorrect code that is slightly modified from the filterbank example in Listing \ref{lst:filterbank_good}. The main difference between Listing \ref{lst:filterbank_bad} and Listing \ref{lst:filterbank_good} is whether the recursive calls in the \texttt{filterbank} function are written directly or bound using a \texttt{let} expression outside the inner function. Similarly, in the \texttt{dsp} function, which is called by the audio driver in mimium, the difference lies in whether the \texttt{filterbank} function is executed within \texttt{dsp} or bound with \texttt{let} once in the global context.
In a typical functional programming language, as long as none of the functions in the composition involve destructive assignments, the calculation process remains unchanged even if the variable bound by \texttt{let} is replaced with its term (via beta reduction), as seen in the transformation from Listing \ref{lst:filterbank_bad} to Listing \ref{lst:filterbank_good}.
In a typical functional programming language, if none of the functions in the composition involve destructive assignments, the calculation process remains unchanged even if the variable bound by \texttt{let} is replaced with its term (via beta reduction), as seen in the transformation from Listing \ref{lst:filterbank_bad} to Listing \ref{lst:filterbank_good}.
However, in mimium, there are two distinct stages of evaluation. 0: The code is first evaluated in the global environment (where the signal processing graph is concretized). 1: The \texttt{dsp} function is executed repeatedly (handling actual signal processing), and may involve implicit updates to internal states.
However, in mimium, there are two distinct stages of evaluation. 0: The code is first evaluated in a global environment (where the signal-processing graph is concretized). 1: The \texttt{dsp} function is executed repeatedly (handling the actual signal processing) and may involve implicit updates to the internal states.
Even though the code contains no destructive assignments, the recursive execution of the \texttt{filterbank} function occurs only once in Listing \ref{lst:filterbank_good}, during the global environment evaluation. In contrast, in Listing \ref{lst:filterbank_bad}, the recursive function is executed and a closure is generated each time the \texttt{dsp} function runs on every sample. Since the internal state of the closure is initialized at the time of closure allocation, in the example of Listing \ref{lst:filterbank_bad}, the internal state of the closure is reset at each time step following the evaluation of \texttt{filterbank}.
Although the code contains no destructive assignments, the recursive execution of the \texttt{filterbank} function occurs only once in Listing \ref{lst:filterbank_good} during the global environment evaluation. Conversely, in Listing \ref{lst:filterbank_bad}, the recursive function is executed, and a closure is generated each time the \texttt{dsp} function runs on every sample. Because the internal state of the closure is initialized at the time of closure allocation, in the example of Listing \ref{lst:filterbank_bad}, the internal state of the closure is reset at each time step, following the evaluation of \texttt{filterbank}.
\begin{lstlisting}[float,floatplacement=H,label=lst:filterbank_bad,language=Rust,caption=\it Wrong example of the code that duplicate filter parametrically.]
fn filterbank(n,filter){
@@ -393,7 +388,6 @@
}
\end{lstlisting}
\begin{lstlisting}[float,floatplacement=H,label=lst:filterbank_multi,language=Rust,caption=\it Example of filterbank function using multi-stage computation in a future specification of mimium.]
fn filterbank(n,filter){
.< if (n>0){
@@ -408,28 +402,27 @@
}
\end{lstlisting}
This implies that major compiler optimization techniques, such as constant folding and function inlining, cannot be directly applied to mimium. These optimizations must be performed after the global context evaluation and before the evaluation of the \texttt{dsp} function.
This implies that major compiler optimization techniques, such as constant folding and function inlining, cannot be directly applied to mimium. These optimizations must be performed after global context evaluation and before the evaluation of the \texttt{dsp} function.
To address this issue, it would be necessary to introduce a distinction in the type system to indicate whether a term should be used during the global context evaluation (stage 0) or during actual signal processing (stage 1). This can be achieved with Multi-Stage Computation \cite{Taha1997}. Listing \ref{lst:filterbank_multi} provides an example of the \\ \texttt{filterbank} code using BER MetaOCaml’s syntax: \texttt{.<term>.}, which generates a program to be used in the next stage, and \texttt{\textasciitilde term}, which embeds terms evaluated in the previous stage \cite{kiselyov2014a}.
To address this issue, it is necessary to introduce a distinction in the type system to indicate whether a term should be used during global context evaluation (stage 0) or actual signal processing (stage 1). This can be achieved with Multi-Stage Computation \cite{Taha1997}. Listing \ref{lst:filterbank_multi} provides an example of the \\ \texttt{filterbank} code using BER MetaOCaml’s syntax: \texttt{.<term>.}, which generates a program to be used in the next stage, and \texttt{\textasciitilde term}, which embeds the terms evaluated in the previous stage \cite{kiselyov2014a}.
The \texttt{filterbank} function is evaluated in stage 0 while embedding itself with \texttt{\textasciitilde}. This multi-stage computation code retains the same semantics for both the generation of the signal processing graph and the execution of the signal processing, in contrast to Faust and Kronos.
The \texttt{filterbank} function is evaluated in stage 0 while embedding itself with \texttt{\textasciitilde}. In contrast to Faust and Kronos, this multi-stage computation code retains the same semantics for both the generation of the signal processing graph and the execution of signal processing.
\subsection{A Possibility of the Foreign Stateful Function Call}
The closure data structure in \lambdammm\ combines functions with internal states, as shown in Figure 3. The fact that \texttt{filterbank} samples do not require special handling for internal states means that external signal processors (Unit Generators: UGens), such as oscillators and filters written in C or C++, can be called from mimium just like normal closure calls. Additionally, it is possible to parametrize, duplicate, and combine external UGens. This capability is difficult to implement in Faust and similar languages but is easily achievable in the \lambdammm\ paradigm.
The closure data structure in \lambdammm\ combines functions with the internal states, as shown in Figure 3. The fact that \texttt{filterbank} samples do not require special handling for internal states means that external signal processors (Unit Generators: UGens), such as oscillators and filters written in C or C++, can be called from mimium, just like normal closure calls. Additionally, it is possible to parameterize, duplicate, and combine external UGens. This capability is difficult to implement in Faust and similar languages but is easily achievable in the \lambdammm\ paradigm.
However, mimium currently uses sample-by-sample processing and cannot handle buffer-by-buffer value passing. Since most native unit generators process data on a buffer-by-buffer basis, there are not many practical cases where external UGens are used at this time. Nonetheless, in \lambdammm, only $feed$ terms require sample-by-sample processing. It is therefore possible to differentiate functions that can only process one sample at a time from those that can process concurrently at the type level. As the multi-rate specification is being considered in Faust \cite{jouvelotDependentVectorTypes2011}, it may be possible to facilitate buffer-based processing between an external Unit Generator by having the compiler automatically determine which parts can be processed buffer-by-buffer.
However, mimium currently uses sample-by-sample processing and cannot handle buffer-by-buffer value passing. Because most native unit generators process data on a buffer-by-buffer basis, there are few practical cases where external UGens are currently used. Nonetheless, in \lambdammm, only $feed$ terms require sample-by-sample processing. Therefore, it is possible to differentiate the functions that can process only one sample at a time from those that can process concurrently at the type level. As the multi-rate specification is being considered in Faust \cite{jouvelotDependentVectorTypes2011}, it may be possible to facilitate buffer-based processing between an external Unit Generator by having the compiler automatically determine the parts that can be processed buffer-by-buffer.
\section{Conclusion}
\label{sec:conclusion}
This paper proposed \lambdammm, an intermediate representation for programming languages for music and signal processing, along with a virtual machine and instruction set to execute it. \lambdammm\ enables the description of generative signal graphs and their contents within a unified syntax and semantics. However, users are responsible for ensuring that their code does not create escapable closures during the iterative execution of DSP, which can be challenging for novice users to grasp.
This paper proposed \lambdammm, an intermediate representation for programming languages for music and signal processing, along with a virtual machine and an instruction set to execute it. \lambdammm\ enables the description of generative signal graphs and their contents within a unified syntax and semantics. However, users are responsible for ensuring that their code does not create escapable closures during the iterative execution of a DSP, which can be challenging for novice users to grasp.
In this paper, the translation of \lambdammm\ terms into VM instructions was illustrated by showing examples of code and the corresponding expected bytecode, alongside pseudo-code to describe the behavior of the VM. More formal semantics and a detailed translation process should be considered, especially with the introduction of multi-stage computation.
In this paper, the translation of \lambdammm\ terms into VM instructions was illustrated by showing examples of code and the corresponding expected bytecode alongside pseudocode to describe the behavior of the VM. More formal semantics and a detailed translation process should be considered, particularly with the introduction of multi-stage computation.
I hope that this research will contribute to more general representations of music and sound on digital computers and foster deeper connections between the theory of languages for music and the broader field of programming language theory.
\section{Acknowledgments}
This work was supported by JSPS KAKENHI (Grant No. \\JP19K21615). Also great thanks for many anonymous reviewers.
This study was supported by JSPS KAKENHI (Grant No. \\JP19K21615). I would also like to thank the many anonymous reviewers.

BIN
src/main.pdf
View File

Binary file not shown.