Dixin's Blog

C# Functional Programming In-Depth (14) Asynchronous Function

Tue, 04 Mar 2025 12:58:00 GMT

[LINQ via C# series]

[C# functional programming in-depth series]

Asynchronous function can improve the responsiveness and scalability of the application and service. C# 5.0 introduces asynchronous function to greatly simplify the async programming model.

Task, Task<TResult> and asynchrony

The C# async programming model uses System.Threading.Tasks.Task to represent async operation without output, and uses System.Threading.Tasks.Task<TResult> to represent async operation with TResult output:

namespace System.Threading.Tasks

{

public partial class Task : IAsyncResult

{

public Task(Action action); // Wraps () –> void function.

public void Start();

public void Wait();

public TaskStatus Status { get; } // Created, WaitingForActivation, WaitingToRun, Running, WaitingForChildrenToComplete, RanToCompletion, Canceled, Faulted.

public bool IsCanceled { get; }

public bool IsCompleted { get; }

public bool IsFaulted { get; }

public AggregateException Exception { get; }

Task ContinueWith(Action<Task> continuationAction);

Task<TResult> ContinueWith<TResult>(Func<Task, TResult> continuationFunction);

// Other members.

}

public partial class Task<TResult> : Task

{

public Task(Func<TResult> function); // Wraps () –> TResult function.

public TResult Result { get; }

public Task ContinueWith(Action<Task<TResult>> continuationAction);

public Task<TNewResult> ContinueWith<TNewResult>(

Func<Task<TResult>, TNewResult> continuationFunction);

// Other members.

}

Task can be constructed with () –>void function, and Task<TResult> can be constructed with () –> TResult function. They can be started by calling the Start method. A () –> void function or () –> TResult function runs synchronously on the thread. In contrast, a task runs asynchronously, and does not block the current thread. Its status can be queried by the Status, IsCanceled, IsCompleted, IsFaulted properties. A task can be waited by calling its Wait method, which blocks the current thread until the task is completed successfully, or fails, or is cancelled. For Task<TResult>, when the underlying async operation is completed successfully, the result is available through Result property. For Task or Task<TResult>, if the underlying async operation fails with exception, the exception is available through the Exception property. A task can be chained with another async continuation operation by calling the ContinueWith methods. When the task finishes running, the specified continuation starts running asynchronously. If the task already finishes running when its ContinueWith method is called, then the specified continuation immediately starts running. The following example constructs and starts a task to read a file, and chains another continuation task to write the contents to another file:

internal static partial class Functions

{

internal static void ConstructTask(string readPath, string writePath)

{

Thread.CurrentThread.ManagedThreadId.WriteLine(); // 10

Task<string> task = new Task<string>(() =>

{

Thread.CurrentThread.ManagedThreadId.WriteLine(); // 8

return File.ReadAllText(readPath);

});

task.Start();

Task continuationTask = task.ContinueWith(antecedentTask =>

{

Thread.CurrentThread.ManagedThreadId.WriteLine(); // 9

object.ReferenceEquals(antecedentTask, task).WriteLine(); // True

if (antecedentTask.IsFaulted)

{

antecedentTask.Exception.WriteLine();

}

else

{

File.WriteAllText(writePath, antecedentTask.Result);

}

});

continuationTask.Wait();

}

As async operations, when tasks are started, the wrapped functions are by default scheduled to runtime’s thread pool to execute, so that their thread ids are different from the caller thread id.

In .NET Framework, Task also implements System.Threading.IThreadPoolWorkItem and IDisposable interfaces. Its usage is the same as in .NET Core. Do not bother disposing tasks.

Task also provides Run methods to construct and automatically start tasks:

namespace System.Threading.Tasks

{

public partial class Task : IAsyncResult

{

public static Task Run(Action action);

public static Task<TResult> Run<TResult>(Func<TResult> function);

}

Now compare the following functions:

internal static void Write(string path, string contents) => File.WriteAllText(path, contents);

internal static string Read(string path) => File.ReadAllText(path);

internal static Task WriteAsync(string path, string contents) =>

Task.Run(() => File.WriteAllText(path, contents));

internal static Task<string>ReadAsync(string path) => Task.Run(() => File.ReadAllText(path));

Write without output and Read with string output run synchronously. WriteAsync with Task output and ReadAsync with Task<string> output run asynchronously, where Task can be viewed as future void, and Task<TResult> can be viewed as future TResult result. Here WriteAsync and ReadAsync become async by simply offloading the operations to thread pool. This is for demonstration purpose, and does not bring any scalability improvement. A better implementation is discussed later.

internal static void CallReadWrite(string path, string contents)

{

Write(path, contents); // Blocking.

// When the underlying write operation is done, the call is completed with no result.

string result = Read(path); // Blocking.

// When the underlying read operation is done, the call is completed with result available.

Task writeTask = WriteAsync(path, contents); // Non-blocking.

// When the task is constructed and started, the call is completed immediately.

// The underlying write operation is scheduled, and will be completed in the future with no result.

Task<string> readTask = ReadAsync(path); // Non-blocking.

// When the task is constructed and started, the call is completed immediately.

// The underlying read operation is scheduled, and will be completed in the future with result available.

}

When Write is called, its execution blocks the current thread. When the writing operation is done synchronously, it does not output any result, and then the caller thread can continue execution. Similarly, when Read is called, its execution blocks the current thread too. When the reading operation is done synchronously, it outputs the result, so that the result is available to the caller and the caller can continue execution. When WriteAsync is called, it calls Task.Run to construct a Task instance with the writing operation, start the task, then immediately outputs the task to the caller. Then the caller can continue without being blocked by the writing operation execution. By default, the writing operation is scheduled to thread pool, when it is done, the writing operation outputs no result, and the task’s Status is updated. Similarly, when ReadAsync is called, it also calls Task.Run to construct a Task<string> instance with the reading operation, start the task, then immediately outputs the task to the caller. Then the caller can continue without being blocked by the reading operation execution. By default, the reading operation is also scheduled to thread pool, when it is done, the reading operation has a result, and the task’s Status is updated, with the result available through the Result property.

Named async function

By default, named async function’s output type is Task or Task<TResult>, and has an Async or AsyncTask postfix in the name as the convention. The following example is a file read and write workflow of sync function calls:

internal static void ReadWrite(string readPath, string writePath)

{

string contents = Read(readPath);

Write(writePath, contents);

}

The same logic can be implemented by calling the async version of functions:

internal static async Task ReadWriteAsync(string readPath, string writePath)

{

string contents = await ReadAsync(readPath);

await WriteAsync(writePath, contents);

}

Here await keyword is used for each async function call, and the code structure remains the same as the sync workflow. When await keyword is used in function body, the async modifier is required for that function’s signature. Regarding the workflow outputs no result, the async function outputs Task (future void). This ReadWriteAsync function calls async functions, itself is also async function, since it has the async modifier and Task output. When ReadWriteAsync is called, it works the same way as ReadAsync and WriteAsync. it does not block its caller, and immediately outputs a task to represent the scheduled read and write workflow.

So the await keyword can be viewed as virtually waiting for the task’s underlying async operation to finish. If the task fails, exception is thrown. If the task is completed successfully, the continuation right after the await expression is called back. If the task has a result, await expression can extract the result. Therefore, the async workflow keeps the same looking of sync workflow. There is no ContinueWith call needed to build the continuation. The following example is a more complex database query workflow of sync function calls, with an int value as the query result:

internal static int Query(DbConnection connection, StreamWriter logWriter) // Output int.

{

try

{

connection.Open(); // Output void.

using (DbCommand command = connection.CreateCommand())

{

command.CommandText = "SELECT 1;";

using (DbDataReader reader = command.ExecuteReader()) // Output DbDataReader.

{

if (reader.Read()) // Output bool.

{

return (int)reader[0];

}

throw new InvalidOperationException("Failed to call sync functions.");

}

catch (SqlException exception)

{

logWriter.WriteLine(exception.ToString()); // Output void.

throw new InvalidOperationException("Failed to call sync functions.", exception);

}

Here the DbConnection.Open, DbCommand.ExecuteReader, DbDataReader.Read, StreamWriter.WriteLine functions have async version provided as DbConnection.OpenAsync, DbCommand.ExecuteReaderAsync, DbDataReader.ReadAsync, StreamWriter.WriteLineAsync. They output either Task or Task<TResult>. With the async and await keywords, it easy to call these async functions:

internal static async Task<int> QueryAsync(

DbConnection connection, StreamWriter logWriter) // Output Task<int> instead of int.

{

try

{

await connection.OpenAsync(); // Output Task instead of void.

using (DbCommand command = connection.CreateCommand())

{

command.CommandText = "SELECT 1;";

using (DbDataReader reader = await command.ExecuteReaderAsync()) // Output Task<DbDataReader> instead of DbDataReader.

{

if (await reader.ReadAsync()) // Output Task<bool> instead of bool.

{

return (int)reader[0];

}

throw new InvalidOperationException("Failed to call async functions.");

}

catch (SqlException exception)

{

await logWriter.WriteLineAsync(exception.ToString()); // Output Task instead of void.

throw new InvalidOperationException("Failed to call async functions.", exception);

}

Again, the async workflow persists the same code structure as the sync workflow, including try-catch, using, if statements, etc. Without this syntax, it is a lot more complex to call ContinueWith and manually build above workflow. Regarding the async function has an int result, its output type is Task<int> (future int).

The above Write and Read functions calls File.WriteAllText and File.ReadAllText to execute sync I/O operation, which are internally implemented by calling StreamWriter.Write and StreamReader.ReadToEnd. Now with the async and await keywords, WriteAsync and ReadAsync can be reimplemented as real async I/O (assuming async I/O is actually supported by the underlying operating system) by calling StreamWriter.WriteAsync and StreamReader.ReadToEndAsync:

internal static async Task WriteAsync(string path, string contents)

{

// File.WriteAllText implementation:

// using (StreamWriter writer = new StreamWriter(new FileStream(

// path: path, mode: FileMode.Create, access: FileAccess.Write,

// share: FileShare.Read, bufferSize: 4096, useAsync: false)))

// {

// writer.Write(contents);

// }

using (StreamWriter writer = new StreamWriter(new FileStream(

path: path, mode: FileMode.Create, access: FileAccess.Write,

share: FileShare.Read, bufferSize: 4096, useAsync: true)))

{

await writer.WriteAsync(contents);

}

internal static async Task<string>ReadAsync(string path)

{

// File.ReadAllText implementation:

// using (StreamReader reader = new StreamReader(new FileStream(

// path: path, mode: FileMode.Open, access: FileAccess.Read,

// share: FileShare.Read, bufferSize: 4096, useAsync: false)))

// {

// return reader.ReadToEnd();

// }

using (StreamReader reader = new StreamReader(new FileStream(

path: path, mode: FileMode.Open, access: FileAccess.Read,

share: FileShare.Read, bufferSize: 4096, useAsync: true)))

{

return await reader.ReadToEndAsync();

}

There is one special scenario where async function has void output – async function as event handler. For example, ObservableCollection<T> has a CollectionChanged event:

namespace System.Collections.ObjectModel

{

public class ObservableCollection<T> : Collection<T>, INotifyCollectionChanged, INotifyPropertyChanged

{

public event NotifyCollectionChangedEventHandler CollectionChanged;

// Other members.

}

namespace System.Collections.Specialized

{

// (object, NotifyCollectionChangedEventArgs) –> void.

public delegate void NotifyCollectionChangedEventHandler(

object sender, NotifyCollectionChangedEventArgs e);

}

This event requires its handler to be a function of type (object, NotifyCollectionChangedEventArgs) –> void. So, when defining an async function as the above event’s handler, that async function has void output instead of Task:

private static readonly StringBuilder Logs = new StringBuilder();

private static readonly StringWriter LogWriter = new StringWriter(logs);

// (object, NotifyCollectionChangedEventArgs) –> void.

private static async void CollectionChangedAsync(

object sender, NotifyCollectionChangedEventArgs e) =>

await LogWriter.WriteLineAsync(e.Action.ToString());

internal static void AddEventHandler()

{

ObservableCollection<int> collection = new ObservableCollection<int>();

collection.CollectionChanged += CollectionChangedAsync;

collection.Add(1); // Fires CollectionChanged event.

}

The await keyword works with task from async function as well as any Task and Task<TResult> instance:

internal static async Task AwaitTasks(string path)

{

Task<string> task1 = ReadAsync(path);

string contents = await task1;

// Equivalent to: string contents = await ReadAsync(path);

Task task2 = WriteAsync(path, contents);

await task2;

// Equivalent to: await WriteAsync(path, contents);

Task task3 = Task.Run(() => { });

await task3;

// Equivalent to: await Task.Run(() => { });

Task<int> task4 = Task.Run(() => 0);

int result = await task4;

// Equivalent to: int result = await Task.Run(() => 0);

Task task5 = Task.Delay(TimeSpan.FromSeconds(10));

await task5;

// Equivalent to: await Task.Delay(TimeSpan.FromSeconds(10));

Task<int> task6 = Task.FromResult(result);

result = await task6;

// Equivalent to: result = await Task.FromResult(result);

}

If a task is never started, apparently it never finishes running. The code after its await expression is never called back:

internal static async Task HotColdTasks(string path)

{

Task hotTask = new Task(() => { });

hotTask.Start();

await hotTask;

hotTask.Status.WriteLine();

Task coldTask = new Task(() => { });

await coldTask;

coldTask.Status.WriteLine(); // Never execute.

}

Task not started yet is called cold task, and task already started is called hot task. As a convention, any function with task output should always output a hot task. All APIs in .NET Standard follow this convention.

Awaitable-awaiter pattern

C# compiles the await expression with the awaitable-awaiter pattern. Besides Task and Task<TResult>, the await keyword can be used with any awaitable type. An awaitable type has a GetAwaiter instance or extension method to output an awaiter. An awaiter type implements System.Runtime.CompilerServices.INotifyCompletion interface, also has an IsCompleted property with bool output, and a GetResult instance method with or without output. The following IAwaitable and IAwaiter interfaces demonstrate the awaitable-awaiter pattern for operation with no result:

public interface IAwaitable

{

IAwaiter GetAwaiter();

}

public interface IAwaiter : INotifyCompletion

{

bool IsCompleted { get; }

void GetResult(); // No result.

}

And the following IAwaitable<TResult> and IAwaiter<TResult> interfaces demonstrate the awaitable-awaiter pattern for operations with a result:

public interface IAwaitable<TResult>

{

IAwaiter<TResult>GetAwaiter();

}

public interface IAwaiter<TResult>: INotifyCompletion

{

bool IsCompleted { get; }

TResult GetResult(); // TResult result.

}

And INotifyCompletion interface has a single OnCompleted method to chain a continuation:

namespace System.Runtime.CompilerServices

{

public interface INotifyCompletion

{

void OnCompleted(Action continuation);

}

Here is how Task and Task<TResult> implement the awaitable-awaiter pattern. Task can be virtually viewed as implementation of IAwaitable, it has a GetAwaiter instance method outputting System.Runtime.CompilerServices.TaskAwaiter, which can be virtually viewed as implementation of IAwaiter; Similarly, Task<TResult> can be virtually viewed as implementation of IAwaitable<TResult>, it has a GetAwaiter method outputting System.Runtime.CompilerServices.TaskAwaiter<TResult>, which can be virtually viewed as implementation of IAwaiter<TResult>:

namespace System.Threading.Tasks

{

public partial class Task : IAsyncResult

{

public TaskAwaiter GetAwaiter();

}

public partial class Task<TResult> : Task

{

public TaskAwaiter<TResult> GetAwaiter();

}

namespace System.Runtime.CompilerServices

{

public struct TaskAwaiter : ICriticalNotifyCompletion, INotifyCompletion

{

public bool IsCompleted { get; }

public void GetResult(); // No result.

public void OnCompleted(Action continuation);

// Other members.

}

public struct TaskAwaiter<TResult> : ICriticalNotifyCompletion, INotifyCompletion

{

public bool IsCompleted { get; }

public TResult GetResult(); // TResult result.

public void OnCompleted(Action continuation);

// Other members.

}

Any other type can be used with the await keyword, as long as the awaitable-awaiter pattern is implemented. Take delegate type Action as example, a GetAwaiter method can be easily implemented as its extension method, by reusing above TaskAwaiter:

public static TaskAwaiter GetAwaiter(this Action action) => Task.Run(action).GetAwaiter();

Similarly, this pattern can be implemented for Func<TResult>, by reusing TaskAwaiter<TResult>:

public static TaskAwaiter<TResult> GetAwaiter<TResult>(this Func<TResult> function) =>

Task.Run(function).GetAwaiter();

Now the await keyword can be directly used with a function of Action type or Func<TResult> type:

internal static async Task AwaitFunctions(string readPath, string writePath)

{

Func<string>read = () => File.ReadAllText(readPath);

string contents = await read;

Action write = () => File.WriteAllText(writePath, contents);

await write;

}

Async state machine

As fore mentioned, with async and await keywords, an async function outputs a task immediately, so it is non-blocking. At compile time, the workflow of an async function is compiled to an async state machine. At runtime, when this async function is called, it just starts that generated async state machine , and immediately outputs a task representing the workflow in the async state machine. To demonstrate this, define the following async methods:

internal static async Task<T> Async<T>(T value)

{

T value1 = Start(value);

T result1 = await Async1(value1);

T value2 = Continuation1(result1);

T result2 = await Async2(value2);

T value3 = Continuation2(result2);

T result3 = await Async3(value3);

T result = Continuation3(result3);

return result;

}

internal static T Start<T>(T value) => value;

internal static Task<T> Async1<T>(T value) => Task.Run(() => value);

internal static T Continuation1<T>(T value) => value;

internal static Task<T> Async2<T>(T value) => Task.FromResult(value);

internal static T Continuation2<T>(T value) => value;

internal static Task<T> Async3<T>(T value) => Task.Run(() => value);

internal static T Continuation3<T>(T value) => value;

After compilation, the async modifier is gone. The async function becomes a normal function to start an async state machine:

[AsyncStateMachine(typeof(AsyncStateMachine<>))]

internal static Task<T> CompiledAsync<T>(T value)

{

AsyncStateMachine<T>asyncStateMachine = new AsyncStateMachine<T>()

{

Value = value,

Builder = AsyncTaskMethodBuilder<T>.Create(),

State = -1 // -1 means start.

};

asyncStateMachine.Builder.Start(ref asyncStateMachine);

return asyncStateMachine.Builder.Task;

}

And the generated async state machine is a structure in release build, and a class in debug build:

[CompilerGenerated]

[StructLayout(LayoutKind.Auto)]

private struct AsyncStateMachine<TResult>: IAsyncStateMachine

{

public int State;

public AsyncTaskMethodBuilder<TResult> Builder;

public TResult Value;

private TaskAwaiter<TResult> awaiter;

void IAsyncStateMachine.MoveNext()

{

TResult result;

try

{

switch (this.State)

{

case -1: // Start code from the beginning to the 1st await.

// Workflow begins.

TResult value1 = Start(this.Value);

this.awaiter = Async1(value1).GetAwaiter();

if (this.awaiter.IsCompleted)

{

// If the task returned by Async1 is already completed, immediately execute the continuation.

goto case 0;

}

else

{

this.State = 0;

// If the task returned by Async1 is not completed, specify the continuation as its callback.

this.Builder.AwaitUnsafeOnCompleted(ref this.awaiter, ref this);

// Later when the task returned by Async1 is completed, it calls back MoveNext, where State is 0.

return;

}

case 0: // Continuation code from after the 1st await to the 2nd await.

// The task returned by Async1 is completed. The result is available immediately through GetResult.

TResult result1 = this.awaiter.GetResult();

TResult value2 = Continuation1(result1);

this.awaiter = Async2(value2).GetAwaiter();

if (this.awaiter.IsCompleted)

{

// If the task returned by Async2 is already completed, immediately execute the continuation.

goto case 1;

}

else

{

this.State = 1;

// If the task returned by Async2 is not completed, specify the continuation as its callback.

this.Builder.AwaitUnsafeOnCompleted(ref this.awaiter, ref this);

// Later when the task returned by Async2 is completed, it calls back MoveNext, where State is 1.

return;

}

case 1: // Continuation code from after the 2nd await to the 3rd await.

// The task returned by Async2 is completed. The result is available immediately through GetResult.

TResult result2 = this.awaiter.GetResult();

TResult value3 = Continuation2(result2);

this.awaiter = Async3(value3).GetAwaiter();

if (this.awaiter.IsCompleted)

{

// If the task returned by Async3 is already completed, immediately execute the continuation.

goto case 2;

}

else

{

this.State = 2;

// If the task returned by Async3 is not completed, specify the continuation as its callback.

this.Builder.AwaitUnsafeOnCompleted(ref this.awaiter, ref this);

// Later when the task returned by Async3 is completed, it calls back MoveNext, where State is 1.

return;

}

case 2: // Continuation code from after the 3rd await to the end.

// The task returned by Async3 is completed. The result is available immediately through GetResult.

TResult result3 = this.awaiter.GetResult();

result = Continuation3(result3);

this.State = -2; // -2 means end.

this.Builder.SetResult(result);

// Workflow ends.

return;

}

catch (Exception exception)

{

this.State = -2; // -2 means end.

this.Builder.SetException(exception);

}

[DebuggerHidden]

void IAsyncStateMachine.SetStateMachine(IAsyncStateMachine asyncStateMachine) =>

this.Builder.SetStateMachine(asyncStateMachine);

}

The generated async state machine is a finite state machine:

The workflow is compiled into a switch statement in its MoveNext method. The original workflow is split to 4 parts by the 3 await keywords, and compiled to 4 cases of the switch statement. The parameter of the workflow is compiled as a field of the state machine, so it can be accessed by the workflow inside MoveNext. When the state machine is initialized, its initial state is –1, which means to start. Once the state machine is started, MoveNext is called, and the case –1 block is executed, which has the code from the beginning of the workflow to the first await expression, which is compiled to a GetAwaiter call. If the awaiter is already completed, then the continuation should immediate be executed by going to case 0 block directly; If the awaiter is not completed, the continuation (MoveNext call with next state 0) is specified as the awaiter’s callback when it is completed in the future. In either case, when code in case 0 block is executed, the previous awaiter is already completed, and its result is immediately available through its GetResult method. The execution goes on in the same pattern, until the last block of case 2 is executed.

Runtime context capture

At runtime, when executing an await expression, if the awaited task is not completed yet, the continuation is scheduled as callback. As a result, the continuation can be executed by a thread different from initial caller thread. By default, the initial thread’s runtime context information is captured, and are reused by the callback thread to execute the continuation. To demonstrate this, the above awaitable-awaiter pattern for Action can be re-implemented with the following custom awaiter:

public static IAwaiter GetAwaiter(this Action action) =>

new ActionAwaiter(Task.Run(action));

public class ActionAwaiter : IAwaiter

{

private readonly (SynchronizationContext, TaskScheduler, ExecutionContext) runtimeContext;

private readonly Task task;

public ActionAwaiter(Task task) =>

(this.task, this.runtimeContext) = (task, RuntimeContext.Capture()); // Capture runtime context when initialized.

public bool IsCompleted => this.task.IsCompleted;

public void GetResult() => this.task.Wait();

public void OnCompleted(Action continuation) => this.task.ContinueWith(task =>

this.runtimeContext.Execute(continuation));// Execute continuation on captured runtime context.

}

When the awaiter is constructed, it captures the runtime context information, including System.Threading.SynchronizationContext, System.Threading.Tasks.TaskScheduler, and System.Threading.ExecutionContext of current thread. Then in OnCompleted, when the continuation is called back, it is executed with the previously captured runtime context information. The custom awaiter can be implemented for Func<TResult> in the same pattern:

public static IAwaiter<TResult> GetAwaiter<TResult>(this Func<TResult> function) =>

new FuncAwaiter<TResult>(Task.Run(function));

public class FuncAwaiter<TResult> : IAwaiter<TResult>

{

private readonly (SynchronizationContext, TaskScheduler, ExecutionContext) runtimeContext =

RuntimeContext.Capture();

private readonly Task<TResult> task;

public FuncAwaiter(Task<TResult> task) => (this.task, this.runtimeContext) = (task, RuntimeContext.Capture()); // Capture runtime context when initialized.

public bool IsCompleted => this.task.IsCompleted;

public TResult GetResult() => this.task.Result;

public void OnCompleted(Action continuation) => this.task.ContinueWith(task =>

this.runtimeContext.Execute(continuation)); // Execute continuation on captured runtime context.

}

The following is a basic implementation of runtime context capture and resume:

public static class RuntimeContext

{

public static (SynchronizationContext, TaskScheduler, ExecutionContext) Capture() =>

(SynchronizationContext.Current, TaskScheduler.Current, ExecutionContext.Capture());

public static void Execute(

this (SynchronizationContext, TaskScheduler, ExecutionContext) runtimeContext, Action continuation)

{

var (synchronizationContext, taskScheduler, executionContext) = runtimeContext;

if (synchronizationContext != null && synchronizationContext.GetType() != typeof(SynchronizationContext))

{

if (synchronizationContext == SynchronizationContext.Current)

{

executionContext.Run(continuation);

}

else

{

executionContext.Run(() => synchronizationContext.Post(

d: state => continuation(), state: null));

}

return;

}

if (taskScheduler != null && taskScheduler != TaskScheduler.Default)

{

Task continuationTask = new Task(continuation);

continuationTask.Start(taskScheduler);

return;

}

executionContext.Run(continuation);

}

private static void Run(this ExecutionContext executionContext, Action continuation)

{

if (executionContext != null)

{

ExecutionContext.Run(

executionContext: executionContext, callback: state => continuation(), state: null);

}

else

{

continuation();

}

When Capture is called, it captures a 3-tuple of SynchronizationContext, TaskScheduler, and ExecutionContext When the continuation is executed, first the previously captured SynchronizationContext is checked. If a specialized SynchronizationContext is captured and it is different from current SynchronizationContext, then the continuation is executed with the captured SynchronizationContext and ExecutionContext. When there is no specialized SynchronizationContext captured, then the TaskScheduler is checked. If a specialized TaskScheduler is captured, it is used to schedule the continuation as a task. For all the other cases, the continuation is executed with the captured ExecutionContext.

Task and Task<TResult> provides a ConfigureAwait method to specify whether the continuation is marshalled to the previously captured runtime context:

namespace System.Threading.Tasks

{

public partial class Task : IAsyncResult

{

public ConfiguredTaskAwaitable ConfigureAwait(bool continueOnCapturedContext);

}

public partial class Task<TResult> : Task

{

public ConfiguredTaskAwaitable<TResult> ConfigureAwait(bool continueOnCapturedContext);

}

To demonstrate the runtime context capture, define a custom task scheduler, which simply start a background thread to execute each task:

public class BackgroundThreadTaskScheduler : TaskScheduler

{

protected override IEnumerable<Task> GetScheduledTasks() =>

throw new NotImplementedException();

protected override void QueueTask(Task task) =>

new Thread(() => this.TryExecuteTask(task)) { IsBackground = true }.Start();

protected override bool TryExecuteTaskInline(

Task task, bool taskWasPreviouslyQueued) =>

this.TryExecuteTask(task);

}

The following async function has 2 await expressions, where ConfigureAwait is called with different bool values:

internal static async Task ConfigureRuntimeContextCapture(

string readPath, string writePath)

{

TaskScheduler taskScheduler1 = TaskScheduler.Current;

string contents = await ReadAsync(readPath).ConfigureAwait(

continueOnCapturedContext: true);

// Equivalent to: await ReadAsync(readPath);

// Continuation is executed with captured runtime context.

TaskScheduler taskScheduler2 = TaskScheduler.Current;

object.ReferenceEquals(taskScheduler1, taskScheduler2).WriteLine(); // True

await WriteAsync(writePath, contents).ConfigureAwait(

continueOnCapturedContext: false);

// Continuation is executed without captured runtime context.

TaskScheduler taskScheduler3 = TaskScheduler.Current;

object.ReferenceEquals(taskScheduler1, taskScheduler3).WriteLine(); // False

}

To demonstrate the task scheduler capture, call the above async function by specifying the custom task scheduler:

internal static async Task CallConfigureContextCapture(string readPath, string writePath)

{

Task<Task> task = new Task<Task>(() =>

ConfigureRuntimeContextCapture(readPath, writePath));

task.Start(new BackgroundThreadTaskScheduler());

await task.Unwrap(); // Equivalent to: await await task;

}

Here since async function ConfigureRuntimeContextCapture outputs Task, so the task constructed with () -> Task function is of type Task<Task>. Similarly, if task is constructed with () -> Task<TResult> function, the constructed task is of type Task<Task<TResult>>. For this scenario, Unwrap extension methods are provided to convert nested task to normal task:

namespace System.Threading.Tasks

{

public static class TaskExtensions

{

public static Task Unwrap(this Task<Task> task);

public static Task<TResult> Unwrap<TResult>(this Task<Task<TResult>> task);

}

When start executing ConfigureRuntimeContextCapture, the initial task scheduler is specified to be the custom task scheduler, BackgroundThreadTaskScheduler. In the first await expression, ConfigureAwait is called with true, so that the runtime context information is captured and the continuation is executed with the captured runtime context information. This is the default behaviour, so calling ConfigureAwait with true is equivalent to not calling ConfigureAwait at all. As a result, the first continuation is executed with the same custom task scheduler. In the second await expression, ConfigureAwait is called with false, so the runtime context information is not captured. As a result, the second continuation is executed with the default task scheduler, System.Threading.Tasks.ThreadPoolTaskScheduler.

The runtime context capture can be also demonstrated by SynchronizationContext. SynchronizationContext is inherited by different implementations in different application models, for example:

· ASP.NET: System.Web.AspNetSynchronizationContext

· WPF: System.Windows.Threading.DispatcherSynchronizationContext

· WinForms: System.Windows.Forms.WindowsFormsSynchronizationContext

· Windows Universal: System.Threading.WinRTCoreDispatcherBasedSynchronizationContext

· Xamarin.Android: Android.App.SyncContext

· Xamarin.iOS: UIKit.UIKitSynchronizationContext

Take Windows Universal application as example. In Visual Studio on Windows, create a Windows Universal application, add a button to its UI:

In the code behind, implement the Click event handler as an async function:

private async void ButtonClick(object sender, RoutedEventArgs e)

{

SynchronizationContext synchronizationContext1 = SynchronizationContext.Current;

ExecutionContext executionContext1 = ExecutionContext.Capture();

await Task.Delay(TimeSpan.FromSeconds(1)).ConfigureAwait(

continueOnCapturedContext: true);

// Equivalent to: await Task.Delay(TimeSpan.FromSeconds(1));

// Continuation is executed with captured runtime context.

SynchronizationContext synchronizationContext2 = SynchronizationContext.Current;

Debug.WriteLine(synchronizationContext1 == synchronizationContext2); // True

this.Button.Background = new SolidColorBrush(Colors.Blue); // UI update works.

await Task.Delay(TimeSpan.FromSeconds(1)).ConfigureAwait(

continueOnCapturedContext: false);

// Continuation is executed without captured runtime context.

SynchronizationContext synchronizationContext3 = SynchronizationContext.Current;

Debug.WriteLine(synchronizationContext1 == synchronizationContext3); // False

this.Button.Background = new SolidColorBrush(Colors.Yellow); // UI update fails.

// Exception: The application called an interface that was marshalled for a different thread.

}

For Windows Universal application, the SynchronizationContext is only available for the UI thread, and application UI can only be updated with UI thread’s SynchronizationContext. When the button is clicked, the UI thread calls the async function ButtonClick, so the UI thread’s SynchronizationContext is captured. Similar to the previous example, when ConfigureAwait is called with true, the continuation is executed with the previously captured SynchronizationContext, so the continuation can update the UI successfully. When ConfigureAwait is called with true, the continuation is not executed with the SynchronizationContext captured from UI thread, and it fails to update the UI and throws exception.

Generalized async function output type and async method builder

Since C# 7, async function is supported to have any awaitable output type, as long as it has an async method builder specified. Take Func<TResult> is already awaitable with the previously defined GetAwaiter extension method as example, it is already awaitable with the previously defined GetAwaiter extension method, and can be used in await expression just like task. However, it cannot be used with async modifier to be async function output type just like task. To make Func<TResult> output type of async function, the following FuncAwaitable<TResult> type is defined as a wrapper of Func<TResult>. This wrapper is an awaitable type, its GetAwaiter instance method reuses previously defined FuncAwater<TResult> as its awaiter:

[AsyncMethodBuilder(typeof(AsyncFuncAwaitableMethodBuilder<>))]

public class FuncAwaitable<TResult>: IAwaitable<TResult>

{

private readonly Func<TResult> function;

public FuncAwaitable(Func<TResult> function) => this.function = function;

public IAwaiter<TResult> GetAwaiter() =>

new FuncAwaiter<TResult>(Task.Run(this.function));

}

This wrapper type is associated with its async method builder with System.Runtime.CompilerServices.AsyncMethodBuilderAttribute. The async method builder for FuncAwaitable<TResult> is implemented as:

public class AsyncFuncAwaitableMethodBuilder<TResult>

{

private AsyncTaskMethodBuilder<TResult> taskMethodBuilder;

private TResult result;

private bool hasResult;

private bool useBuilder;

public static AsyncFuncAwaitableMethodBuilder<TResult> Create() =>

new AsyncFuncAwaitableMethodBuilder<TResult>()

{

taskMethodBuilder = AsyncTaskMethodBuilder<TResult>.Create()

};

public void Start<TStateMachine>(ref TStateMachine stateMachine)

where TStateMachine : IAsyncStateMachine =>

this.taskMethodBuilder.Start(ref stateMachine);

public void SetStateMachine(IAsyncStateMachine stateMachine) =>

this.taskMethodBuilder.SetStateMachine(stateMachine);

public void SetResult(TResult result)

{

if (this.useBuilder)

{

this.taskMethodBuilder.SetResult(result);

}

else

{

this.result = result;

this.hasResult = true;

}

public void SetException(Exception exception) =>

this.taskMethodBuilder.SetException(exception);

public FuncAwaitable<TResult> Task

{

get

{

if (this.hasResult)

{

TResult result = this.result;

return new FuncAwaitable<TResult>(() => result);

}

this.useBuilder = true;

Task<TResult>task = this.taskMethodBuilder.Task;

return new FuncAwaitable<TResult>(() => task.Result);

}

public void AwaitOnCompleted<TAwaiter, TStateMachine>(

ref TAwaiter awaiter, ref TStateMachine stateMachine)

where TAwaiter : INotifyCompletion where TStateMachine : IAsyncStateMachine

{

this.useBuilder = true;

this.taskMethodBuilder.AwaitOnCompleted(ref awaiter, ref stateMachine);

}

public void AwaitUnsafeOnCompleted<TAwaiter, TStateMachine>(

ref TAwaiter awaiter, ref TStateMachine stateMachine)

where TAwaiter : ICriticalNotifyCompletion where TStateMachine : IAsyncStateMachine

{

this.useBuilder = true;

this.taskMethodBuilder.AwaitUnsafeOnCompleted(ref awaiter, ref stateMachine);

}

Now the FuncAwaitable<TResult> type can be output type of async function, just like task:

internal static async FuncAwaitable<T> AsyncFunctionWithFuncAwaitable<T>(T value)

{

await Task.Delay(TimeSpan.FromSeconds(1));

return value;

}

Its compilation is in the same pattern as async function with task output. The only difference is, in the generated async state machine, the builder field become the specified AsyncFuncAwaitableMethodBuilder<TResult>, instead of the AsyncTaskMethodBuilder<TResult> for task. And apparently, this async function can be called in the await expression since its output type FuncAwaitable<TResult> is awaitable:

internal static async Task CallAsyncFunctionWithFuncAwaitable<T>(T value)

{

T result = await AsyncFunctionWithFuncAwaitable(value);

}

ValueTask<TResult> and performance

With the generalized async function output type support, Microsoft also provides a System.Threading.Tasks.ValueTask<TResult> awaitable structure in the System.Threading.Tasks.Extensions NuGet package:

namespace System.Threading.Tasks

{

[AsyncMethodBuilder(typeof(AsyncValueTaskMethodBuilder<>))]

[StructLayout(LayoutKind.Auto)]

public struct ValueTask<TResult> : IEquatable<ValueTask<TResult>>

{

public ValueTask(TResult result);

public ValueTask(Task<TResult> task);

public ValueTaskAwaiter<TResult> GetAwaiter();

// Other members.

}

Its awaiter is System.Threading.Tasks.ValueTaskAwaiter<TResult>, and its async method builder is System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder<TResult>, which are provided in the same NuGet package. So ValueTask<TResult> can be used with both await expression and async function. As a value type, it can be allocated and deallocated on stack, with better performance than reference type Task<TResult>. Also, unlike Task<TResult> as a wrapper of Func<TResult> operation, ValueTask<TResult> can be a wrapper of either Func<TResult> operation or TResult result. So ValueTask<TResult> can improve the performance for async function that may have result available before any async operation. The following example downloads data from the specified URI:

private static readonly Dictionary<string, byte[]> Cache =

new Dictionary<string, byte[]>(StringComparer.OrdinalIgnoreCase);

internal static async Task<byte[]> DownloadAsyncTask(string uri)

{

// All code compiled to async state machine. When URI is cached, async state machine is still started.

if (Cache.TryGetValue(uri, out byte[] cachedResult))

{

return cachedResult;

}

using (HttpClient httpClient = new HttpClient())

{

byte[] result = await httpClient.GetByteArrayAsync(uri);

Cache.Add(uri, result);

return result;

}

It first checks the cache, if the data is already cached for the specified URI, then it outputs the cached data directly, no async operation is needed. However, at compile time, since the function has the async modifier, the entire function body, including the if statement, is compiled into an async state machine. At runtime, a task is always allocated on the heap and should be garbage collected, and the async state machine is always started, even when the result is available in the cache and no async operation is needed. With ValueTask<TResult>, this can be easily optimized:

internal static ValueTask<byte[]> DownloadAsyncValueTask(string uri)

{

// Not compiled to async state machine. When URI is cached, no async state machine is started.

return Cache.TryGetValue(uri, out byte[] cachedResult)

? new ValueTask<byte[]>(cachedResult)

: new ValueTask<byte[]>(DownloadAsync());

async Task<byte[]> DownloadAsync()

{

// Compiled to async state machine. When URI is not cached, async state machine is started.

using (HttpClient httpClient = new HttpClient())

{

byte[] result = await httpClient.GetByteArrayAsync(uri);

Cache.Add(uri, result);

return result;

}

Now the function becomes a sync function with awaitable ValueTask<TResult> output. When the result is available in the cache, the async local function is not called, so there is no async operation or async state machine involved, and there is no task allocated on heap. The async operation is encapsulated in the async local function, which is compiled to async state machine, and is only involved when the result is not available in the cache. As a result, the performance can be improved, especially when the cache is hit frequently.

Anonymous async function

The async and await keywords can be used with the lambda expression syntax for anonymous function. Just like named async function, anonymous async function’s output type is task:

internal static async Task AsyncAnonymousFunction(string readPath, string writePath)

{

Func<string, Task<string>>readAsync = async path =>

{

using (StreamReader reader = new StreamReader(new FileStream(

path: path, mode: FileMode.Open, access: FileAccess.Read,

share: FileShare.Read, bufferSize: 4096, useAsync: true)))

{

return await reader.ReadToEndAsync();

}

};

Func<string, string, Task>writeAsync = async (path, contents) =>

{

using (StreamWriter writer = new StreamWriter(new FileStream(

path: path, mode: FileMode.Create, access: FileAccess.Write,

share: FileShare.Read, bufferSize: 4096, useAsync: true)))

{

await writer.WriteAsync(contents);

}

};

string result = await readAsync(readPath);

await writeAsync(writePath, result);

}

The above async lambda expressions are compiled as methods of closure class, in the same pattern as normal sync lambda expressions.

Since task can be constructed with anonymous function with any output type, it can be constructed with anonymous async function with task output too:

internal static async Task ConstructTaskWithAsyncAnonymousFunction(

string readPath, string writePath)

{

Task<Task<string>> task1 = new Task<Task<string>>(async () =>

await ReadAsync(readPath));

task1.Start(); // Cold task needs to be started.

string contents = await task1.Unwrap(); // Equivalent to: string contents = await await task1;

Task<Task> task2 = new Task<Task>(async () => await WriteAsync(writePath, null));

task2.Start(); // Cold task needs to be started.

await task2.Unwrap(); // Equivalent to: await await task2;

}

The first task is constructed with anonymous async function of type () –> Task<string>, so the constructed task is of type Task<Task<string>>. Similarly, the second task is constructed with anonymous async function of type () –> Task, so the constructed task is of type Task<Task>. As fore mentioned, nested task can be unwrapped and awaited.

internal static async Task RunAsyncWithAutoUnwrap(string readPath, string writePath)

{

Task<string> task1 = Task.Run(async () => await ReadAsync(readPath)); // Automatically unwrapped.

string contents = await task1; // Hot task.

Task task2 = Task.Run(async () => await WriteAsync(writePath, contents)); // Automatically unwrapped.

await task2; // Hot task.

}

Asynchrnous sequence: IAsyncEnumerable<T>

In C# 8.0, an async function can return a sequence of values using the return type IAsyncEnumerable<T>:

namespace System.Collections.Generic

{

public interface IAsyncEnumerable<out T>

{

IAsyncEnumerator<T> GetAsyncEnumerator(CancellationToken cancellationToken = default);

}

public interface IAsyncEnumerator<out T> : IAsyncDisposable

{

T Current { get; }

ValueTask<bool> MoveNextAsync();

}

The following example define a async function that generates a sequence of values by using yield statement:

internal static async IAsyncEnumerable<string>DownloadAsync(IEnumerable<Uri> uris)

{

using WebClient webClient = new WebClient();

foreach (Uri uri in uris)

{

string webPage = await webClient.DownloadStringTaskAsync(uri);

yield return webPage;

}

The following example consumes an async sequence by pulling the values asynchronously using async foreach statement:

internal static async void PrintDownloadAsync(IEnumerable<Uri> uris)

{

IAsyncEnumerable<string> webPages = DownloadAsync(uris);

await foreach (string webPage in webPages)

{

Trace.WriteLine(webPage);

}

In above 2 async functions, the code are both compiled to a state macine similar to async functions returning a task.

async using declaration: IAsyncDispose

In C# 8.0, an instance can be decared with async using keywords, if its type implements System.IAsyncDispose interface:

namespace System

{

public interface IAsyncDisposable

{

ValueTask DisposeAsync();

}

For example, FileStream type implements IAsyncDispose:

internalstaticasyncvoid AsyncUsing(string file)

{

awaitusing FileStream fileStream = File.OpenRead(file);

Trace.WriteLine(fileStream.Length);

}

The code in the above async function is also compiled to a state machine.

Summary

C# supports async function as a simplified asynchronous programming model. In C#, async operation is represented by Task or Task<TResult>. A task can be async function output type, and can be used in await expression. Besides task, any type following the awaitable-awaiter pattern can be used in await expression. Async function is compiled to async state machine. It can capture the caller’s runtime context, and execute the continuation code with the captured context. C# generalizes async function output type with async method builder support, and a ValueTask<TResult> type is provided to improve async function performance. C# also support async local function and async anonymous function.

Functional Programming and LINQ via C#

Sun, 02 Mar 2025 03:16:00 GMT

Acclaim
Contents at a Glance
Table of Contents

This is a book on functional programming and LINQ programming via C# language. It discusses:

Functional programming via C# in-depth
Use functional LINQ to work with local data and cloud data
The underlying mathematics theories of functional programming and LINQ, including Lambda Calculus and Category Theory

Acclaim

Microsoft:

“An excellent book for those of us who need to get in-depth understanding on LINQ and functional programming with latest C# language. The author made sure this book includes the latest and cross-platform knowledge for the language, the framework, as well as the underlying mathematical theories.”
Hongfei Guo
Partner Group Engineering Manager at Microsoft
“This book explains practical and in-depth material clearly, concisely and accurately to the areas of the C# language, functional programming, and LINQ on .NET Framework and .NET Core. This is a great book for anyone wanting to understand the whys and hows behind these important technologies.”
Samer Boshra
Principal Software Development Engineer at Microsoft
“This is a great book for developers who want to go functional programming. It's one-stop shopping for serious developers who have to get up to speed with LINQ and functional programming quickly and in-depth. I'll keep this book on my desk not on my bookshelf.”
Roshan Kommusetty
Principal Software Engineering Manager at Microsoft
“This is a great book for C# developers, it covers both basic C# programming concepts for the beginners new to the .NET world, and C# advanced constructs for experienced .NET programmers. The book is up to date, talks C# 7.0 new language features and demonstrates how you can use them for functional programming. Thanks for the awesome work!”
Mark Zhou
Principal Software Engineering Manager at Microsoft
“I like the way the author presented the detailed knowledge with a lot of examples. As a data scientist with statistics background in a number of industries, I can pick up C# programming and LINQ quickly when I followed the book. The book was concise and easy to read. It was a pleasant experience for me to spend my time emerging myself in the book in the sunshine weekday afternoon.”
Xue Liu
Senior Data Scientist at Microsoft
“Functional Programming and LINQ in C# language, have been fully and clearly unraveled in this book, with many practical examples. The author has not saved any effort to go beyond scratching the surface of C# language and has successfully explained the magic behind the scene. This book is a must-have for anyone who wants to understand functional programming using C#.”
Jie Mei
Data & Applied Scientist at Microsoft

Academy and more:

“This book provides comprehensive and in-depth information about the C# functional programming and LINQ technologies to application developers on both .NET Framework and .NET Core. The detailed text and wealth of examples will give a developer a clear and solid understanding of C# language, functional programming and using LINQ to work with different data domains.”
Dong Si
Assistant Professor, Department of Computer Science, University of Washington, Bothell
“This book offers a comprehensive, in-depth, yet easy-to-understand tutorial to functional C# programming and LINQ. Filled with detailed explanations and real-world examples, this book is highly valuable for beginners and experienced developers alike.”
Shuang Zhao
Assistant Professor, Department of Computer Science, University of California, Irvine
“This excellent book is an in-depth and also readable exploration of C# functional programming and LINQ programming. It covers .NET Framework and .NET Core in great detail.”
Yang Sha
Engineering Manager at Google
“Great book! It takes a hands-on approach to LINQ and functional programming in an easy to understand format. I would highly recommend this book to developers looking to develop expertise in C#, functional programming, and LINQ.”
Himanshu Lal
Software Engineering Manager at Facebook
“This is a great book that combines practical examples with in-depth analysis of LINQ and functional programming in C#. Dixin leverages his expertise in .NET to provide a well written tutorial on the effective use of LINQ and an overview of the theoretical principles behind it. A must read for anyone working on these technologies!”
Dimitrios Soulios
Director at Goldman Sachs

Contents at a Glance

The contents are organized as the following chapters:

Part 1 Code - covers functional programming via C#, and fundamentals of LINQ.
- Chapter 1 Functional programming and LINQ paradigm
  - What is LINQ, how LINQ uses language to work with many different data domains.
  - Programming paradigm, imperative vs. declarative programming, object-oriented vs. functional programming.
- Chapter 2 Functional programming in depth
  - C# fundamentals for beginners.
  - Aspects of functional programming via C#, including function type, named/anonymous/local function, closure, lambda, higher-order function, currying, partial application, first class function, function composition, query expression, covariance/contravariance, immutability, tuple, purity, async function, pattern matching, etc., including how C# is processed at compile time and runtime.
Part 2 Data - covers how to use functional LINQ to work with different data domains in the real world, and how LINQ works internally.
- Chapter 3 LINQ to Objects
  - How to use functional LINQ queries to work with objects, covering all LINQ and Ix.
  - How the LINQ to Objects query methods are implemented, how to implement useful custom LINQ queries.
- Chapter 4 LINQ to XML
  - How to modeling XML data, and use functional LINQ queries to work with XML data.
  - How to use the other LINQ to XML APIs to manipulate XML data.
- Chapter 5 Parallel LINQ
  - How to use parallelized functional LINQ queries to work with objects.
  - Performance analysis for parallel/sequential LINQ queries.
- Chapter 6 Entity Framework/Core and LINQ to Entities
  - How to model database with object-relational mapping, and use functional LINQ queries to work with relational data in database.
  - How the C# LINQ to Entities queries are implemented to work with database.
  - How to change data in database, and handle concurrent conflicts.
  - Performance tips and asynchrony.
Part 3 Theories - demystifies the abstract mathematics theories, which are the rationale and foundations of LINQ and functional programming.
- Chapter 7 Lambda Calculus via C#
  - Core concepts of lambda calculus, bound and free variables, reduction (α-conversion, β-reduction, η-conversion), etc.
  - How to use lambda functions to represent values, data structures and computation, including Church Boolean, Church numbers, Church pair, Church list, and their operations.
  - Combinators and combinatory logic, including SKI combinator calculus, fixed point combinator for function recursion, etc.
- Chapter 8 Category Theory via C#
  - Core concepts of category theory, including category, object, morphism, monoid, functor, natural transformation, applicative functor, monad, and their laws.
  - How these concepts are applied in functional programming and LINQ.
  - How to manage I/O, state, exception handling, shared environment, logging, and continuation, etc., in functional programming.

This tutorial delivers highly reusable knowledge:

It covers C# language in depth, which can be generally applied in any programming paradigms besides functional programming.
It is a cross platform tutorial, covering both .NET Framework for Windows and .NET Core for Windows, Mac, Linux.
It demonstrates both usage and implementation of LINQ for mainstream data domains, which also enables developer to use the LINQ technologies for other data domains, or build custom LINQ APIs for specific data scenarios.
It also demystifies the abstract mathematics knowledge for functional programming, which applies to general functional programming, so it greatly helps developers understanding any other functional languages too.

As a fun of functional programming, LINQ, C#, and .NET technologies, hope this helps.

All code examples are available on GitHub: https://github.com/Dixin/CodeSnippets.

Functional programming and LINQ paradigm
1. Cross platform C# and .NET
  - Introducing cross platform .NET, C# and LINQ
    - .NET Framework, C#, and LINQ
    - .NET Core, UWP, Mono, Xamarin and Unity
    - .NET Standard
  - Introducing this book
    - Book structure
    - Code examples
  - Start coding
    - Start coding with Visual Studio (Windows)
    - Start coding with Visual Studio Code (Windows, macOS and Linux)
    - Start coding with Visual Studio for Mac (macOS)
2. Programming paradigms and functional programming
  - Programming paradigms
  - Imperative programming vs. declarative programming
  - Object-oriented programming vs. functional programming
3. LINQ to data sources
  - One language for different data domains
    - LINQ to Objects
    - Parallel LINQ
    - LINQ to XML
    - LINQ to DataSets
    - LINQ to Entities
    - LINQ to SQL
    - LINQ to NoSQL (LINQ to CosmosDB)
    - LINQ to JSON
    - LINQ to Twitter
  - Sequential query vs. parallel query
  - Local query vs. remote query
Functional programming in depth
1. C# language basics
  - Types and members
    - Types and members
    - Built-in types
  - Reference type vs. value type
    - ref local variable and immutable ref local variable
    - Array and stack-allocated array
    - Default value
    - ref structure
  - Static class
  - Partial type
  - Interface and implementation
    - IDisposable interface and using declaration
  - Generic type
    - Type parameter
    - Type parameter constraints
  - Nullable value type
  - Auto property
  - Property initializer
  - Object initializer
  - Collection initializer
  - Index initializer
  - Null coalescing operator
  - Null conditional operator
  - throw expression
  - Exception filter
  - String interpolation
  - nameof operator
  - Digit separator and leading underscore
2. Named function and function polymorphism
  - Constructor, static constructor and finalizer
  - Static method and instance method
  - Extension method
  - More named functions
  - Function polymorphisms
    - Ad hoc polymorphism: method overload
    - Parametric polymorphism: generic method
      - Type argument inference
  - Static import
  - Partial method
3. Local function and closure
  - Local function
  - Closure
    - Outer variable
    - Implicit reference
    - Static local function
4. Function input and output
  - Input by copy vs. input by alias (ref parameter)
    - Input by immutable alias (in parameter)
  - Output parameter (out parameter) and out variable
    - Discarding out variable
  - Parameter array
  - Positional argument vs. named argument
  - Required parameter vs. optional parameter
  - Caller information parameter
  - Output by copy vs. output by alias
    - Output by immutable alias
5. Delegate: Function type, instance, and group
  - Delegate type as function type
    - Function type
    - Generic delegate type
    - Unified built-in delegate types
  - Delegate instance as function instance
  - Delegate instance as function group
    - Event and event handler
6. Anonymous function and lambda expression
  - Anonymous method
  - Lambda expression as anonymous function
    - IIFE (Immediately-invoked function expression)
    - Closure
  - Expression bodied function member
7. Expression tree: Function as data
  - Lambda expression as expression tree
    - Metaprogramming: function as abstract syntax tree
    - .NET expressions
  - Compile expression tree at runtime
    - Traverse expression tree
    - Expression tree to CIL at runtime
    - Expression tree to executable function at runtime
  - Expression tree and LINQ remote query
8. Higher-order function, currying and first class function
  - First order function vs. higher-order function
    - Convert first-order function to higher-order function
    - Lambda operator => associativity
  - Curry function
    - Uncurry function
    - Partial applying function
  - First-class function
9. Function composition and chaining
  - Forward composition vs. backward composition
  - Forward piping
  - Method chaining and fluent interface
10. LINQ query expression
  - Syntax and compilation
  - Query expression pattern
  - LINQ query expression
    - Forward piping with LINQ
  - Query expression vs. query method
11. Covariance and contravariance
  - Subtyping and type polymorphism
  - Variances of non-generic function type
  - Variances of generic function type
  - Variances of generic interface
  - Variances of generic higher-order function type
  - Covariance of array
  - Variances in .NET and LINQ
12. Immutability, anonymous type and tuple
  - Immutable value
    - Constant local
    - Enumeration
    - using declaration and foreach statement
    - Immutable alias (immutable ref local variable)
    - Function’s immutable input and immutable output
    - Range variable in LINQ query expression
    - this reference for class
  - Immutable state (immutable type)
    - Constant field
    - Immutable class with readonly instance field
    - Immutable structure (readonly structure)
    - Immutable anonymous type
      - Local variable type inference
    - Immutable tuple vs. mutable tuple
      - Construction, element name and element inference
      - Deconstruction
      - Tuple assignment
    - Immutable collection vs. readonly collection
    - Shallow immutability vs. deep immutability
13. Pure function
  - Pure function vs. impure function
    - Referential transparency and side effect free
  - Purity in .NET
  - Purity in LINQ
14. Asynchronous function
  - Task, Task<TResult> and asynchrony
  - Named async function
  - Awaitable-awaiter pattern
  - Async state machine
  - Runtime context capture
  - Generalized async return type and async method builder
    - ValueTask<TResult> and performance
  - Anonymous async function
  - Asynchronous sequence: IAsyncEnumerable<T>
  - async using declaration: IAsyncDispose
15. Pattern matching
  - Is expression
  - switch statement and switch expression
LINQ to Objects: Querying objects in memory
1. Local sequential LINQ query
  - Iteration pattern and foreach statement
  - IEnumerable<T> and IEnumerator<T>
    - foreach loop vs. for loop
    - Non-generic sequence vs. generic sequence
  - LINQ to Objects queryable types
2. LINQ to Objects standard queries and query expressions
  - Sequence queries
    - Generation: Empty , Range, Repeat, DefaultIfEmpty
    - Filtering (restriction): Where, OfType, where
    - Mapping (projection): Select, SelectMany, from, let, select
    - Grouping: GroupBy, group, by, into
    - Join
      - Inner join: Join, SelectMany, join, on, equals
      - Outer join: GroupJoin, join, into, on, equals
      - Cross join: SelectMany, Join, from select, join, on, equals
    - Concatenation: Concat
    - Set: Distinct, Union, Intersect, Except
    - Convolution: Zip
    - Partitioning: Take, Skip, TakeWhile, SkipWhile
    - Ordering: OrderBy, ThenBy, OrderByDescending, ThenByDescending, Reverse, orderby, ascending, descending, into
    - Conversion: Cast, AsEnumerable
  - Collection queries
    - Conversion: ToArray, ToList, ToDictionary, ToLookup
  - Value queries
    - Element: First, FirstOrDefault, Last, LastOrDefault, ElementAt, ElementAtOrDefault, Single, SingleOrDefault
    - Aggregation: Aggregate, Count, LongCount, Min, Max, Sum, Average
    - Quantifier: All, Any, Contains
    - Equality: SequenceEqual
  - Queries in other languages
3. Generator
  - Implementing iterator pattern
  - Generating sequence and iterator
  - Yield statement and generator
4. Deferred execution, lazy evaluation and eager Evaluation
  - Immediate execution vs. Deferred execution
    - Cold IEnumerable<T> vs. hot IEnumerable<T>
  - Lazy evaluation vs. eager evaluation
5. LINQ to Objects internals: Standard queries implementation
  - Argument check and deferred execution
  - Collection queries
    - Conversion: ToArray, ToList, ToDictionary, ToLookup
  - Sequence queries
    - Conversion: Cast, AsEnumerable
    - Generation: Empty , Range, Repeat, DefaultIfEmpty
    - Filtering (restriction): Where, OfType
    - Mapping (projection): Select, SelectMany
    - Grouping: GroupBy
    - Join: SelectMany, Join, GroupJoin
    - Concatenation: Concat
    - Set: Distinct, Union, Intersect, Except
    - Convolution: Zip
    - Partitioning: Take, Skip, TakeWhile, SkipWhile
    - Ordering: OrderBy, ThenBy, OrderByDescending, ThenByDescending, Reverse
  - Value queries
    - Element: First, FirstOrDefault, Last, LastOrDefault, ElementAt, ElementAtOrDefault, Single, SingleOrDefault
    - Aggregation: Aggregate, Count, LongCount, Min, Max, Sum, Average
    - Quantifier: All, Any, Contains
    - Equality: SequenceEqual
6. Advanced queries in Microsoft Interactive Extensions (Ix)
  - Sequence queries
    - Generation: Defer, Create, Return, Repeat
    - Filtering: IgnoreElements, DistinctUntilChanged
    - Mapping: SelectMany, Scan, Expand
    - Concatenation: Concat, StartWith
    - Set: Distinct
    - Partitioning: TakeLast, SkipLast
    - Conversion: Hide
    - Buffering: Buffer, Share, Publish, Memoize
    - Exception: Throw, Catch, Finally, OnErrorResumeNext, Retry
    - Imperative: If, Case, Using, While, DoWhile, Generate, For
    - Iteration: Do
  - Value queries
    - Aggregation: Min, Max, MinBy, MaxBy
    - Quantifiers: isEmpty
  - Void queries
    - Iteration: ForEach
7. Building custom queries
  - Sequence queries (deferred execution)
    - Generation: Create, RandomInt32, RandomDouble, FromValue, FromValues, EmptyIfNull
    - Filtering: Timeout
    - Concatenation: Join, Append, Prepend, AppendTo, PrependTo
    - Partitioning: Subsequence
    - Exception: Catch, Retry
    - Comparison: OrderBy, OrderByDescending, ThenBy, ThenByDescending, GroupBy, Join, GroupJoin, Distinct, Union, Intersect, Except
    - List: Insert, Remove, RemoveAll, RemoveAt
  - Collection queries
    - Comparison: ToDictionary, ToLookup
  - Value queries
    - List: IndexOf, LastIndexOf
    - Aggregation: PercentileExclusive, PercentileInclusive, Percentile
    - Quantifiers: IsNullOrEmpty, IsNotNullOrEmpty
    - Comparison: Contains, SequenceEqual
  - Void queries
    - Iteration: ForEach
LINQ to XML: Querying XML
1. Modeling XML
  - Imperative vs. declarative paradigm
  - Types, conversions and operators
  - Read and deserialize XML
  - Serialize and write XML
  - Deferred construction
2. LINQ to XML standard queries
  - Navigation
  - Ordering
  - Comparison
  - More useful queries
  - XPath
    - Generate XPath expression
3. Manipulating XML
  - Clone
  - Adding, deleting, replacing, updating, and events
  - Annotation
  - Validating XML with XSD
  - Transforming XML with XSL
Parallel LINQ: Querying objects in parallel
1. Parallel LINQ query and visualization
  - Parallel query vs. sequential query
  - Parallel query execution
  - Visualizing parallel query execution
    - Using Concurrency Visualizer
    - Visualizing sequential and parallel LINQ queries
    - Visualizing chaining query methods
2. Parallel LINQ internals: data partitioning
  - Partitioning and load balancing
    - Range partitioning
    - Chunk partitioning
    - Hash partitioning
    - Stripped partitioning
  - Implement custom partitioner
    - Static partitioner
    - Dynamic partitioner
3. Parallel LINQ standard queries
  - Query settings
    - Cancellation
    - Degree of parallelism
    - Execution mode
    - Merge the values
  - Ordering
    - Preserving the order
    - Order and correctness
    - Orderable partitioner
  - Aggregation
    - Commutativity, associativity and correctness
    - Partitioning and merging
4. Parallel query performance
  - Sequential query vs. parallel query
  - CPU bound operation vs. IO bound operation
  - Factors to impact performance
Entity Framework/Core and LINQ to Entities: Querying relational data
1. Remote LINQ query
  - Entity Framework and Entity Framework Core
  - SQL database
  - Remote query vs. local query
  - Function vs. expression tree
2. Modeling database with object-relational mapping
  - Data types
  - Database
    - Connection resiliency and execution retry strategy
  - Tables
  - Relationships
    - One-to-one
    - One-to-many
    - Many-to-many
  - Inheritance
  - Views
3. Logging and tracing LINQ to Entities queries
  - Application side logging
  - Database side tracing with Extended Events
4. LINQ to Entities standard queries
  - Sequence queries
    - Generation: DefaultIfEmpty
    - Filtering (restriction): Where, OfType
    - Mapping (projection): Select
    - Grouping: GroupBy
    - Join
      - Inner join: Join, SelectMany, GroupJoin, Select
      - Outer join: GroupJoin, Select, SelectMany
      - Cross join and self join: SelectMany, Join
    - Concatenation: Concat
    - Set: Distinct, Union, Intersect, Except
    - Partitioning: Take, Skip
    - Ordering: OrderBy, ThenBy, OrderByDescending, ThenByDescending
    - Conversion: Cast, AsQueryable
  - Value queries
    - Element: First, FirstOrDefault, Single, SingleOrDefault
    - Aggregation: Count, LongCount, Min, Max, Sum, Average
    - Quantifier: All, Any, Contains
5. LINQ to Entities internals: Query translation implementation
  - Code to LINQ expression tree
    - IQueryable<T> and IQueryProvider
    - Standard remote queries
    - Building LINQ to Entities abstract syntax tree
  - .NET expression tree to database expression tree
    - Database query abstract syntax tree
    - Compiling LINQ expressions to database expressions
    - Compiling LINQ queries
    - Compiling .NET API calls
    - Remote API call vs. local API call
    - Compile database functions and operators
  - Database expression tree to database query language
    - SQL generator and SQL command
    - Generating SQL from database expression tree
6. Loading query data
  - Deferred execution
    - Iterator pattern
    - Lazy evaluation vs. eager evaluation
  - Explicit loading
  - Eager loading
  - Lazy loading
    - The N + 1 problem
    - Disabling lazy loading
7. Manipulating relational data: Data change and transaction
  - Repository pattern and unit of work pattern
  - Tracking entities and changes
    - Tracking entities
    - Tracking entity changes and property changes
    - Tracking relationship changes
    - Enabling and disabling tracking
  - Change data
    - Create
    - Update
    - Delete
  - Transaction
    - Transaction with connection resiliency and execution strategy
    - EF Core transaction
    - ADO.NET transaction
    - Transaction scope
8. Resolving optimistic concurrency
  - Detecting concurrent conflicts
  - Resolving concurrent conflicts
    - Retaining database values (database wins)
    - Overwriting database values (client wins)
    - Merging with database values
  - Saving changes with concurrent conflict handling
Lambda Calculus via C#: The foundation of all functional programming
1. Basics
  - Expression
    - Bound variable vs. free variable
  - Reductions
    - α-conversion (alpha-conversion)
    - β-reduction (beta-reduction)
    - η-conversion (eta-conversion)
    - Normal order
    - Applicative order
  - Function composition
    - Associativity
    - Unit
2. Church encoding: Function as boolean and logic
  - Church encoding
  - Church Boolean
  - Logical operators
  - Conversion between Church Boolean and System.Boolean
  - If
3. Church encoding: Function as numeral, arithmetic and predicate
  - Church numerals
  - Increase and decrease
  - Arithmetic operators
  - Predicate and relational operators
    - Attempt of recursion
  - Conversion between Church numeral and System.UInt32
4. Church encoding: Function as tuple and signed numeral
  - Church pair (2-tuple)
    - Tuple operators
  - N-tuple
  - Signed numeral
    - Arithmetic operators
5. Church encoding: Function as list
  - Tuple as list node
    - List operators
  - Aggregation function as list node
    - List operators
  - Model everything
6. Combinatory logic
  - Combinator
  - SKI combinator calculus
    - SKI compiler: compile lambda calculus expression to SKI calculus combinator
  - Iota combinator calculus
7. Fixed point combinator and recursion
  - Normal order fixed point combinator (Y combinator) and recursion
  - Applicative order fixed point combinator (Z combinator) and recursion
8. Undecidability of equivalence
  - Halting problem
  - Equivalence problem
Category Theory via C#: The essentials and design of LINQ
1. Basics: Category and morphism
  - Category and category laws
  - DotNet category
2. Monoid
  - Monoid and monoid laws
  - Monoid as category
3. Functor and LINQ to Functors
  - Functor and functor laws
    - Endofunctor
    - Type constructor and higher-kinded type
  - LINQ to Functors
    - Built-in IEnumerable<> functor
    - Functor pattern of LINQ
  - More LINQ to Functors
4. Natural transformation
  - Natural transformation and naturality
  - Functor Category
    - Endofunctor category
5. Bifunctor
  - Bifunctor
  - Monoidal category
6. Monoidal functor and applicative functor
  - Monoidal functor
    - IEnumeable<> monoidal functor
  - Applicative functor
    - IEnumeable<> applicative functor
  - Monoidal functor vs. applicative functor
  - More Monoidal functors and applicative functors
7. Monad and LINQ to Monads
  - Monad
  - LINQ to Monads and monad laws
    - Built-in IEnumerable<> monad
    - Monad laws and Kleisli composition
    - Kleisli category
    - Monad pattern of LINQ
  - Monad vs. monoidal/applicative functor
  - More LINQ to Monads
8. Advanced LINQ to Monads
  - IO monad
  - State monad
  - Try monad
  - Reader monad
  - Writer monad
  - Continuation monad

Understanding (all) JavaScript module formats and tools

Sun, 09 Feb 2025 18:15:00 GMT

When you build an application with JavaScript, you always want to modularize your code. However, JavaScript language was initially invented for simple form manipulation, with no built-in features like module or namespace. In years, tons of technologies are invented to modularize JavaScript. This article discusses all mainstream terms, patterns, libraries, syntax, and tools for JavaScript modules.

IIFE module: JavaScript module pattern
- IIFE: Immediately invoked function expression
- Import mixins
Revealing module: JavaScript revealing module pattern
CJS module: CommonJS module, or Node.js module
AMD module: Asynchronous Module Definition, or RequireJS module
- Dynamic loading
- AMD module from CommonJS module
UMD module: Universal Module Definition, or UmdJS module
- UMD for both AMD (RequireJS) and native browser
- UMD for both AMD (RequireJS) and CommonJS (Node.js)
ES module: ECMAScript 2015, or ES6 module
ES dynamic module: ECMAScript 2020, or ES11 dynamic module
System module: SystemJS module
- Dynamic module loading
Webpack module: bundle from CJS, AMD, ES modules
Babel module: transpile from ES module
- Babel with SystemJS
TypeScript module: Transpile to CJS, AMD, ES, System modules
- Internal module and namespace
Conclusion

IIFE module: JavaScript module pattern

In the browser, defining a JavaScript variable is defining a global variable, which causes pollution across all JavaScript files loaded by the current web page:

// Define global variables. let count = 0; const increase = () => ++count; const reset = () => { count = 0; console.log("Count is reset."); }; // Use global variables. increase(); reset();

To avoid global pollution, an anonymous function can be used to wrap the code:

(() => { let count = 0; // ... });

Apparently, there is no longer any global variable. However, defining a function does not execute the code inside the function.

IIFE: Immediately invoked function expression

To execute the code inside a function f, the syntax is function call () as f(). To execute the code inside an anonymous function (() => {}), the same function call syntax () can be used as (() => {})():

(() => { let count = 0; // ... })();

This is called an IIFE (Immediately invoked function expression). So a basic module can be defined in this way:

// Define IIFE module. const iifeCounterModule = (() => { let count = 0; return { increase: () => ++count, reset: () => { count = 0; console.log("Count is reset."); } }; })(); // Use IIFE module. iifeCounterModule.increase(); iifeCounterModule.reset();

It wraps the module code inside an IIFE. The anonymous function returns an object, which is the placeholder of exported APIs. Only 1 global variable is introduced, which is the module name (or namespace). Later the module name can be used to call the exported module APIs. This is called the module pattern of JavaScript.

Import mixins

When defining a module, some dependencies may be required. With IIFE module pattern, each dependent module is a global variable. The dependent modules can be directly accessed inside the anonymous function, or they can be passed as the anonymous function’s arguments:

// Define IIFE module with dependencies. const iifeCounterModule = ((dependencyModule1, dependencyModule2) => { let count = 0; return { increase: () => ++count, reset: () => { count = 0; console.log("Count is reset."); } }; })(dependencyModule1, dependencyModule2);

The early version of popular libraries, like jQuery, followed this pattern. (The latest version of jQuery follows the UMD module, which is explained later in this article.)

Revealing module: JavaScript revealing module pattern

The revealing module pattern is named by Christian Heilmann. This pattern is also an IIFE, but it emphasizes defining all APIs as local variables inside the anonymous function:

// Define revealing module. const revealingCounterModule = (() => { let count = 0; const increase = () => ++count; const reset = () => { count = 0; console.log("Count is reset."); }; return { increase, reset }; })(); // Use revealing module. revealingCounterModule.increase(); revealingCounterModule.reset();

With this syntax, it becomes easier when the APIs need to call each other.

CJS module: CommonJS module, or Node.js module

CommonJS, initially named ServerJS, is a pattern to define and consume modules. It is implemented by Node,js. By default, each .js file is a CommonJS module. A module variable and an exports variable are provided for a module (a file) to expose APIs. And a require function is provided to load and consume a module. The following code defines the counter module in CommonJS syntax:

// Define CommonJS module: commonJSCounterModule.js. const dependencyModule1 = require("./dependencyModule1"); const dependencyModule2 = require("./dependencyModule2"); let count = 0; const increase = () => ++count; const reset = () => { count = 0; console.log("Count is reset."); }; exports.increase = increase; exports.reset = reset; // Or equivalently: module.exports = { increase, reset };

The following example consumes the counter module:

// Use CommonJS module. const { increase, reset } = require("./commonJSCounterModule"); increase(); reset(); // Or equivelently: const commonJSCounterModule = require("./commonJSCounterModule"); commonJSCounterModule.increase(); commonJSCounterModule.reset();

At runtime, Node.js implements this by wrapping the code inside the file into a function, then passes the exports variable, module variable, and require function through arguments.

// Define CommonJS module: wrapped commonJSCounterModule.js. (function (exports, require, module, __filename, __dirname) { const dependencyModule1 = require("./dependencyModule1"); const dependencyModule2 = require("./dependencyModule2"); let count = 0; const increase = () => ++count; const reset = () => { count = 0; console.log("Count is reset."); }; module.exports = { increase, reset }; return module.exports; }).call(thisValue, exports, require, module, filename, dirname); // Use CommonJS module. (function (exports, require, module, __filename, __dirname) { const commonJSCounterModule = require("./commonJSCounterModule"); commonJSCounterModule.increase(); commonJSCounterModule.reset(); }).call(thisValue, exports, require, module, filename, dirname);

AMD module: Asynchronous Module Definition, or RequireJS module

AMD (Asynchronous Module Definition https://github.com/amdjs/amdjs-api), is a pattern to define and consume module. It is implemented by RequireJS library https://requirejs.org/. AMD provides a define function to define module, which accepts the module name, dependent modules’ names, and a factory function:

// Define AMD module. define("amdCounterModule", ["dependencyModule1", "dependencyModule2"], (dependencyModule1, dependencyModule2) => { let count = 0; const increase = () => ++count; const reset = () => { count = 0; console.log("Count is reset."); }; return { increase, reset }; });

It also provides a require function to consume module:

// Use AMD module. require(["amdCounterModule"], amdCounterModule => { amdCounterModule.increase(); amdCounterModule.reset(); });

The AMD require function is totally different from the CommonJS require function. AMD require accept the names of modules to be consumed, and pass the module to a function argument.

Dynamic loading

AMD’s define function has another overload. It accepts a callback function, and pass a CommonJS-like require function to that callback. Inside the callback function, require can be called to dynamically load the module:

// Use dynamic AMD module. define(require => { const dynamicDependencyModule1 = require("dependencyModule1"); const dynamicDependencyModule2 = require("dependencyModule2"); let count = 0; const increase = () => ++count; const reset = () => { count = 0; console.log("Count is reset."); }; return { increase, reset }; });

AMD module from CommonJS module

The above define function overload can also passes the require function as well as exports variable and module to its callback function. So inside the callback, CommonJS syntax code can work:

// Define AMD module with CommonJS code. define((require, exports, module) => { // CommonJS code. const dependencyModule1 = require("dependencyModule1"); const dependencyModule2 = require("dependencyModule2"); let count = 0; const increase = () => ++count; const reset = () => { count = 0; console.log("Count is reset."); }; exports.increase = increase; exports.reset = reset; }); // Use AMD module with CommonJS code. define(require => { // CommonJS code. const counterModule = require("amdCounterModule"); counterModule.increase(); counterModule.reset(); });

UMD module: Universal Module Definition, or UmdJS module

UMD (Universal Module Definition, https://github.com/umdjs/umd) is a set of tricky patterns to make your code file work in multiple environments.

UMD for both AMD (RequireJS) and native browser

For example, the following is a kind of UMD pattern to make module definition work with both AMD (RequireJS) and native browser:

// Define UMD module for both AMD and browser. ((root, factory) => { // Detects AMD/RequireJS"s define function. if (typeof define === "function" && define.amd) { // Is AMD/RequireJS. Call factory with AMD/RequireJS"s define function. define("umdCounterModule", ["deependencyModule1", "dependencyModule2"], factory); } else { // Is Browser. Directly call factory. // Imported dependencies are global variables(properties of window object). // Exported module is also a global variable(property of window object) root.umdCounterModule = factory(root.deependencyModule1, root.dependencyModule2); } })(typeof self !== "undefined" ? self : this, (deependencyModule1, dependencyModule2) => { // Module code goes here. let count = 0; const increase = () => ++count; const reset = () => { count = 0; console.log("Count is reset."); }; return { increase, reset }; });

It is more complex but it is just an IIFE. The anonymous function detects if AMD’s define function exists.

If yes, call the module factory with AMD’s define function.
If not, it calls the module factory directly. At this moment, the root argument is actually the browser’s window object. It gets dependency modules from global variables (properties of window object). When factory returns the module, the returned module is also assigned to a global variable (property of window object).

UMD for both AMD (RequireJS) and CommonJS (Node.js)

The following is another kind of UMD pattern to make module definition work with both AMD (RequireJS) and CommonJS (Node.js):

(define => define((require, exports, module) => { // Module code goes here. const dependencyModule1 = require("dependencyModule1"); const dependencyModule2 = require("dependencyModule2"); let count = 0; const increase = () => ++count; const reset = () => { count = 0; console.log("Count is reset."); }; module.export = { increase, reset }; }))(// Detects module variable and exports variable of CommonJS/Node.js. // Also detect the define function of AMD/RequireJS. typeof module === "object" && module.exports && typeof define !== "function" ? // Is CommonJS/Node.js. Manually create a define function. factory => module.exports = factory(require, exports, module) : // Is AMD/RequireJS. Directly use its define function. define);

Again, don’t be scared. It is just another IIFE. When the anonymous function is called, its argument is evaluated. The argument evaluation detects the environment (check the module variable and exports variable of CommonJS/Node.js, as well as the define function of AMD/RequireJS).

If the environment is CommonJS/Node.js, the anonymous function’s argument is a manually created define function.
If the environment is AMD/RequireJS, the anonymous function’s argument is just AMD’s define function. So when the anonymous function is executed, it is guaranteed to have a working define function. Inside the anonymous function, it simply calls the define function to create the module.

ES module: ECMAScript 2015, or ES6 module

After all the module mess, in 2015, JavaScript’s spec version 6 introduces one more different module syntax. This spec is called ECMAScript 2015 (ES2015), or ECMAScript 6 (ES6). The main syntax is the import keyword and the export keyword. The following example uses new syntax to demonstrate ES module’s named import/export and default import/export:

// Define ES module: esCounterModule.js or esCounterModule.mjs. import dependencyModule1 from "./dependencyModule1.mjs"; import dependencyModule2 from "./dependencyModule2.mjs"; let count = 0; // Named export: export const increase = () => ++count; export const reset = () => { count = 0; console.log("Count is reset."); }; // Or default export: export default { increase, reset };

To use this module file in browser, add a <script> tag and specify it is a module: <script type="module" src="esCounterModule.js"></script>. To use this module file in Node.js, rename its extension from .js to .mjs.

// Use ES module. // Browser: <script type="module" src="esCounterModule.js"></script> or inline. // Server: esCounterModule.mjs // Import from named export. import { increase, reset } from "./esCounterModule.mjs"; increase(); reset(); // Or import from default export: import esCounterModule from "./esCounterModule.mjs"; esCounterModule.increase(); esCounterModule.reset();

For browser, <script>’s nomodule attribute can be used for fallback:

ES dynamic module: ECMAScript 2020, or ES11 dynamic module

In 2020, the latest JavaScript spec version 11 is introducing a built-in function import to consume an ES module dynamically. The import function returns a promise, so its then method can be called to consume the module:

// Use dynamic ES module with promise APIs, import from named export: import("./esCounterModule.js").then(({ increase, reset }) => { increase(); reset(); }); // Or import from default export: import("./esCounterModule.js").then(dynamicESCounterModule => { dynamicESCounterModule.increase(); dynamicESCounterModule.reset(); });

By returning a promise, apparently, import function can also work with the await keyword:

// Use dynamic ES module with async/await. (async () => { // Import from named export: const { increase, reset } = await import("./esCounterModule.js"); increase(); reset(); // Or import from default export: const dynamicESCounterModule = await import("./esCounterModule.js"); dynamicESCounterModule.increase(); dynamicESCounterModule.reset(); })();

The following is the compatibility of import/dynamic import/export, from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules:

System module: SystemJS module

SystemJS is a library that can enable ES module syntax for older ES. For example, the following module is defined in ES 6syntax:

// Define ES module. import dependencyModule1 from "./dependencyModule1.js"; import dependencyModule2 from "./dependencyModule2.js"; dependencyModule1.api1(); dependencyModule2.api2(); let count = 0; // Named export: export const increase = function () { return ++count }; export const reset = function () { count = 0; console.log("Count is reset."); }; // Or default export: export default { increase, reset }

If the current runtime, like an old browser, does not support ES6 syntax, the above code cannot work. One solution is to transpile the above module definition to a call of SystemJS library API, System.register:

// Define SystemJS module. System.register(["./dependencyModule1.js", "./dependencyModule2.js"], function (exports_1, context_1) { "use strict"; var dependencyModule1_js_1, dependencyModule2_js_1, count, increase, reset; var __moduleName = context_1 && context_1.id; return { setters: [ function (dependencyModule1_js_1_1) { dependencyModule1_js_1 = dependencyModule1_js_1_1; }, function (dependencyModule2_js_1_1) { dependencyModule2_js_1 = dependencyModule2_js_1_1; } ], execute: function () { dependencyModule1_js_1.default.api1(); dependencyModule2_js_1.default.api2(); count = 0; // Named export: exports_1("increase", increase = function () { return ++count }; exports_1("reset", reset = function () { count = 0; console.log("Count is reset."); };); // Or default export: exports_1("default", { increase, reset }); } }; });

So that the import/export new ES6 syntax is gone. The old API call syntax works for sure. This transpilation can be done automatically with Webpack, TypeScript, etc., which are explained later in this article.

Dynamic module loading

SystemJS also provides an import function for dynamic import:

// Use SystemJS module with promise APIs. System.import("./esCounterModule.js").then(dynamicESCounterModule => { dynamicESCounterModule.increase(); dynamicESCounterModule.reset(); });

Webpack module: bundle from CJS, AMD, ES modules

Webpack is a bundler for modules. It transpiles combined CommonJS module, AMD module, and ES module into a single harmony module pattern, and bundle all code into a single file. For example, the following 3 files define 3 modules in 3 different syntaxes:

// Define AMD module: amdDependencyModule1.js define("amdDependencyModule1", () => { const api1 = () => { }; return { api1 }; }); // Define CommonJS module: commonJSDependencyModule2.js const dependencyModule1 = require("./amdDependencyModule1"); const api2 = () => dependencyModule1.api1(); exports.api2 = api2; // Define ES module: esCounterModule.js. import dependencyModule1 from "./amdDependencyModule1"; import dependencyModule2 from "./commonJSDependencyModule2"; dependencyModule1.api1(); dependencyModule2.api2(); let count = 0; const increase = () => ++count; const reset = () => { count = 0; console.log("Count is reset."); }; export default { increase, reset }

And the following file consumes the counter module:

// Use ES module: index.js import counterModule from "./esCounterModule"; counterModule.increase(); counterModule.reset();

Webpack can bundle all the above file, even they are in 3 different module systems, into a single file main.js:

root
- dist
  - main.js (Bundle of all files under src)
- src
  - amdDependencyModule1.js
  - commonJSDependencyModule2.js
  - esCounterModule.js
  - index.js
- webpack.config.js

Since Webpack is based on Node.js, Webpack uses CommonJS module syntax for itself. In webpack.config.js:

const path = require('path'); module.exports = { entry: './src/index.js', mode: "none", // Do not optimize or minimize the code for readability. output: { filename: 'main.js', path: path.resolve(__dirname, 'dist'), }, };

Now run the following command to transpile and bundle all 4 files, which are in different syntax:

npm install webpack webpack-cli --save-dev npx webpack --config webpack.config.js

AS a result, Webpack generates the bundle file main.js. The following code in main.js is reformatted, and variables are renamed, to improve readability:

Again, it is just another IIFE. The code of all 4 files is transpiled to the code in 4 functions in an array. And that array is passed to the anonymous function as an argument.

Babel module: transpile from ES module

Babel is another transpiler to convert ES6+ JavaScript code to the older syntax for the older environment like older browsers. The above counter module in ES6 import/export syntax can be converted to the following babel module with new syntax replaced:

// Babel. Object.defineProperty(exports, "__esModule", { value: true }); exports["default"] = void 0; function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { "default": obj }; } // Define ES module: esCounterModule.js. var dependencyModule1 = _interopRequireDefault(require("./amdDependencyModule1")); var dependencyModule2 = _interopRequireDefault(require("./commonJSDependencyModule2")); dependencyModule1["default"].api1(); dependencyModule2["default"].api2(); var count = 0; var increase = function () { return ++count; }; var reset = function () { count = 0; console.log("Count is reset."); }; exports["default"] = { increase: increase, reset: reset };

And here is the code in index.js which consumes the counter module:

// Babel. function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { "default": obj }; } // Use ES module: index.js var esCounterModule = _interopRequireDefault(require("./esCounterModule.js")); esCounterModule["default"].increase(); esCounterModule["default"].reset();

This is the default transpilation. Babel can also work with other tools.

Babel with SystemJS

SystemJS can be used as a plugin for Babel:

npm install --save-dev @babel/plugin-transform-modules-systemjs

And it should be added to the Babel configuration babel.config.json:

{ "plugins": ["@babel/plugin-transform-modules-systemjs"], "presets": [ [ "@babel/env", { "targets": { "ie": "11" } } ] ] }

Now Babel can work with SystemJS to transpile CommonJS/Node.js module, AMD/RequireJS module, and ES module:

npx babel src --out-dir lib

The result is:

root
- lib
  - amdDependencyModule1.js (Transpiled with SystemJS)
  - commonJSDependencyModule2.js (Transpiled with SystemJS)
  - esCounterModule.js (Transpiled with SystemJS)
  - index.js (Transpiled with SystemJS)
- src
  - amdDependencyModule1.js
  - commonJSDependencyModule2.js
  - esCounterModule.js
  - index.js
- babel.config.json

Now all the ADM, CommonJS, and ES module syntax are transpiled to SystemJS syntax:

// Transpile AMD/RequireJS module definition to SystemJS syntax: lib/amdDependencyModule1.js. System.register([], function (_export, _context) { "use strict"; return { setters: [], execute: function () { // Define AMD module: src/amdDependencyModule1.js define("amdDependencyModule1", () => { const api1 = () => { }; return { api1 }; }); } }; }); // Transpile CommonJS/Node.js module definition to SystemJS syntax: lib/commonJSDependencyModule2.js. System.register([], function (_export, _context) { "use strict"; var dependencyModule1, api2; return { setters: [], execute: function () { // Define CommonJS module: src/commonJSDependencyModule2.js dependencyModule1 = require("./amdDependencyModule1"); api2 = () => dependencyModule1.api1(); exports.api2 = api2; } }; }); // Transpile ES module definition to SystemJS syntax: lib/esCounterModule.js. System.register(["./amdDependencyModule1", "./commonJSDependencyModule2"], function (_export, _context) { "use strict"; var dependencyModule1, dependencyModule2, count, increase, reset; return { setters: [function (_amdDependencyModule) { dependencyModule1 = _amdDependencyModule.default; }, function (_commonJSDependencyModule) { dependencyModule2 = _commonJSDependencyModule.default; }], execute: function () { // Define ES module: src/esCounterModule.js. dependencyModule1.api1(); dependencyModule2.api2(); count = 0; increase = () => ++count; reset = () => { count = 0; console.log("Count is reset."); }; _export("default", { increase, reset }); } }; }); // Transpile ES module usage to SystemJS syntax: lib/index.js. System.register(["./esCounterModule"], function (_export, _context) { "use strict"; var esCounterModule; return { setters: [function (_esCounterModuleJs) { esCounterModule = _esCounterModuleJs.default; }], execute: function () { // Use ES module: src/index.js esCounterModule.increase(); esCounterModule.reset(); } }; });

TypeScript module: Transpile to CJS, AMD, ES, System modules

TypeScript supports all JavaScript syntax, including the ES6 module syntax https://www.typescriptlang.org/docs/handbook/modules.html. When TypeScript transpiles, the ES module code can either be kept as ES6, or transpiled to other formats, including CommonJS/Node.js, AMD/RequireJS, UMD/UmdJS, or System/SystemJS, according to the specified transpiler options in tsconfig.json:

{ "compilerOptions": { "module": "ES2020", // None, CommonJS, AMD, System, UMD, ES6, ES2015, ES2020, ESNext. } }

For example:

// TypeScript and ES module. // With compilerOptions: { module: "ES6" }. Transpile to ES module with the same import/export syntax. import dependencyModule from "./dependencyModule"; dependencyModule.api(); let count = 0; export const increase = function () { return ++count }; // With compilerOptions: { module: "CommonJS" }. Transpile to CommonJS/Node.js module: var __importDefault = (this && this.__importDefault) || function (mod) { return (mod && mod.__esModule) ? mod : { "default": mod }; }; exports.__esModule = true; var dependencyModule_1 = __importDefault(require("./dependencyModule")); dependencyModule_1["default"].api(); var count = 0; exports.increase = function () { return ++count; }; // With compilerOptions: { module: "AMD" }. Transpile to AMD/RequireJS module: var __importDefault = (this && this.__importDefault) || function (mod) { return (mod && mod.__esModule) ? mod : { "default": mod }; }; define(["require", "exports", "./dependencyModule"], function (require, exports, dependencyModule_1) { "use strict"; exports.__esModule = true; dependencyModule_1 = __importDefault(dependencyModule_1); dependencyModule_1["default"].api(); var count = 0; exports.increase = function () { return ++count; }; }); // With compilerOptions: { module: "UMD" }. Transpile to UMD/UmdJS module: var __importDefault = (this && this.__importDefault) || function (mod) { return (mod && mod.__esModule) ? mod : { "default": mod }; }; (function (factory) { if (typeof module === "object" && typeof module.exports === "object") { var v = factory(require, exports); if (v !== undefined) module.exports = v; } else if (typeof define === "function" && define.amd) { define(["require", "exports", "./dependencyModule"], factory); } })(function (require, exports) { "use strict"; exports.__esModule = true; var dependencyModule_1 = __importDefault(require("./dependencyModule")); dependencyModule_1["default"].api(); var count = 0; exports.increase = function () { return ++count; }; }); // With compilerOptions: { module: "System" }. Transpile to System/SystemJS module: System.register(["./dependencyModule"], function (exports_1, context_1) { "use strict"; var dependencyModule_1, count, increase; var __moduleName = context_1 && context_1.id; return { setters: [ function (dependencyModule_1_1) { dependencyModule_1 = dependencyModule_1_1; } ], execute: function () { dependencyModule_1["default"].api(); count = 0; exports_1("increase", increase = function () { return ++count; }); } }; });

The ES module syntax supported in TypeScript was called external modules.

Internal module and namespace

TypeScript also has a module keyword and a namespace keyword https://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html#pitfalls-of-namespaces-and-modules. They were called internal modules:

module Counter { let count = 0; export const increase = () => ++count; export const reset = () => { count = 0; console.log("Count is reset."); }; } namespace Counter { let count = 0; export const increase = () => ++count; export const reset = () => { count = 0; console.log("Count is reset."); }; }

They are both transpiled to JavaScript objects:

var Counter; (function (Counter) { var count = 0; Counter.increase = function () { return ++count; }; Counter.reset = function () { count = 0; console.log("Count is reset."); }; })(Counter || (Counter = {}));

TypeScript module and namespace can have multiple levels by supporting the . separator:

module Counter.Sub { let count = 0; export const increase = () => ++count; } namespace Counter.Sub { let count = 0; export const increase = () => ++count; }

The the sub module and sub namespace are both transpiled to object’s property:

var Counter; (function (Counter) { var Sub; (function (Sub) { var count = 0; Sub.increase = function () { return ++count; }; })(Sub = Counter.Sub || (Counter.Sub = {})); })(Counter|| (Counter = {}));

TypeScript module and namespace can also be used in the export statement:

module Counter { let count = 0; export module Sub { export const increase = () => ++count; } } module Counter { let count = 0; export namespace Sub { export const increase = () => ++count; } }

The transpilation is the same as submodule and sub-namespace:

var Counter; (function (Counter) { var count = 0; var Sub; (function (Sub) { Sub.increase = function () { return ++count; }; })(Sub = Counter.Sub || (Counter.Sub = {})); })(Counter || (Counter = {}));

Conclusion

Welcome to JavaScript, which has so much drama - 10+ systems/formats just for modularization/namespace:

IIFE module: JavaScript module pattern
Revealing module: JavaScript revealing module pattern
CJS module: CommonJS module, or Node.js module
AMD module: Asynchronous Module Definition, or RequireJS module
UMD module: Universal Module Definition, or UmdJS module
ES module: ECMAScript 2015, or ES6 module
ES dynamic module: ECMAScript 2020, or ES11 dynamic module
System module: SystemJS module
Webpack module: transpile and bundle of CJS, AMD, ES modules
Babel module: transpile ES module
TypeScript module and namespace

Fortunately, now JavaScript has standard built-in language features for modules, and it is supported by Node.js and all the latest modern browsers. For the older environments, you can still code with the new ES module syntax, then use Webpack/Babel/SystemJS/TypeScript to transpile to older or compatible syntax.

Port Microsoft Concurrency Visualizer SDK to .NET Standard and NuGet

Fri, 24 Jan 2025 18:27:00 GMT

I uploaded a NuGet package of Microsoft Concurrency Visualizer SDK: ConcurrencyVisualizer. Microsoft Concurrency Visualizer is an extension tool for Visual Studio. It is a great tool for performance profiling and multithreading execution visualization. It also has a SDK library to be invoked by code and draw markers and spans in the timeline. I used it to visualize sequential LINQ and Parallel LINQ (PLINQ) execution in my Functional Programming and LINQ tutorials. For example, array.Where(…).Select(…) sequential LINQ query and array.AsParallel().Where(…).Select(…) Parallel LINQ query can be visualized as following spans:

The Concurrency Visualizer is available in Visual Studio Marketplace:

And the SDK library is available for .NET Framework, and can be installed from menu item:

This adds a reference to local assembly C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\4hhyuhoo.ghy\SDK\Managed\4.0\Microsoft.ConcurrencyVisualizer.Markers.dll. For your convenience, I have made a NuGet package:

Install-Package ConcurrencyVisualizer

It makes your code more potable. I have also ported the code to .NET Standard, so now the SDK can work with .NET Framework, .NET Core, etc.:

Now the Concurrency Visualizer tool can visualize markers and spans of .NET Core correctly.

TransientFaultHandling.Core: Retry library for .NET Core/.NET Standard

Wed, 22 Jan 2025 18:09:00 GMT

TransientFaultHandling.Core is retry library for transient error handling. It is ported from Microsoft Enterprise Library’s TransientFaultHandling library, a library widely used with .NET Framework. The retry pattern APIs are ported to .NET Core/.NET Standard, with outdated configuration API updated, and new retry APIs added for convenience.

Introduction

With this library, the old code of retry logic based on Microsoft Enterprise Library can be ported to .NET Core/.NET Standard without modification:

ITransientErrorDetectionStrategy transientExceptionDetection = new MyDetection();
RetryStrategy retryStrategy = new FixedInterval(retryCount: 5, retryInterval: TimeSpan.FromSeconds(1));
RetryPolicy retryPolicy = new RetryPolicy(transientExceptionDetection, retryStrategy);
string result = retryPolicy.ExecuteAction(() => webClient.DownloadString("https://DixinYan.com"));

With this library, it is extremely easy to detect transient exception and implement retry logic. For example, the following code downloads a string, if the exception thrown is transient (a WebException), it retries up to 5 times, and it waits for 1 second between retries:

Retry.FixedInterval(
    () => webClient.DownloadString("https://DixinYan.com"),
    isTransient: exception => exception is WebException,
    retryCount: 5, retryInterval: TimeSpan.FromSeconds(1));

Fluent APIs are also provided for even better readability:

Retry
    .WithIncremental(retryCount: 5, initialInterval: TimeSpan.FromSeconds(1),
        increment: TimeSpan.FromSeconds(1))
    .Catch<OperationCanceledException>()
    .Catch<WebException>(exception =>
        exception.Response is HttpWebResponse response && response.StatusCode == HttpStatusCode.RequestTimeout)
    .ExecuteAction(() => webClient.DownloadString("https://DixinYan.com"));

It also supports JSON/XML/INI configuration:

{
  "retryStrategy": {
    "name1": {
      "fastFirstRetry": "true",
      "retryCount": 5,
      "retryInterval": "00:00:00.1"
    },
    "name2": {
      "fastFirstRetry": "true",
      "retryCount": 55,
      "initialInterval": "00:00:00.2",
      "increment": "00:00:00.3"
    }
  }
}

Document

https://weblogs.asp.net/dixin/transientfaulthandling-core-retry-library-for-net-core-net-standard

Source

https://github.com/Dixin/EnterpriseLibrary.TransientFaultHandling.Core (Partially ported from Topaz, with additional new APIs and updated configuration APIs).

NuGet installation

It can be installed through NuGet using .NET CLI:

dotnet add package EnterpriseLibrary.TransientFaultHandling.Core

dotnet add package TransientFaultHandling.Caching

dotnet add package TransientFaultHandling.Configuration

dotnet add package TransientFaultHandling.Data

Or in Visual Studio NuGet Package Manager Console:

Install-Package EnterpriseLibrary.TransientFaultHandling.Core

Install-Package TransientFaultHandling.Caching

Install-Package TransientFaultHandling.Configuration

Install-Package TransientFaultHandling.Data

Backward compatibility with Enterprise Library

This library provides maximum backward compatibility with Microsoft Enterprise Library’s TransientFaultHandling (aka Topaz) for .NET Framework:

If you have code using EnterpriseLibrary.TransientFaultHandling, you can port your code to use EnterpriseLibrary.TransientFaultHandling.Core, without any modification.
If you have code using EnterpriseLibrary.TransientFaultHandling.Caching, you can port your code to use TransientFaultHandling.Caching, without any modification.
If you have code using EnterpriseLibrary.TransientFaultHandling.Data, you can port your code to use TransientFaultHandling.Data, without any modification.
If you have code and configuration based on EnterpriseLibrary.TransientFaultHandling.Configuration, you have to change your code and configuration to use TransientFaultHandling.Configuration. The old XML configuration infrastructure based on .NET Framework is outdated. You need to replace the old XML format with new XML/JSON/INI format configuration supported by .NET Core/.NET Standard.

How to use the APIs

For retry pattern, please read Microsoft’s introduction in Cloud Design Patterns. For the introduction of transient fault handling, read Microsoft’s Perseverance, Secret of All Triumphs: Using the Transient Fault Handling Application Block and Microsoft Azure Architecture Center’s Best practice - Transient fault handling.

Object-oriented APIs from Enterprise Library

Enterprise Library existing APIs follows an object-oriented design. For the details, please see Microsoft’s API reference and ebook Developer's Guide to Microsoft Enterprise Library‘s Chapter 4, Using the Transient Fault Handling Application Block. Here is a brief introduction.

First, ITransientErrorDetectionStrategy interface must be implemented. It has a single method IsTransient to detected if the thrown exception is transient and retry should be executed.

internal class MyDetection : ITransientErrorDetectionStrategy
{
    bool IsTransient(Exception exception) => 
        exception is OperationCanceledException;
}

Second, a retry strategy must be defined to specify how the retry is executed, like retry count, retry interval, etc.. a retry strategy must inherit RetryStrategy abstract class. There are 3 built-in retry strategies: FixedInterval, Incremental, ExponentialBackoff.

Then a retry policy (RetryPolicy class) must be instantiated with a retry strategy and an ITransientErrorDetectionStrategy interface. a retry policy has an ExecuteAction method to execute the specified synchronous function, and an ExecuteAsync method to execute a\the specified async function. It also has a Retrying event. When the executed sync/async function throws an exception, if the exception is detected to be transient and max retry count is not reached, then it waits for the specified retry interval, and then it fires the Retrying event, and execute the specified sync/async function again.

RetryStrategy retryStrategy = new FixedInterval(retryCount: 5, retryInterval: TimeSpan.FromSeconds(1));

RetryPolicy retryPolicy = new RetryPolicy(new MyDetection(), retryStrategy);
retryPolicy.Retrying += (sender, args) =>
    Console.WriteLine($@"{args.CurrentRetryCount}: {args.LastException}");

using (WebClient webClient = new WebClient())
{
    string result1 = retryPolicy.ExecuteAction(() => webClient.DownloadString("https://DixinYan.com"));
    string result2 = await retryPolicy.ExecuteAsync(() => webClient.DownloadStringTaskAsync("https://DixinYan.com"));
}

New functional APIs: single function call for retry

The above object-oriented API design is very inconvenient. New static functions Retry.FixedInterval, Retry.Incremental, Retry.ExponentialBackoff are added to implement retry with a single function call. For example:

Retry.FixedInterval(
    () => webClient.DownloadString("https://DixinYan.com"),
    isTransient: exception => exception is OperationCanceledException,
    retryCount: 5, retryInterval: TimeSpan.FromSeconds(1),
    retryingHandler: (sender, args) =>
        Console.WriteLine($@"{args.CurrentRetryCount}: {args.LastException}"));

await Retry.IncrementalAsync(
    () => webClient.DownloadStringTaskAsync("https://DixinYan.com"),
    isTransient: exception => exception is OperationCanceledException,
    retryCount: 5, initialInterval: TimeSpan.FromSeconds(1), increment: TimeSpan.FromSeconds(2));

These sync and async functions are very convenient because only the first argument (action to execute) is required. All the other arguments are optional. And a function can be defined inline to detect transient exception, instead of defining a type to implement an interface:

// Treat any exception as transient. Use default retry count, default interval. No event handler.
Retry.FixedInterval(() => webClient.DownloadString("https://DixinYan.com"));

// Treat any exception as transient. Specify retry count. Use default initial interval, default increment. No event handler.
await Retry.IncrementalAsync(
    () => webClient.DownloadStringTaskAsync("https://DixinYan.com"),
    retryCount: 10);

New fluent APIs for retry

For better readability, new fluent APIs are provided:

Retry
    .WithFixedInterval(retryCount: 5, retryInterval: TimeSpan.FromSeconds(1))
    .Catch(exception =>
        exception is OperationCanceledException ||
        exception is HttpListenerException httpListenerException && httpListenerException.ErrorCode == 404)
    .HandleWith((sender, args) =>
        Console.WriteLine($@"{args.CurrentRetryCount}: {args.LastException}"))
    .ExecuteAction(() => MyTask());

The HandleWith call adds an event handler to the Retying event. It is optional:

Retry
    .WithFixedInterval(retryCount: 5, retryInterval: TimeSpan.FromSeconds(1))
    .Catch(exception =>
        exception is OperationCanceledException ||
        exception is HttpListenerException httpListenerException && httpListenerException.ErrorCode == 404)
    .ExecuteAction(() => MyTask());

Catch method has a generic overload. The above code is equivalent to:

Retry
    .WithFixedInterval(retryCount: 5, retryInterval: TimeSpan.FromSeconds(1))
    .Catch<OperationCanceledException>()
    .Catch<HttpListenerException>(exception => exception.ErrorCode == 404)
    .ExecuteAction(() => MyTask());

The following code “catches” any exception as transient:

Retry
    .WithIncremental(retryCount: 5, increment: TimeSpan.FromSeconds(1)) // Use default initial interval.
    .Catch() // Equivalent to: .Catch<Exception>()
    .ExecuteAction(() => MyTask());

Old XML configuration for retry

Ditched the following old XML format from .NET Framework:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="RetryPolicyConfiguration" type="Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.Configuration.RetryPolicyConfigurationSettings, Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.Configuration" />
  </configSections>
  <RetryPolicyConfiguration>
    <fixedInterval name="FixedIntervalDefault" maxRetryCount="10" retryInterval="00:00:00.1" />
    <incremental name="IncrementalIntervalDefault" maxRetryCount="10" initialInterval="00:00:00.01" retryIncrement="00:00:00.05" />
    <exponentialBackoff name="ExponentialIntervalDefault" maxRetryCount="10" minBackoff="100" maxBackoff="1000" deltaBackoff="100" />
  </RetryPolicyConfiguration>
</configuration>

These old XML infrastructures are outdated. Use new XML/JSON/INI format configuration supported by .NET Standard/.NET Core.

New XML/JSON/INI configuration for retry

Please install TransientFaultHandling.Configuration package. The following is an example JSON configuration file app.json. It has 3 retry strategies, a FixedInterval retry strategy, a Incremental retry strategy, and an ExponentialBackoff retry strategy:

{
  "retryStrategy": {
    "name1": {
      "fastFirstRetry": "true",
      "retryCount": 5,
      "retryInterval": "00:00:00.1"
    },
    "name2": {
      "fastFirstRetry": "true",
      "retryCount": 55,
      "initialInterval": "00:00:00.2",
      "increment": "00:00:00.3"
    },
    "name3": {
      "fastFirstRetry": "true",
      "retryCount": 555,
      "minBackoff": "00:00:00.4",
      "maxBackoff": "00:00:00.5",
      "deltaBackoff": "00:00:00.6"
    }
  }
}

The same configuration file app.xml in XML format:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <retryStrategy name="name1">
    <fastFirstRetry>true</fastFirstRetry>
    <retryCount>5</retryCount>
    <retryInterval>00:00:00.1</retryInterval>
  </retryStrategy>
  <retryStrategy name="name2">
    <fastFirstRetry>true</fastFirstRetry>
    <retryCount>55</retryCount>
    <initialInterval>00:00:00.2</initialInterval>
    <increment>00:00:00.3</increment>
  </retryStrategy>
  <retryStrategy name="name3">
    <fastFirstRetry>true</fastFirstRetry>
    <retryCount>555</retryCount>
    <minBackoff>00:00:00.4</minBackoff>
    <maxBackoff>00:00:00.5</maxBackoff>
    <deltaBackoff>00:00:00.6</deltaBackoff>
  </retryStrategy>
</configuration>

And app.ini file in INI format:

[retryStrategy:name1]
fastFirstRetry=true
retryCount=5
retryInterval=00:00:00.1

[retryStrategy:name2]
fastFirstRetry=true
retryCount=55
initialInterval=00:00:00.2
increment=00:00:00.3

[retryStrategy:name3]
fastFirstRetry=true
retryCount=5555
minBackoff=00:00:00.4
maxBackoff=00:00:00.5
deltaBackoff=00:00:00.6

These configurations can be easily loaded and deserialized into retry strategy instances:

IConfiguration configuration = new ConfigurationBuilder()
    .AddJsonFile("app.json") // or AddXml("app.xml") or AddIni("app.ini")
    .Build();

IDictionary<string, RetryStrategy> retryStrategies = configuration.GetRetryStrategies();
// or retryStrategies = configuration.GetRetryStrategies("yourConfigurationSectionKey");
// The default configuration section key is "retryStrategy".

The GetRetryStrategies extension method returns a dictionary of key value pairs, where each key is the specified name of retry strategy, and each value is the retry strategy instance. Here the first key is “name1”, the first value is a FixedInterval retry strategy instance. The second key is “anme2”, the second value is Incremental retry strategy instance. The third key is “name3”, the third value is ExponentialBackoff retry strategy instance. This extension method can also accept custom configuration section key, and a function to create instance of custom retry strategy type.

retryStrategies = configuration.GetRetryStrategies(
    key: "yourConfigurationSectionKey",
    getCustomRetryStrategy: configurationSection => new MyRetryStrategyType(...));

The other generic overload can filter the specified retry strategy type:

FixedInterval retryStrategy = configuration.GetRetryStrategies<FixedInterval>().Single().Value;

It still returns a dictionary, which only has the specified type of retry strategies.

TransientFaultHandling.Data.Core: SQL Server support

Since 2.1.0, both Microsoft.Data.SqlClient and System.Data.SqlClient are supported. A API breaking change is introduced for this. If you are using the latest Microsoft.Data.SqlClient, no code change is needed. If you are using the legacy System.Data.SqlClient, the following types are renamed with a Legacy suffix:

ReliableSqlConnection –> ReliableSqlConnectionLegacy
SqlDatabaseTransientErrorDetectionStrategy –> SqlDatabaseTransientErrorDetectionStrategyLegacy
SqlAzureTransientErrorDetectionStrategy –> SqlAzureTransientErrorDetectionStrategyLegacy

You can either rename these types or add the using directives:

using ReliableSqlConnection = Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.ReliableSqlConnectionLegacy;
using SqlDatabaseTransientErrorDetectionStrategy = Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.SqlDatabaseTransientErrorDetectionStrategyLegacy;
using SqlAzureTransientErrorDetectionStrategy = Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure.SqlAzureTransientErrorDetectionStrategyLegacy;

History

This library follows the http://semver.org standard for semantic versioning.

1.0.0: Initial release. Ported EnterpriseLibrary.TransientFaultHandling from .NET Framework to .NET Core/.NET Standard.

1.1.0: Add functional APIs for retry.
1.2.0: Add functional APIs for retry.

2.0.0: Add fluent APIs for retry. Ported EnterpriseLibrary.TransientFaultHandling.Caching from .NET Framework to .NET Core/.NET Standard. Ported EnterpriseLibrary.TransientFaultHandling.Data from .NET Framework to .NET Core/.NET Standard. Redesigned/reimplemented EnterpriseLibrary.TransientFaultHandling.Configuration with JSON in .NET Core/.NET Standard.
2.1.0: Add support for Microsoft.Data.SqlClient. Now both Microsoft.Data.SqlClient and System.Data.SqlClient are supported.

Category Theory via C# (8) Advanced LINQ to Monads

Tue, 31 Dec 2024 13:13:00 GMT

[FP & LINQ via C# series]

[Category Theory via C# series]

Monad is a powerful structure, with the LINQ support in C# language, monad enables chaining operations to build fluent workflow, which can be pure. With these features, monad can be used to manage I/O, state changes, exception handling, shared environment, logging/tracing, and continuation, etc., in the functional paradigm.

IO monad

IO is impure. As already demonstrated, the Lazy<> and Func<> monads can build purely function workflows consists of I/O operations. The I/O is produced only when the workflows is started. So the Func<> monad is also called IO monad (Again, Lazy<T> is just a wrapper of Func<T> factory function, so Lazy<> and Func<> can be viewed as equivalent.). Here, to be more intuitive, rename Func<> to IO<>:

// IO: () -> T
public delegate T IO<out T>();

Func<T> or IO<T> is just a wrapper of T. Generally, the difference is, if a value T is obtained, effect is already produced; and if a Func<T> or IO<T> function wrapper is obtained, the effect can be delayed to produce, until explicitly calling this function to pull the wrapped T value. The following example is a simple comparison:

public static partial class IOExtensions
{
    internal static string Impure()
    {
        string filePath = Console.ReadLine();
        string fileContent = File.ReadAllText(filePath);
        return fileContent;
    }

    internal static IO<string> Pure()
    {
        IO<string> filePath = () => Console.ReadLine();
        IO<string> fileContent = () => File.ReadAllText(filePath());
        return fileContent;
    }

    internal static void IO()
    {
        string ioResult1 = Impure(); // IO is produced.
        IO<string> ioResultWrapper = Pure(); // IO is not produced.

        string ioResult2 = ioResultWrapper(); // IO is produced.
    }
}

IO<> monad is just Func<> monad:

public static partial class IOExtensions
{
    // SelectMany: (IO<TSource>, TSource -> IO<TSelector>, (TSource, TSelector) -> TResult) -> IO<TResult>
    public static IO<TResult> SelectMany<TSource, TSelector, TResult>(
        this IO<TSource> source,
        Func<TSource, IO<TSelector>> selector,
        Func<TSource, TSelector, TResult> resultSelector) =>
            () =>
            {
                TSource value = source();
                return resultSelector(value, selector(value)());
            };

    // Wrap: TSource -> IO<TSource>
    public static IO<TSource> IO<TSource>(this TSource value) => () => value;

    // Select: (IO<TSource>, TSource -> TResult) -> IO<TResult>
    public static IO<TResult> Select<TSource, TResult>(
        this IO<TSource> source, Func<TSource, TResult> selector) =>
            source.SelectMany(value => selector(value).IO(), (value, result) => result);
}

The (SelectMany, Wrap, Select) operations are defined so that the LINQ functor syntax (single from clause) and monad syntax (multiple from clauses) are enabled. The let clause is also enabled by Select, which provides great convenience.

Some I/O operations, like above Console.ReadLine: () –> string, and File.ReadAllText: string –> string, returns a value T that can be wrapped IO<T>. There are other I/O operations that return void, like Console.WriteLine: string –> void, etc. Since C# compiler does not allow void to be used as type argument of IO<void>, these operations can be viewed as returning a Unit value, which can be wrapped as IO<Uint>. The following methods help wrap IO<T> functions from I/O operations with or without return value:

public static IO<TResult> IO<TResult>(Func<TResult> function) =>
    () => function();

public static IO<Unit> IO(Action action) =>
    () =>
    {
        action();
        return default;
    };

Now the I/O workflow can be build as purely function LINQ query:

internal static void Workflow()
{
    IO<int> query = from unit1 in IO(() => Console.WriteLine("File path:")) // IO<Unit>.
                    from filePath in IO(Console.ReadLine) // IO<string>.
                    from unit2 in IO(() => Console.WriteLine("File encoding:")) // IO<Unit>.
                    from encodingName in IO(Console.ReadLine) // IO<string>.
                    let encoding = Encoding.GetEncoding(encodingName)
                    from fileContent in IO(() => File.ReadAllText(filePath, encoding)) // IO<string>.
                    from unit3 in IO(() => Console.WriteLine("File content:")) // IO<Unit>.
                    from unit4 in IO(() => Console.WriteLine(fileContent)) // IO<Unit>.
                    select fileContent.Length; // Define query.
    int result = query(); // Execute query.
}

IO<> monad works with both synchronous and asynchronous I/O operations. The async version of IO<T> is just IO<Task<T>>, and the async version of IO<Unit> is just IO<Task>:

internal static async Task WorkflowAsync()
{
    using (HttpClient httpClient = new HttpClient())
    {
        IO<Task> query = from unit1 in IO(() => Console.WriteLine("URI:")) // IO<Unit>. 
                            from uri in IO(Console.ReadLine) // IO<string>.
                            from unit2 in IO(() => Console.WriteLine("File path:")) // IO<Unit>.
                            from filePath in IO(Console.ReadLine) // IO<string>.
                            from downloadStreamTask in IO(async () =>
                                await httpClient.GetStreamAsync(uri)) // IO<Task<Stream>>.
                            from writeFileTask in IO(async () => 
                                await (await downloadStreamTask).CopyToAsync(File.Create(filePath))) // IO<Task>.
                            from messageTask in IO(async () =>
                                {
                                    await writeFileTask;
                                    Console.WriteLine($"Downloaded {uri} to {filePath}");
                                }) // IO<Task>.
                            select messageTask; // Define query.
        await query(); // Execute query.
    }
}

State monad

In object-oriented programming, there is the state pattern to handle state changes. In functional programming, state change can be modeled with pure function. For pure function TSource –> TResult, its state-involved version can be represented as a Tuple<TSource, TState> –> Tuple<TResult, TState> function, which accepts some input value along with some input state, and returns some output value and some output state. This function can remains pure, because it can leave the input state unchanged, then either return the same old state, or create a new state and return it. To make this function monadic, break up the input tuple and curry the function to TSource –> (TState –> Tuple<TResult, TState>). Now the returned TState –> Tuple<TResult, TState> function type can be given an alias called State:

// State: TState -> ValueTuple<T, TState>
public delegate (T Value, TState State) State<TState, T>(TState state);

Similar to fore mentioned Tuple<,> and Func<,> types, the above open generic type State<,> can be viewed as a type constructor of kind * –> * –> *. After partially applied with a first type argument TState, State<TState,> becomes a * –> * type constructor. If it can be a functor and monad, then above stateful function becomes a monadic selector TSource –> State<TState, TResult>. So the following (SelectMany, Wrap, Select) methods can be defined for State<TState,>:

public static partial class StateExtensions
{
    // SelectMany: (State<TState, TSource>, TSource -> State<TState, TSelector>, (TSource, TSelector) -> TResult) -> State<TState, TResult>
    public static State<TState, TResult> SelectMany<TState, TSource, TSelector, TResult>(
        this State<TState, TSource> source,
        Func<TSource, State<TState, TSelector>> selector,
        Func<TSource, TSelector, TResult> resultSelector) =>
            oldState =>
            {
                (TSource Value, TState State) value = source(oldState);
                (TSelector Value, TState State) result = selector(value.Value)(value.State);
                TState newState = result.State;
                return (resultSelector(value.Value, result.Value), newState); // Output new state.
            };

    // Wrap: TSource -> State<TState, TSource>
    public static State<TState, TSource> State<TState, TSource>(this TSource value) =>
        oldState => (value, oldState); // Output old state.

    // Select: (State<TState, TSource>, TSource -> TResult) -> State<TState, TResult>
    public static State<TState, TResult> Select<TState, TSource, TResult>(
        this State<TState, TSource> source,
        Func<TSource, TResult> selector) =>
            oldState =>
            {
                (TSource Value, TState State) value = source(oldState);
                TState newState = value.State;
                return (selector(value.Value), newState); // Output new state.
            };
            // Equivalent to:            
            // source.SelectMany(value => selector(value).State<TState, TResult>(), (value, result) => result);
}

SelectMany and Select return a function that accepts an old state and outputs new state, State method returns a function that outputs the old state. Now this State<TState,> delegate type is the state monad, so a State<TState, T> function can be viewed as a wrapper of a T value, and this T value can be unwrapped in the monad workflow, with the from value in source syntax. State<TState, T> function also wraps the state information. To get/set the TState state in the monad workflow, the following GetState/SetState functions can be defined:

// GetState: () -> State<TState, TState>
public static State<TState, TState> GetState<TState>() =>
    oldState => (oldState, oldState); // Output old state.

// SetState: TState -> State<TState, Unit>
public static State<TState, Unit> SetState<TState>(TState newState) =>
    oldState => (default, newState); // Output new state.

Here GetState returns a State<TState, TState> function wrapping the state as value, so that the state can be extracted in the monad workflow with the same syntax that unwraps the value. SetState returns a State<TState, Unit> function, which ignores the old state, and wrap no value (represented by Unit) and outputs the the specified new value to the monad workflow. Generally, the state monad workflow can be demonstrated as:

internal static void Workflow()
{
    string initialState = nameof(initialState);
    string newState = nameof(newState);
    string resetState = nameof(resetState);
    State<string, int> source1 = oldState => (1, oldState);
    State<string, bool> source2 = oldState => (true, newState);
    State<string, char> source3 = '@'.State<string, char>(); // oldState => 2, oldState).

    State<string, string[]> query =
        from value1 in source1 // source1: State<string, int> = initialState => (1, initialState).
        from state1 in GetState<string>() // GetState<int>(): State<string, string> = initialState => (initialState, initialState).
        from value2 in source2 // source2: State<string, bool>3 = initialState => (true, newState).
        from state2 in GetState<string>() // GetState<int>(): State<string, string> = newState => (newState, newState).
        from unit in SetState(resetState) // SetState(resetState): State<string, Unit> = newState => (default, resetState).
        from state3 in GetState<string>() // GetState(): State<string, string> = resetState => (resetState, resetState).
        from value3 in source3 // source3: State<string, char> = resetState => (@, resetState).
        select new string[] { state1, state2, state3 }; // Define query.
    (string[] Value, string State) result = query(initialState); // Execute query with initial state.
    result.Value.WriteLines(); // initialState newState resetState
    result.State.WriteLine(); // Final state: resetState
}

The state monad workflow is a State<TState, T> function, which is of type TState –> Tuple<T, TState>. To execute the workflow, it must be called with a TState initial state. At runtime, when the workflow executes, the first operation in the workflow, also a TState –> Tuple<T, TState> function, is called with the workflow’s initial state, and returns a output value and a output state; then the second operation, once again another TState –> Tuple<T, TState> function, is called with the first operation’s output state, and outputs another output value and another output state; and so on. In this chaining, each operation function can wither return its original input state, or return a new state. This is how state changes through a workflow of pure functions.

Take the factorial function as example. The factorial function can be viewed as a recursive function with a state – the current product of the current recursion step, and apparently take the initial state (product) is 1. To calculate the factorial of 5, the recursive steps can be modeled as:

(Value: 5, State: 1) => (Value: 4, State: 1 * 5)
(Value: 4, State: 1 * 5) => (Value: 3, State: 1 * 5 * 4)
(Value: 3, State: 1 * 5 * 4) => (Value: 3, State: 1 * 5 * 4)
(Value: 2, State: 1 * 5 * 4 * 3) => (Value: 2, State: 1 * 5 * 4 * 3)
(Value: 1, State: 1 * 5 * 4 * 3 * 2) => (Value: 1, State: 1 * 5 * 4 * 3 * 2)
(Value: 0, State: 1 * 5 * 4 * 3 * 2 * 1) => (Value: 0, State: 1 * 5 * 4 * 3 * 2 * 1)

When the current integer becomes 0, the recursion terminates, and the final state (product) is the factorial result. So this recursive function is of type Tuple<int, int> –> Tuple<int, int>. As fore mentioned, it can be curried to int –> (int –> Tuple<int, int>), which is equivalent to int –> State<int, int>:

// FactorialState: uint -> (uint -> (uint, uint))
// FactorialState: uint -> State<unit, uint>
private static State<uint, uint> FactorialState(uint current) =>
    from state in GetState<uint>() // State<uint, uint>.
    let product = state
    let next = current - 1U
    from result in current > 0U
        ? (from unit in SetState(product * current) // State<unit, Unit>.
            from value in FactorialState(next) // State<uint, uint>.
            select next)
        : next.State<uint, uint>() // State<uint, uint>.
    select result;

public static uint Factorial(uint uInt32)
{
    State<uint, uint> query = FactorialState(uInt32); // Define query.
    return query(1).State; // Execute query, with initial state: 1.
}

Another example is Enumerable.Aggregate query method, which accepts an IEnumerable<TSource> sequence, a TAccumulate seed, and a TAccumulate –> TSource –> TAccumulate function. Aggregate calls the accumulation function over the seed and all the values in the sequence. The aggregation steps can also be modeled as recursive steps, where each step’s state is the current accumulate result and the unused source values. Take source sequence { 1, 2, 3, 4, 5 }, seed 0, and function + as example:

(Value: +, State: (0, { 1, 2, 3, 4 })) => (Value: +, State: (0 + 1, { 2, 3, 4 }))
(Value: +, State: (0 + 1, { 2, 3, 4 })) => (Value: +, State: (0 + 1 + 2, { 3, 4 }))
(Value: +, State: (0 + 1 + 2, { 3, 4 })) => (Value: +, State: (0 + 1 + 2 + 3, { 4 }))
(Value: +, State: (0 + 1 + 2 + 3, { 4 })) => (Value: +, State: (0 + 1 + 2 + 3 + 4, { }))
(Value: +, State: (0 + 1 + 2 + 3 + 4, { })) => (Value: +, State: (0 + 1 + 2 + 3 + 4, { }))

When the current source sequence in the state is empty, all source values are applied to the accumulate function, the recursion terminates, and the aggregation result in in the final state. So the recursive function is of type Tuple<TAccumulate –> TSource –> TAccumulate, Tuple<TAccumulate, IEnumerable<TSource>>> –> Tuple<TAccumulate –> TSource –> TAccumulate, Tuple<TAccumulate, IEnumerable<TSource>>>. Again, it can be curried to (TAccumulate –> TSource –> TAccumulate) –> (Tuple<TAccumulate, IEnumerable<TSource>> –> Tuple<TAccumulate –> TSource –> TAccumulate, Tuple<TAccumulate, IEnumerable<TSource>>>), which is equivalent to (TAccumulate –> TSource –> TAccumulate) –> State<Tuple<TAccumulate, IEnumerable<TSource>>, TAccumulate –> TSource –> TAccumulate>:

// AggregateState: (TAccumulate -> TSource -> TAccumulate) -> ((TAccumulate, IEnumerable<TSource>) -> (TAccumulate -> TSource -> TAccumulate, (TAccumulate, IEnumerable<TSource>)))
// AggregateState: TAccumulate -> TSource -> TAccumulate -> State<(TAccumulate, IEnumerable<TSource>), TAccumulate -> TSource -> TAccumulate>
private static State<(TAccumulate, IEnumerable<TSource>), Func<TAccumulate, TSource, TAccumulate>> AggregateState<TSource, TAccumulate>(
    Func<TAccumulate, TSource, TAccumulate> func) =>
        from state in GetState<(TAccumulate, IEnumerable<TSource>)>() // State<(TAccumulate, IEnumerable<TSource>), (TAccumulate, IEnumerable<TSource>)>.
        let accumulate = state.Item1 // TAccumulate.
        let source = state.Item2.Share() // IBuffer<TSource>.
        let sourceIterator = source.GetEnumerator() // IEnumerator<TSource>.
        from result in sourceIterator.MoveNext()
            ? (from unit in SetState((func(accumulate, sourceIterator.Current), source.AsEnumerable())) // State<(TAccumulate, IEnumerable<TSource>), Unit>.
                from value in AggregateState(func) // State<(TAccumulate, IEnumerable<TSource>), Func<TAccumulate, TSource, TAccumulate>>.
                select func)
            : func.State<(TAccumulate, IEnumerable<TSource>), Func<TAccumulate, TSource, TAccumulate>>() // State<(TAccumulate, IEnumerable<TSource>), Func<TAccumulate, TSource, TAccumulate>>.
        select result;

public static TAccumulate Aggregate<TSource, TAccumulate>(
    IEnumerable<TSource> source, TAccumulate seed, Func<TAccumulate, TSource, TAccumulate> func)
{
    State<(TAccumulate, IEnumerable<TSource>), Func<TAccumulate, TSource, TAccumulate>> query =
        AggregateState(func); // Define query.
    return query((seed, source)).State.Item1; // Execute query, with initial state (seed, source).
}

In each recursion step, if the source sequence in the current state in not empty, the source sequence needs to be split. The first value is used to call the accumulation function, and the other values are put into output state, which is passed to the next recursion step. So there are multiple pulling operations for the source sequence: detecting if it is empty detection, pulling first value, and pulling the rest values. To avoid multiple iterations for the same source sequence, here the Share query method from Microsoft Ix (Interactive Extensions) library is called, so that all the pulling operations share the same iterator.

The stack’s Pop and Push operation can be also viewed as state processing. The Pop method of stack requires no input, and out put the stack’s top value T, So Pop can be viewed of type Unit –> T. In contrast, stack’s Push method accepts a value, set the value to the top of the stack, and returns no output, so Push can be viewed of type T –> Unit. The stack’s values are different before and after the Pop and Push operations, so the stack itself can be viewed as the state of the Pop and Push operation. If the values in a stack is represented as a IEnumerable<T> sequence, then Pop can be remodeled as Tuple<Unit, IEnumerable<T>> –> Tuple<Unit, IEnumerable<T>>, which can be curried to Unit –> State<IEnumerable<T>, T>; and Push can be remodeled as Tuple<T, IEnumerable<T>> –> Tuple<Unit, IEnumerable<T>>:

// PopState: Unit -> (IEnumerable<T> -> (T, IEnumerable<T>))
// PopState: Unit -> State<IEnumerable<T>, T>
internal static State<IEnumerable<T>, T> PopState<T>(Unit unit = null) =>
    oldStack =>
    {
        IEnumerable<T> newStack = oldStack.Share();
        return (newStack.First(), newStack); // Output new state.
    };

// PushState: T -> (IEnumerable<T> -> (Unit, IEnumerable<T>))
// PushState: T -> State<IEnumerable<T>, Unit>
internal static State<IEnumerable<T>, Unit> PushState<T>(T value) =>
    oldStack =>
    {
        IEnumerable<T> newStack = oldStack.Concat(value.Enumerable());
        return (default, newStack); // Output new state.
    };

Now the stack operations can be a state monad workflow. Also, GetState can get the current values of the stack, and SetState can reset the values of stack:

internal static void Stack()
{
    IEnumerable<int> initialStack = Enumerable.Repeat(0, 5);
    State<IEnumerable<int>, IEnumerable<int>> query =
        from value1 in PopState<int>() // State<IEnumerable<int>, int>.
        from unit1 in PushState(1) // State<IEnumerable<int>, Unit>.
        from unit2 in PushState(2) // State<IEnumerable<int>, Unit>.
        from stack in GetState<IEnumerable<int>>() // State<IEnumerable<int>, IEnumerable<int>>.
        from unit3 in SetState(Enumerable.Range(0, 5)) // State<IEnumerable<int>, Unit>.
        from value2 in PopState<int>() // State<IEnumerable<int>, int>.
        from value3 in PopState<int>() // State<IEnumerable<int>, int>.
        from unit4 in PushState(5) // State<IEnumerable<int>, Unit>.
        select stack; // Define query.
    (IEnumerable<int> Value, IEnumerable<int> State) result = query(initialStack); // Execute query with initial state.
    result.Value.WriteLines(); // 0 0 0 0 1 2
    result.State.WriteLines(); // 0 1 2 5
}

Exception monad

As previously demonstrated, the Optional<> monad can handle the case that any operation of the workflow may not produce a valid result, in a . When an operation succeeds to return a valid result, the next operation executes. If all operations succeed, the entire workflow has a valid result. Option<> monad’s handling is based on operation’s return result. What if the operation fails with exception? To work with operation exceptions in a purely functional paradigm, the following Try<> structure can be defined, which is just Optional<> plus exception handling and store:

public readonly struct Try<T>
{
    private readonly Lazy<(T, Exception)> factory;

    public Try(Func<(T, Exception)> factory) =>
        this.factory = new Lazy<(T, Exception)>(() =>
        {
            try
            {
                return factory();
            }
            catch (Exception exception)
            {
                return (default, exception);
            }
        });

    public T Value
    {
        get
        {
            if (this.HasException)
            {
                throw new InvalidOperationException($"{nameof(Try<T>)} object must have a value.");
            }
            return this.factory.Value.Item1;
        }
    }

    public Exception Exception => this.factory.Value.Item2;

    public bool HasException => this.Exception != null;

    public static implicit operator Try<T>(T value) => new Try<T>(() => (value, (Exception)null));
}

Try<T> represents an operation, which either succeeds with a result, or fail with an exception. Its SelectMany method is also in the same pattern as Optional<>’s SelectMany, so that when an operation (source) succeeds without exception, the next operation (returned by selector) executes:

public static partial class TryExtensions
{
    // SelectMany: (Try<TSource>, TSource -> Try<TSelector>, (TSource, TSelector) -> TResult) -> Try<TResult>
    public static Try<TResult> SelectMany<TSource, TSelector, TResult>(
        this Try<TSource> source,
        Func<TSource, Try<TSelector>> selector,
        Func<TSource, TSelector, TResult> resultSelector) =>
            new Try<TResult>(() =>
            {
                if (source.HasException)
                {
                    return (default, source.Exception);
                }
                Try<TSelector> result = selector(source.Value);
                if (result.HasException)
                {
                    return (default, result.Exception);
                }
                return (resultSelector(source.Value, result.Value), (Exception)null);
            });

    // Wrap: TSource -> Try<TSource>
    public static Try<TSource> Try<TSource>(this TSource value) => value;

    // Select: (Try<TSource>, TSource -> TResult) -> Try<TResult>
    public static Try<TResult> Select<TSource, TResult>(
        this Try<TSource> source, Func<TSource, TResult> selector) =>
            source.SelectMany(value => selector(value).Try(), (value, result) => result);
}

The operation of throwing an exception can be represented with a Try<T> with the specified exception:

public static Try<T> Throw<T>(this Exception exception) => new Try<T>(() => (default, exception));

For convenience, Try<T> instance can be implicitly wrapped from a T value. And the following method also helps wrap a Func<T> operation:

public static Try<T> Try<T>(Func<T> function) =>
    new Try<T>(() => (function(), (Exception)null));

Similar to IO<> monad, an function operation (() –> void) without return result can be viewed as a function returning Unit (() –> Unit):

public static Try<Unit> Try(Action action) =>
    new Try<Unit>(() =>
    {
        action();
        return (default, (Exception)null);
    });

To handle the exception from an operation represented by Try<T>, just check the HasException property, filter the exception, and process it. The following Catch method handles the specified exception type:

public static Try<T> Catch<T, TException>(
    this Try<T> source, Func<TException, Try<T>> handler, Func<TException, bool> when = null)
    where TException : Exception => 
        new Try<T>(() =>
        {
            if (source.HasException && source.Exception is TException exception && exception != null
                && (when == null || when(exception)))
            {
                source = handler(exception);
            }
            return source.HasException ? (default, source.Exception) : (source.Value, (Exception)null);
        });

The evaluation of the Try<T> source, and the execution of handler, are both deferred. And the following Catch overload handles all exception types:

public static Try<T> Catch<T>(
    this Try<T> source, Func<Exception, Try<T>> handler, Func<Exception, bool> when = null) =>
        Catch<T, Exception>(source, handler, when);

And the Finally method just call a function to process the Try<T>:

public static TResult Finally<T, TResult>(
    this Try<T> source, Func<Try<T>, TResult> finally) => finally(source);

public static void Finally<T>(
    this Try<T> source, Action<Try<T>> finally) => finally(source);

The operation of throwing an exception can be represented with a Try<T> instance wrapping the specified exception:

public static partial class TryExtensions
{
    public static Try<T> Throw<T>(this Exception exception) => new Try<T>(() => (default, exception));
}

The following is an example of throwing exception:

internal static Try<int> TryStrictFactorial(int? value)
{
    if (value == null)
    {
        return Throw<int>(new ArgumentNullException(nameof(value)));
    }
    if (value <= 0)
    {
        return Throw<int>(new ArgumentOutOfRangeException(nameof(value), value, "Argument should be positive."));
    }

    if (value == 1)
    {
        return 1;
    }
    return value.Value * TryStrictFactorial(value - 1).Value;
}

And the the following is an example of handling exception:

internal static string Factorial(string value)
{
    Func<string, int?> stringToNullableInt32 = @string =>
        string.IsNullOrEmpty(@string) ? default : Convert.ToInt32(@string);
    Try<int> query = from nullableInt32 in Try(() => stringToNullableInt32(value)) // Try<int32?>
                        from result in TryStrictFactorial(nullableInt32) // Try<int>.
                        from unit in Try(() => result.WriteLine()) // Try<Unit>.
                        select result; // Define query.
    return query
        .Catch(exception => // Catch all and rethrow.
        {
            exception.WriteLine();
            return Throw<int>(exception);
        })
        .Catch<int, ArgumentNullException>(exception => 1) // When argument is null, factorial is 1.
        .Catch<int, ArgumentOutOfRangeException>(
            when: exception => object.Equals(exception.ActualValue, 0),
            handler: exception => 1) // When argument is 0, factorial is 1.
        .Finally(result => result.HasException // Execute query.
            ? result.Exception.Message : result.Value.ToString());
}

Reader monad

The Func<T,> functor is also monad. In contrast to Func<> monad, a factory function that only outputs a value, Func<T,> can also read input value from the environment. So Fun<T,> monad is also called reader monad, or environment monad. To be intuitive, rename Func<T,> to Reader<TEnvironment,>:

// Reader: TEnvironment -> T
public delegate T Reader<in TEnvironment, out T>(TEnvironment environment);

And its (SelectMany, Wrap, Select) methods are straightforward:

public static partial class ReaderExtensions
{
    // SelectMany: (Reader<TEnvironment, TSource>, TSource -> Reader<TEnvironment, TSelector>, (TSource, TSelector) -> TResult) -> Reader<TEnvironment, TResult>
    public static Reader<TEnvironment, TResult> SelectMany<TEnvironment, TSource, TSelector, TResult>(
        this Reader<TEnvironment, TSource> source,
        Func<TSource, Reader<TEnvironment, TSelector>> selector,
        Func<TSource, TSelector, TResult> resultSelector) =>
            environment =>
            {
                TSource value = source(environment);
                return resultSelector(value, selector(value)(environment));
            };

    // Wrap: TSource -> Reader<TEnvironment, TSource>
    public static Reader<TEnvironment, TSource> Reader<TEnvironment, TSource>(this TSource value) => 
        environment => value;

    // Select: (Reader<TEnvironment, TSource>, TSource -> TResult) -> Reader<TEnvironment, TResult>
    public static Reader<TEnvironment, TResult> Select<TEnvironment, TSource, TResult>(
        this Reader<TEnvironment, TSource> source, Func<TSource, TResult> selector) =>
            source.SelectMany(value => selector(value).Reader<TEnvironment, TResult>(), (value, result) => result);
}

There are scenarios of accessing input value from shared environment, like reading the configurations, dependency injection, etc. In the following example, the operations are dependents of the configurations, so these operations can be modeled using Reader<ICongiguration,> monad:

private static Reader<IConfiguration, FileInfo> DownloadHtml(Uri uri) =>
    configuration => default;

private static Reader<IConfiguration, FileInfo> ConverToWord(FileInfo htmlDocument, FileInfo template) =>
    configuration => default;

private static Reader<IConfiguration, Unit> UploadToOneDrive(FileInfo file) =>
    configuration => default;

internal static void Workflow(IConfiguration configuration, Uri uri, FileInfo template)
{
    Reader<IConfiguration, (FileInfo, FileInfo)> query =
        from htmlDocument in DownloadHtml(uri) // Reader<IConfiguration, FileInfo>.
        from wordDocument in ConverToWord(htmlDocument, template) // Reader<IConfiguration, FileInfo>.
        from unit in UploadToOneDrive(wordDocument) // Reader<IConfiguration, Unit>.
        select (htmlDocument, wordDocument); // Define query.
    (FileInfo, FileInfo) result = query(configuration); // Execute query.
}

The workflow is also a Reader<ICongiguration, T> function. To execute the workflow, it must read the required configuration input. Then all operation in the workflow execute sequentially by reading the same configuration input.

Writer monad

Writer is a function that returns a computed value along with a stream of additional content, so this function is of type () –> Tuple<T, TContent>. In the writer monad workflow, each operation’s additional output content is merged with the next operation’s additional output content, so that when the entire workflow is executed, all operations’ additional output content are merged as the workflow’s final additional output content. Each merge operation accepts 2 TContent instances, and result another TContent instance. It is a binary operation and can be implemented by monoid’s multiplication: TContent ⊙ TContent –> TContent. So writer can be represented by a () –> Tuple<T, TContent> function along with a IMonoid<TContent> monoid:

public abstract class WriterBase<TContent, T, TContentMonoid> : IMonoid<TContent> where TContentMonoid : IMonoid<TContent>
{
    private readonly Lazy<(TContent, T)> lazy;

    protected WriterBase(Func<(TContent, T)> writer)
    {
        this.lazy = new Lazy<(TContent, T)>(writer);
    }

    public TContent Content => this.lazy.Value.Item1;

    public T Value => this.lazy.Value.Item2;

    public static TContent Multiply(TContent value1, TContent value2) => TContentMonoid.Multiply(value1, value2);

    public static TContent Unit => TContentMonoid.Unit;
}

The most common scenario of outputting additional content, is tracing and logging, where the TContent is a sequence of log entries. A sequence of log entries can be represented as IEnumerable<T>, so the fore mentioned (IEnumerable<T>, Enumerable.Concat<T>, Enumerable.Empty<T>()) monoid can be used:

public class Writer<TEntry, T> : WriterBase<IEnumerable<TEntry>, T, EnumerableConcatMonoid<TEntry>>
{
    public Writer(Func<(IEnumerable<TEntry>, T)> writer) : base(writer) { }

    public Writer(T value) : base(() => (Unit, value)) { }
}

Similar to State<TState,> and Reader<TEnvironment,>, here Writer<TEntry,> can be monad with the following (SelectMany, Wrap, Select) methods:

public static partial class WriterExtensions
{
    // SelectMany: (Writer<TEntry, TSource>, TSource -> Writer<TEntry, TSelector>, (TSource, TSelector) -> TResult) -> Writer<TEntry, TResult>
    public static Writer<TEntry, TResult> SelectMany<TEntry, TSource, TSelector, TResult>(
        this Writer<TEntry, TSource> source,
        Func<TSource, Writer<TEntry, TSelector>> selector,
        Func<TSource, TSelector, TResult> resultSelector) =>
            new Writer<TEntry, TResult>(() =>
            {
                Writer<TEntry, TSelector> result = selector(source.Value);
                return (Tutorial.CategoryTheory.Writer<TEntry, TSource>.Multiply(source.Content, result.Content),
                    resultSelector(source.Value, result.Value));
            });

    // Wrap: TSource -> Writer<TEntry, TSource>
    public static Writer<TEntry, TSource> Writer<TEntry, TSource>(this TSource value) =>
        new Writer<TEntry, TSource>(value);

    // Select: (Writer<TEnvironment, TSource>, TSource -> TResult) -> Writer<TEnvironment, TResult>
    public static Writer<TEntry, TResult> Select<TEntry, TSource, TResult>(
        this Writer<TEntry, TSource> source, Func<TSource, TResult> selector) =>
            source.SelectMany(value => selector(value).Writer<TEntry, TResult>(), (value, result) => result);
}

Most commonly, each operation in the workflow logs string message. So the following method is defined to construct a writer instance from a value and a string log factory:

public static Writer<string, TSource> LogWriter<TSource>(this TSource value, Func<TSource, string> logFactory) =>
    new Writer<string, TSource>(() => (logFactory(value).Enumerable(), value));

The previous Fun<> monad workflow now can output logs for each operation:

internal static void Workflow()
{
    Writer<string, string> query = from filePath in Console.ReadLine().LogWriter(value =>
                                        $"File path: {value}") // Writer<string, string>.
                                   from encodingName in Console.ReadLine().LogWriter(value =>
                                        $"Encoding name: {value}") // Writer<string, string>.
                                   from encoding in Encoding.GetEncoding(encodingName).LogWriter(value =>
                                        $"Encoding: {value}") // Writer<string, Encoding>.
                                   from fileContent in File.ReadAllText(filePath, encoding).LogWriter(value =>
                                        $"File content length: {value.Length}") // Writer<string, string>.
                                   select fileContent; // Define query.
    string result = query.Value; // Execute query.
    query.Content.WriteLines();
    // File path: D:\File.txt
    // Encoding name: utf-8
    // Encoding: System.Text.UTF8Encoding
    // File content length: 76138
}

Continuation monad

In program, a function can return the result value, so that some other continuation function can use that value; or a function can take a continuation function as parameter, after it computes the result value, it calls back the continuation function with that value:

public static partial class CpsExtensions
{
    // Sqrt: int -> double
    internal static double Sqrt(int int32) => Math.Sqrt(int32);

    // SqrtWithCallback: (int, double -> TContinuation) -> TContinuation
    internal static TContinuation SqrtWithCallback<TContinuation>(
        int int32, Func<double, TContinuation> continuation) =>
            continuation(Math.Sqrt(int32));
}

The former is style is called direct style, and the latter is called continuation-passing style (CPS). Generally, for a TSource –> TResult function, its CPS version can accept a TResult –> TContinuation continuation function, so the CPS function is of type (TSource, TResult –> TContinuation) –> TContinuation. Again, just like the state monad, the CPS function can be curried to TSource –> ((TResult –> TContinuation) –> TContinuation)

// SqrtWithCallback: int -> (double -> TContinuation) -> TContinuation
internal static Func<Func<double, TContinuation>, TContinuation> SqrtWithCallback<TContinuation>(int int32) =>
    continuation => continuation(Math.Sqrt(int32));

Now the returned (TResult –> TContinuation) –> TContinuation function type can be given an alias Cps:

// Cps: (T -> TContinuation>) -> TContinuation
public delegate TContinuation Cps<TContinuation, out T>(Func<T, TContinuation> continuation);

So that the above function can be renamed as:

// SqrtCps: int -> Cps<TContinuation, double>
internal static Cps<TContinuation, double> SqrtCps<TContinuation>(int int32) =>
    continuation => continuation(Math.Sqrt(int32));

The CPS function becomes TSource –> Cps<TContinuation, TResult>, which is a monadic selector function. Just like State<TState,>, here Cps<TContinuation,> is the continuation monad. Its (SelectMany, Wrap, Select) methods can be implemented as:

public static partial class CpsExtensions
{
    // SelectMany: (Cps<TContinuation, TSource>, TSource -> Cps<TContinuation, TSelector>, (TSource, TSelector) -> TResult) -> Cps<TContinuation, TResult>
    public static Cps<TContinuation, TResult> SelectMany<TContinuation, TSource, TSelector, TResult>(
        this Cps<TContinuation, TSource> source,
        Func<TSource, Cps<TContinuation, TSelector>> selector,
        Func<TSource, TSelector, TResult> resultSelector) =>
            continuation => source(value =>
                selector(value)(result =>
                    continuation(resultSelector(value, result))));

    // Wrap: TSource -> Cps<TContinuation, TSource>
    public static Cps<TContinuation, TSource> Cps<TContinuation, TSource>(this TSource value) =>
        continuation => continuation(value);

    // Select: (Cps<TContinuation, TSource>, TSource -> TResult) -> Cps<TContinuation, TResult>
    public static Cps<TContinuation, TResult> Select<TContinuation, TSource, TResult>(
        this Cps<TContinuation, TSource> source, Func<TSource, TResult> selector) =>
            source.SelectMany(value => selector(value).Cps<TContinuation, TResult>(), (value, result) => result);
            // Equivalent to:
            // continuation => source(value => continuation(selector(value)));
            // Or:
            // continuation => source(continuation.o(selector));
}

A more complex example is sum of squares. The CPS version of sum and square are straightforward. If direct style of square operation of type int –> int, and the direct style of sum operation is (int, int) –> int, then their CPS versions are just of type int –> Cps<TContinuation, int>, and (int, int) –> Cps<TContinuation, int>:

// SquareCps: int -> Cps<TContinuation, int>
internal static Cps<TContinuation, int> SquareCps<TContinuation>(int x) =>
    continuation => continuation(x * x);

// SumCps: (int, int) -> Cps<TContinuation, int>
internal static Cps<TContinuation, int> SumCps<TContinuation>(int x, int y) =>
    continuation => continuation(x + y);

Then CPS version of sum of square can be implemented with them:

// SumOfSquaresCps: (int, int) -> Cps<TContinuation, int>
internal static Cps<TContinuation, int> SumOfSquaresCps<TContinuation>(int a, int b) =>
    continuation =>
        SquareCps<TContinuation>(a)(squareOfA =>
        SquareCps<TContinuation>(b)(squareOfB =>
        SumCps<TContinuation>(squareOfA, squareOfB)(continuation)));

This is not intuitive. But the continuation monad can help. A Cps<TContinuation, T> function can be viewed as a monad wrapper of T value. So T value can be unwrapped from Cps<TContinuation, T> with the LINQ from clause:

internal static Cps<TContinuation, int> SumOfSquaresCpsLinq<TContinuation>(int a, int b) =>
    from squareOfA in SquareCps<TContinuation>(a) // Cps<TContinuation, int>.
    from squareOfB in SquareCps<TContinuation>(b) // Cps<TContinuation, int>.
    from sum in SumCps<TContinuation>(squareOfA, squareOfB) // Cps<TContinuation, int>.
    select sum;

And the following is a similar example of fibonacci:

internal static Cps<TContinuation, uint> FibonacciCps<TContinuation>(uint uInt32) =>
    uInt32 > 1
        ? (from a in FibonacciCps<TContinuation>(uInt32 - 1U)
            from b in FibonacciCps<TContinuation>(uInt32 - 2U)
            select a + b)
        : uInt32.Cps<TContinuation, uint>();
    // Equivalent to:
    // continuation => uInt32 > 1U
    //    ? continuation(FibonacciCps<int>(uInt32 - 1U)(Id) + FibonacciCps<int>(uInt32 - 2U)(Id))
    //    : continuation(uInt32);

Generally, a direct style function can be easily converted to CPS function – just pass the direct style function’s return value to a continuation function:

public static Cps<TContinuation, T> Cps<TContinuation, T>(Func<T> function) =>
    continuation => continuation(function());

Now the previous workflows can be represented in CPS too:

internal static void Workflow<TContinuation>(Func<string, TContinuation> continuation)
{
    Cps<TContinuation, string> query =
        from filePath in Cps<TContinuation, string>(Console.ReadLine) // Cps<TContinuation, string>.
        from encodingName in Cps<TContinuation, string>(Console.ReadLine) // Cps<TContinuation, string>.
        from encoding in Cps<TContinuation, Encoding>(() => Encoding.GetEncoding(encodingName)) // Cps<TContinuation, Encoding>.
        from fileContent in Cps<TContinuation, string>(() => File.ReadAllText(filePath, encoding)) // Cps<TContinuation, string>.
        select fileContent; // Define query.
    TContinuation result = query(continuation); // Execute query.
}

In the workflow, each operation’s continuation function is its next operation. When the workflow executes, each operation computes its return value, then calls back its next operation with its return value. When the last operation executes, it calls back the workflow’s continuation function.

Category Theory via C# (7) Monad and LINQ to Monads

Thu, 26 Dec 2024 13:13:00 GMT

[FP & LINQ via C# series]

[Category Theory via C# series]

Monad

As fore mentioned endofunctor category can be monoidal (the entire category. Actually, an endofunctor In the endofunctor category can be monoidal too. This kind of endofunctor is called monad. Monad is another important algebraic structure in category theory and LINQ. Formally, monad is an endofunctor equipped with 2 natural transformations:

Monoid multiplication ◎ or μ, which a natural transformation ◎: F(F) ⇒ F, which means, for each object X, ◎ maps F(F(X)) to F(X). For convenience, this mapping operation is also denoted F ◎ F ⇒ F.
Monoid unit η, which is a natural transformation η: I ⇒ F. Here I is the identity functor, which maps each object X to X itself. For each X, there is η maps I(X) to F(X). Since I(X) is just X, η can also be viewed as mapping: X → F(X).

So monad F is a monoid (F, ◎, η) in the category of endofunctors. Apparently it must preserve the monoid laws:

Associativity preservation α: (F ◎ F) ◎ F ≡ F ◎ (F ◎ F)
Left unit preservation λ: η ◎ F ≡ F, and right unit preservation ρ: F ≡ F ◎ η

So that, the following diagram commutes:

In DotNet category, monad can be defined as:

// Cannot be compiled.
public partial interface IMonad<TMonad<>> : IFunctor<TMonad<>> where TMonad<> : IMonad<TMonad<>>
{
    // From IFunctor<TMonad<>>:
    // Select: (TSource -> TResult) -> (TMonad<TSource> -> TMonad<TResult>)
    // Func<TMonad<TSource>, TMonad<TResult>> Select<TSource, TResult>(Func<TSource, TResult> selector);

    // Multiply: TMonad<TMonad<TSource>> -> TMonad<TSource>
    TMonad<TSource> Multiply<TSource>(TMonad<TMonad<TSource>> sourceWrapper);
        
    // Unit: TSource -> TMonad<TSource>
    TMonad<TSource> Unit<TSource>(TSource value);
}

LINQ to Monads and monad laws

Built-in IEnumerable<> monad

The previously discussed IEnumerable<> functor is a built-in monad, it is straightforward to implement its (Multiply, Unit) method pair:

public static partial class EnumerableExtensions // IEnumerable<T> : IMonad<IEnumerable<>>
{
    // Multiply: IEnumerable<IEnumerable<TSource>> -> IEnumerable<TSource>
    public static IEnumerable<TSource> Multiply<TSource>(this IEnumerable<IEnumerable<TSource>> sourceWrapper)
    {
        foreach (IEnumerable<TSource> source in sourceWrapper)
        {
            foreach (TSource value in source)
            {
                yield return value;
            }
        }
    }

    // Unit: TSource -> IEnumerable<TSource>
    public static IEnumerable<TSource> Unit<TSource>(TSource value)
    {
        yield return value;
    }
}

The monoid unit η is exactly the same as the Wrap method for monoidal functor. It is easy to verify the above implementation preserves the monoid laws:

internal static void MonoidLaws()
{
    IEnumerable<int> source = new int[] { 0, 1, 2, 3, 4 };

    // Associativity preservation: source.Wrap().Multiply().Wrap().Multiply() == source.Wrap().Wrap().Multiply().Multiply().
    source.Enumerable().Multiply().Enumerable().Multiply().WriteLines();
    // 0 1 2 3 4
    source.Enumerable().Enumerable().Multiply().Multiply().WriteLines();
    // 0 1 2 3 4
    // Left unit preservation: Unit(source).Multiply() == f.
    Unit(source).Multiply().WriteLines(); // 0 1 2 3 4
    // Right unit preservation: source == source.Select(Unit).Multiply().
    source.Select(Unit).Multiply().WriteLines(); // 0 1 2 3 4
}

As discussed in LINQ to Object chapter, for IEnumerable<>, there is already a query method SelectMany providing the same ability to flatten hierarchy an IEnumerable<IEnumerable<T>> sequence to an IEnumerable<T> sequence. Actually, monad can be alternatively defined with SelectMany and η/Wrap:

public partial interface IMonad<TMonad> where TMonad<> : IMonad<TMonad<>>
{
    // SelectMany: (TMonad<TSource>, TSource -> TMonad<TSelector>, (TSource, TSelector) -> TResult) -> TMonad<TResult>
    TMonad<TResult> SelectMany<TSource, TSelector, TResult>(
        TMonad<TSource> source,
        Func<TSource, TMonad<TSelector>> selector,
        Func<TSource, TSelector, TResult> resultSelector);

    // Wrap: TSource -> IEnumerable<TSource>
    TMonad<TSource> Wrap<TSource>(TSource value);
}

And the alternative implementation is very similar:

public static partial class EnumerableExtensions // IEnumerable<T> : IMonad<IEnumerable<>>
{
    // SelectMany: (IEnumerable<TSource>, TSource -> IEnumerable<TSelector>, (TSource, TSelector) -> TResult) -> IEnumerable<TResult>
    public static IEnumerable<TResult> SelectMany<TSource, TSelector, TResult>(
        this IEnumerable<TSource> source,
        Func<TSource, IEnumerable<TSelector>> selector,
        Func<TSource, TSelector, TResult> resultSelector)
    {
        foreach (TSource value in source)
        {
            foreach (TSelector result in selector(value))
            {
                yield return resultSelector(value, result);
            }
        }
    }

    // Wrap: TSource -> IEnumerable<TSource>
    public static IEnumerable<TSource> Enumerable<TSource>(this TSource value)
    {
        yield return value;
    }
}

The above 2 versions of monad definition are equivalent. First, the (SelectMany, Wrap) methods can be implemented with the (Select, Multiply, Unit) methods:

public static partial class EnumerableExtensions // (Select, Multiply, Unit) implements (SelectMany, Wrap).
{
    // SelectMany: (IEnumerable<TSource>, TSource -> IEnumerable<TSelector>, (TSource, TSelector) -> TResult) -> IEnumerable<TResult>
    public static IEnumerable<TResult> SelectMany<TSource, TSelector, TResult>(
        this IEnumerable<TSource> source,
        Func<TSource, IEnumerable<TSelector>> selector,
        Func<TSource, TSelector, TResult> resultSelector) =>
            (from value in source
             select (from result in selector(value)
                     select resultSelector(value, result))).Multiply();
            // Compiled to:
            // source.Select(value => selector(value).Select(result => resultSelector(value, result))).Multiply();

    // Wrap: TSource -> IEnumerable<TSource>
    public static IEnumerable<TSource> Enumerable<TSource>(this TSource value) => Unit(value);
}

And the (Select, Multiply, Unit) methods can be implemented with (SelectMany, Wrap) methods too:

public static partial class EnumerableExtensions // (SelectMany, Wrap) implements (Select, Multiply, Unit).
{
    // Select: (TSource -> TResult) -> (IEnumerable<TSource> -> IEnumerable<TResult>).
    public static Func<IEnumerable<TSource>, IEnumerable<TResult>> Select<TSource, TResult>(
        Func<TSource, TResult> selector) => source =>
            from value in source
            from result in value.Enumerable()
            select result;
            // source.SelectMany(Enumerable, (result, value) => value);

    // Multiply: IEnumerable<IEnumerable<TSource>> -> IEnumerable<TSource>
    public static IEnumerable<TSource> Multiply<TSource>(this IEnumerable<IEnumerable<TSource>> sourceWrapper) =>
        from source in sourceWrapper
        from value in source
        select value;
        // sourceWrapper.SelectMany(source => source, (source, value) => value);

    // Unit: TSource -> IEnumerable<TSource>
    public static IEnumerable<TSource> Unit<TSource>(TSource value) => value.Enumerable();
}

So monad support is built-in in the C# language. As discussed in the LINQ query expression pattern part, SelectMany enables multiple from clauses, which can chain operations together to build a workflow, for example:

internal static void Workflow<T1, T2, T3, T4>(
    Func<IEnumerable<T1>> source1,
    Func<IEnumerable<T2>> source2,
    Func<IEnumerable<T3>> source3,
    Func<T1, T2, T3, IEnumerable<T4>> source4)
{
    IEnumerable<T4> query = from value1 in source1()
                            from value2 in source2()
                            from value3 in source3()
                            from value4 in source4(value1, value2, value3)
                            select value4; // Define query.
    query.WriteLines(); // Execute query.
}

Here N + 1 from clauses are compiled to N SelectMany fluent calls:

internal static void CompiledWorkflow<T1, T2, T3, T4>(
    Func<IEnumerable<T1>> source1,
    Func<IEnumerable<T2>> source2,
    Func<IEnumerable<T3>> source3,
    Func<T1, T2, T3, IEnumerable<T4>> source4)
{
    IEnumerable<T4> query = source1()
        .SelectMany(value1 => source2(), (value1, value2) => new { Value1 = value1, Value2 = value2 })
        .SelectMany(result2 => source3(), (result2, value3) => new { Result2 = result2, Value3 = value3 })
        .SelectMany(
            result3 => source4(result3.Result2.Value1, result3.Result2.Value2, result3.Value3),
            (result3, value4) => value4); // Define query.
    query.WriteLines(); // Execute query.
}

In LINQ, if monad’s SelectMany implements deferred execution, then monad enables imperative programming paradigm (a sequence of commands) in a purely functional way. In above LINQ query definition, the calls to the commands are not executed. When trying to pull results from the LINQ query, the workflow stars, and the commands executes sequentially.

Monad law and Kleisli composition

Regarding monad (F, ◎, η) can be redefined as (F, SelectMany, Wrap), the monoid laws now can be expressed by SelectMany and Wrap too, which are called monad laws:

Associativity law: SelectMany is the associative operator, since it is equivalent to Multiply.
Left unit law and right unit law: Wrap is the unit η, since it is identical to Unit.

internal static void MonadLaws()
{
    IEnumerable<int> source = new int[] { 0, 1, 2, 3, 4 };
    Func<int, IEnumerable<char>> selector = int32 => new string('*', int32);
    Func<int, IEnumerable<double>> selector1 = int32 => new double[] { int32 / 2D, Math.Sqrt(int32) };
    Func<double, IEnumerable<string>> selector2 =
        @double => new string[] { @double.ToString("0.0"), @double.ToString("0.00") };
    const int Value = 5;

    // Associativity: source.SelectMany(selector1).SelectMany(selector2) == source.SelectMany(value => selector1(value).SelectMany(selector2)).
    (from value in source
     from result1 in selector1(value)
     from result2 in selector2(result1)
     select result2).WriteLines();
    // 0.0 0.00 0.0 0.00
    // 0.5 0.50 1.0 1.00
    // 1.0 1.00 1.4 1.41
    // 1.5 1.50 1.7 1.73
    // 2.0 2.00 2.0 2.00
    (from value in source
     from result in (from result1 in selector1(value)
                     from result2 in selector2(result1)
                     select result2)
     select result).WriteLines();
    // 0.0 0.00 0.0 0.00
    // 0.5 0.50 1.0 1.00
    // 1.0 1.00 1.4 1.41
    // 1.5 1.50 1.7 1.73
    // 2.0 2.00 2.0 2.00
    // Left unit: value.Wrap().SelectMany(selector) == selector(value).
    (from value in Value.Enumerable()
     from result in selector(value)
     select result).WriteLines(); // * * * * *
    selector(Value).WriteLines(); // * * * * *
    // Right unit: source == source.SelectMany(Wrap).
    (from value in source
     from result in value.Enumerable()
     select result).WriteLines(); // 0 1 2 3 4
}

However, the monad laws are not intuitive. The Kleisli composition ∘ can help. For 2 monadic selector functions that can be passed to SelectMany,are also called Kleisli functions like s₁: TSource –> TMonad<TMiddle> and s₂: TMiddle –> TMonad<TResult>, their Kleisli composition is still a monadic selector (s₂ ∘ s₁): TSource –> TMonad<TResult>:

public static Func<TSource, IEnumerable<TResult>> o<TSource, TMiddle, TResult>( // After.
    this Func<TMiddle, IEnumerable<TResult>> selector2,
    Func<TSource, IEnumerable<TMiddle>> selector1) =>
        value => selector1(value).SelectMany(selector2, (result1, result2) => result2);
        // Equivalent to:
        // value => selector1(value).Select(selector2).Multiply();

Or generally:

// Cannot be compiled.
public static class FuncExtensions
{
    public static Func<TSource, TMonad<TResult>> o<TMonad<>, TSource, TMiddle, TResult>( // After.
        this Func<TMiddle, TMonad<TResult>> selector2,
        Func<TSource, TMonad<TMiddle>> selector1) where TMonad<> : IMonad<TMonad<>> =>
            value => selector1(value).SelectMany(selector2, (result1, result2) => result2);
            // Equivalent to:
            // value => selector1(value).Select(selector2).Multiply();
}

Now above monad laws can be expressed by monadic selectors and Kleisli composition:

Associativity law: the Kleisli composition of monadic selectors is now the monoid multiplication, it is associative. For monadic selectors s₁, s₂, s₃, there is (s₃ ∘ s₂) ∘ s₁ = s₃ ∘ (s₂ ∘ s₁).
Left unit law and right unit law: Wrap is still the monoid unit η, it is of type TSource –> TMonad<TSource>, so it can also be viewed as a monadic selector too. For monadic selector s, there is η ∘ s = s and s = s ∘ η.

internal static void KleisliComposition()
{
    Func<bool, IEnumerable<int>> selector1 =
        boolean => boolean ? new int[] { 0, 1, 2, 3, 4 } : new int[] { 5, 6, 7, 8, 9 };
    Func<int, IEnumerable<double>> selector2 = int32 => new double[] { int32 / 2D, Math.Sqrt(int32) };
    Func<double, IEnumerable<string>> selector3 =
        @double => new string[] { @double.ToString("0.0"), @double.ToString("0.00") };

    // Associativity: selector3.o(selector2).o(selector1) == selector3.o(selector2.o(selector1)).
    selector3.o(selector2).o(selector1)(true).WriteLines();
    // 0.0 0.00 0.0 0.00
    // 0.5 0.50 1.0 1.00
    // 1.0 1.00 1.4 1.41
    // 1.5 1.50 1.7 1.73
    // 2.0 2.00 2.0 2.00
    selector3.o(selector2.o(selector1))(true).WriteLines();
    // 0.0 0.00 0.0 0.00
    // 0.5 0.50 1.0 1.00
    // 1.0 1.00 1.4 1.41
    // 1.5 1.50 1.7 1.73
    // 2.0 2.00 2.0 2.00
    // Left unit: Unit.o(selector) == selector.
    Func<int, IEnumerable<int>> leftUnit = Enumerable;
    leftUnit.o(selector1)(true).WriteLines(); // 0 1 2 3 4
    selector1(true).WriteLines(); // 0 1 2 3 4
    // Right unit: selector == selector.o(Unit).
    selector1(false).WriteLines(); // 5 6 7 8 9
    Func<bool, IEnumerable<bool>> rightUnit = Enumerable;
    selector1.o(rightUnit)(false).WriteLines(); // 5 6 7 8 9
}

Kleisli category

With monad and Kleisli composition, a new kind of category called Kleisli category can be defined. Given a monad (F, ◎, η) in category C, there is a Kleisli category of F, denoted C_F:

Its objects ob(C_F) are ob(C), all objects in C.
Its morphisms hom(C_F) are Kleisli morphisms. A Kleisli morphisms m from object X to object Y is m: X → F(Y). In DotNet, the Kleisli morphisms are above monadic selector functions.
The composition of Kleisli morphisms is the above Kleisli composition.
The identity Kleisli morphism is η of the monad, so that η_X: X → F(X).

As already demonstrated, Kleisli composition and η satisfy the category associativity law and identity law.

Monad pattern of LINQ

So LINQ SelectMany query’s quintessential mathematics is monad. Generally, in DotNet category, a type is a monad if:

This type is an open generic type definition, which can be viewed as type constructor of kind * –> *, so that it maps a concrete type to another concrete monad-wrapped type.
It is equipped with the standard LINQ query method SelectMany, which can be either instance method or extension method.
The implementation of SelectMany satisfies the monad laws, so that the monad’s monoid structure is preserved.

As Brian Beckman said in this Channel 9 video:

LINQ is monad. It is very carefully designed by Erik Meijer so that it is monad.

Eric Lippert also mentioned:

The LINQ syntax is designed specifically to make operations on the sequence monad feel natural, but in fact the implementation is more general; what C# calls "SelectMany" is a slightly modified form of the "Bind" operation on an arbitrary monad.

On the other hand, to enable the monad LINQ query expression (multiple from clauses with select clause) for a type does not require that type to be strictly a monad. This LINQ workflow syntax can be enabled for any generic or non generic type as long as it has such a SelectMany method, which can be virtually demonstrated as:

// Cannot be compiled.
internal static void Workflow<TMonad<>, T1, T2, T3, T4, TResult>( // Non generic TMonad can work too.
    Func<TMonad<T1>> operation1,
    Func<TMonad<T2>> operation2,
    Func<TMonad<T3>> operation3,
    Func<TMonad<T4>> operation4,
    Func<T1, T2, T3, T4, TResult> resultSelector) where TMonad<> : IMonad<TMonad<>>
{
    TMonad<TResult> query = from /* T1 */ value1 in /* TMonad<T1> */ operation1()
                            from /* T2 */ value2 in /* TMonad<T1> */ operation2()
                            from /* T3 */ value3 in /* TMonad<T1> */ operation3()
                            from /* T4 */ value4 in /* TMonad<T1> */ operation4()
                            select /* TResult */ resultSelector(value1, value2, value3, value4); // Define query.
}

Monad vs. monoidal/applicative functor

Monad is monoidal functor and applicative functor. Monads’ (SelectMany, Wrap) methods implement monoidal functor’s Multiply and Unit methods, and applicative functor’s (Apply, Wrap) methods. This can be virtually demonstrated as:

// Cannot be compiled.
public static partial class MonadExtensions // (SelectMany, Wrap) implements (Multiply, Unit).
{
    // Multiply: (TMonad<T1>, TMonad<T2>) => TMonad<(T1, T2)>
    public static TMonad<(T1, T2)> Multiply<TMonad<>, T1, T2>(
        this TMonad<T1> source1, TMonad<T2> source2) where TMonad<> : IMonad<TMonad<>> =>
            from value1 in source1
            from value2 in source2
            select (value1, value2);
            // source1.SelectMany(value1 => source2 (value1, value2) => value1.ValueTuple(value2));

    // Unit: Unit -> TMonad<Unit>
    public static TMonad<Unit> Unit<TMonad<>>(
        Unit unit = default) where TMonad<> : IMonad<TMonad<>> => unit.Wrap();
}

// Cannot be compiled.
public static partial class MonadExtensions // (SelectMany, Wrap) implements (Apply, Wrap).
{
    // Apply: (TMonad<TSource -> TResult>, TMonad<TSource>) -> TMonad<TResult>
    public static TMonad<TResult> Apply<TMonad<>, TSource, TResult>(
        this TMonad<Func<TSource, TResult>> selectorWrapper, 
        TMonad<TSource> source) where TMonad<> : IMonad<TMonad<>> =>
            from selector in selectorWrapper
            from value in source
            select selector(value);
            // selectorWrapper.SelectMany(selector => source, (selector, value) => selector(value));

    // Monad's Wrap is identical to applicative functor's Wrap.
}

If monad is defined with the (Multiply, Unit) methods, they implement monoidal functor’s Multiply and Unit methods, and applicative functor’s (Apply, Wrap) methods too:

// Cannot be compiled.
public static class MonadExtensions // Monad (Multiply, Unit) implements monoidal functor (Multiply, Unit).
{
    // Multiply: (TMonad<T1>, TMonad<T2>) => TMonad<(T1, T2)>
    public static TMonad<(T1, T2)> Multiply<TMonad<>, T1, T2>(
        this TMonad<T1> source1, TMonad<T2> source2) where TMonad<> : IMonad<TMonad<>> =>
            (from value1 in source1
             select (from value2 in source2
                     select (value1, value2))).Multiply();
            // source1.Select(value1 => source2.Select(value2 => (value1, value2))).Multiply();

    // Unit: Unit -> TMonad<Unit>
    public static TMonad<Unit> Unit<TMonad>(Unit unit = default) where TMonad<>: IMonad<TMonad<>> => 
        TMonad<Unit>.Unit<Unit>(unit);
}

// Cannot be compiled.
public static partial class MonadExtensions // Monad (Multiply, Unit) implements applicative functor (Apply, Wrap).
{
    // Apply: (TMonad<TSource -> TResult>, TMonad<TSource>) -> TMonad<TResult>
    public static TMonad<TResult> Apply<TMonad<>, TSource, TResult>(
        this TMonad<Func<TSource, TResult>> selectorWrapper, 
        TMonad<TSource> source)  where TMonad<> : IMonad<TMonad<>> =>
            (from selector in selectorWrapper
             select (from value in source
                     select selector(value))).Multiply();
            // selectorWrapper.Select(selector => source.Select(value => selector(value))).Multiply();

    // Wrap: TSource -> TMonad<TSource>
    public static TMonad<TSource> Wrap<TMonad<>, TSource>(
        this TSource value) where TMonad<>: IMonad<TMonad<>> => TMonad<TSource>.Unit<TSource>(value);
}

So the monad definition can be updated to implement monoidal functor and applicative functor too:

// Cannot be compiled.
public partial interface IMonad<TMonad<>> : IMonoidalFunctor<TMonad<>>, IApplicativeFunctor<TMonad<>>
{
}

More LINQ to Monads

Many other open generic type definitions provided by .NET can be monad. Take Lazy<> functor as example, first, apparently it is a type constructor of kind * –> *. Then, its SelectMany query method can be defined as extension method:

public static partial class LazyExtensions // Lazy<T> : IMonad<Lazy<>>
{
    // Multiply: Lazy<Lazy<TSource> -> Lazy<TSource>
    public static Lazy<TSource> Multiply<TSource>(this Lazy<Lazy<TSource>> sourceWrapper) =>
        sourceWrapper.SelectMany(Id, False);

    // Unit: TSource -> Lazy<TSource>
    public static Lazy<TSource> Unit<TSource>(TSource value) => Lazy(value);

    // SelectMany: (Lazy<TSource>, TSource -> Lazy<TSelector>, (TSource, TSelector) -> TResult) -> Lazy<TResult>
    public static Lazy<TResult> SelectMany<TSource, TSelector, TResult>(
        this Lazy<TSource> source,
        Func<TSource, Lazy<TSelector>> selector,
        Func<TSource, TSelector, TResult> resultSelector) => 
            new Lazy<TResult>(() => resultSelector(source.Value, selector(source.Value).Value));
}

Its Wrap method has been implemented previously, as a requirement of applicative functor. The following is an example of chaining operations into a workflow with Lazy<> monad:

internal static void Workflow()
{
    Lazy<string> query = from filePath in new Lazy<string>(Console.ReadLine)
                         from encodingName in new Lazy<string>(Console.ReadLine)
                         from encoding in new Lazy<Encoding>(() => Encoding.GetEncoding(encodingName))
                         from fileContent in new Lazy<string>(() => File.ReadAllText(filePath, encoding))
                         select fileContent; // Define query.
    string result = query.Value; // Execute query.
}

Since SelectMany implements deferred execution, the above LINQ query is pure and the workflow is deferred. When the query is executed by calling Lazy<>.Value, the workflow is started.

Func<> functor is also monad, with the following SelectMany:

public static partial class FuncExtensions // Func<T> : IMonad<Func<>>
{
    // Multiply: Func<Func<T> -> Func<T>
    public static Func<TSource> Multiply<TSource>(this Func<Func<TSource>> sourceWrapper) => 
        sourceWrapper.SelectMany(source => source, (source, value) => value);

    // Unit: Unit -> Func<Unit>
    public static Func<TSource> Unit<TSource>(TSource value) => Func(value);

    // SelectMany: (Func<TSource>, TSource -> Func<TSelector>, (TSource, TSelector) -> TResult) -> Func<TResult>
    public static Func<TResult> SelectMany<TSource, TSelector, TResult>(
        this Func<TSource> source,
        Func<TSource, Func<TSelector>> selector,
        Func<TSource, TSelector, TResult> resultSelector) => () =>
        {
            TSource value = source();
            return resultSelector(value, selector(value)());
        };
}

And the workflow is similar to Lazy<> monad’s workflow, because Lazy<T> is just a wrapper of Func<T> factory function:

internal static void Workflow()
{
    Func<string> query = from filePath in new Func<string>(Console.ReadLine)
                         from encodingName in new Func<string>(Console.ReadLine)
                         from encoding in new Func<Encoding>(() => Encoding.GetEncoding(encodingName))
                         from fileContent in new Func<string>(() => File.ReadAllText(filePath, encoding))
                         select fileContent; // Define query.
    string result = query(); // Execute query.
}

The Optional<> monad is monad too, with the following SelectMany:

public static partial class OptionalExtensions // Optional<T> : IMonad<Optional<>>
{
    // Multiply: Optional<Optional<TSource> -> Optional<TSource>
    public static Optional<TSource> Multiply<TSource>(this Optional<Optional<TSource>> sourceWrapper) =>
        sourceWrapper.SelectMany(source => source, (source, value) => value);

    // Unit: TSource -> Optional<TSource>
    public static Optional<TSource> Unit<TSource>(TSource value) => Optional(value);

    // SelectMany: (Optional<TSource>, TSource -> Optional<TSelector>, (TSource, TSelector) -> TResult) -> Optional<TResult>
    public static Optional<TResult> SelectMany<TSource, TSelector, TResult>(
        this Optional<TSource> source,
        Func<TSource, Optional<TSelector>> selector,
        Func<TSource, TSelector, TResult> resultSelector) => new Optional<TResult>(() =>
            {
                if (source.HasValue)
                {
                    Optional<TSelector> result = selector(source.Value);
                    if (result.HasValue)
                    {
                        return (true, resultSelector(source.Value, result.Value));
                    }
                }
                return (false, default);
            });
}

The LINQ workflow of Optional<> monad is also pure and deferred, where each operation in the chaining is an Optional<T> instance:

internal static void Workflow()
{
    string input;
    Optional<string> query =
        from filePath in new Optional<string>(() => string.IsNullOrWhiteSpace(input = Console.ReadLine())
            ? (false, default) : (true, input))
        from encodingName in new Optional<string>(() => string.IsNullOrWhiteSpace(input = Console.ReadLine())
            ? (false, default) : (true, input))
        from encoding in new Optional<Encoding>(() =>
            {
                try
                {
                    return (true, Encoding.GetEncoding(encodingName));
                }
                catch (ArgumentException)
                {
                    return (false, default);
                }
            })
        from fileContent in new Optional<string>(() => File.Exists(filePath)
            ? (true, File.ReadAllText(filePath, encoding)) : (false, default))
        select fileContent; // Define query.
    if (query.HasValue) // Execute query.
    {
        string result = query.Value;
    }
}

So Optional<> covers the scenario that each operation of the workflow may not have invalid result. When an operation has valid result (Optional<T>.HasValue returns true), its next operation executes. And when all all the operations have valid result, the entire workflow has a valid query result.

The ValueTuple<> functor is also monad. Again, its SelectMany cannot defer the call of selector, just like its Select:

public static partial class ValueTupleExtensions // ValueTuple<T, TResult> : IMonad<ValueTuple<T,>>
{
    // Multiply: ValueTuple<T, ValueTuple<T, TSource> -> ValueTuple<T, TSource>
    public static (T, TSource) Multiply<T, TSource>(this (T, (T, TSource)) sourceWrapper) =>
        sourceWrapper.SelectMany(source => source, (source, value) => value); // Immediate execution.

    // Unit: TSource -> ValueTuple<T, TSource>
    public static (T, TSource) Unit<T, TSource>(TSource value) => ValueTuple<T, TSource>(value);

    // SelectMany: (ValueTuple<T, TSource>, TSource -> ValueTuple<T, TSelector>, (TSource, TSelector) -> TResult) -> ValueTuple<T, TResult>
    public static (T, TResult) SelectMany<T, TSource, TSelector, TResult>(
        this (T, TSource) source,
        Func<TSource, (T, TSelector)> selector,
        Func<TSource, TSelector, TResult> resultSelector) =>
            (source.Item1, resultSelector(source.Item2, selector(source.Item2).Item2)); // Immediate execution.
}

So its workflow is the immediate execution version of Lazy<> monad’s workflow:

public static partial class ValueTupleExtensions
{
    internal static void Workflow()
    {
        ValueTuple<string> query = from filePath in new ValueTuple<string>(Console.ReadLine())
                                   from encodingName in new ValueTuple<string>(Console.ReadLine())
                                   from encoding in new ValueTuple<Encoding>(Encoding.GetEncoding(encodingName))
                                   from fileContent in new ValueTuple<string>(File.ReadAllText(filePath, encoding))
                                   select fileContent; // Define and execute query.
        string result = query.Item1; // Query result.
    }
}

The Task<> functor is monad too. Once again, its SelectMany is immediate and impure, just like its Select:

public static partial class TaskExtensions // Task<T> : IMonad<Task<>>
{
    // Multiply: Task<Task<T> -> Task<T>
    public static Task<TResult> Multiply<TResult>(this Task<Task<TResult>> sourceWrapper) =>
        sourceWrapper.SelectMany(source => source, (source, value) => value); // Immediate execution, impure.

    // Unit: TSource -> Task<TSource>
    public static Task<TSource> Unit<TSource>(TSource value) => Task(value);

    // SelectMany: (Task<TSource>, TSource -> Task<TSelector>, (TSource, TSelector) -> TResult) -> Task<TResult>
    public static async Task<TResult> SelectMany<TSource, TSelector, TResult>(
        this Task<TSource> source,
        Func<TSource, Task<TSelector>> selector,
        Func<TSource, TSelector, TResult> resultSelector) =>
            resultSelector(await source, await selector(await source)); // Immediate execution, impure.
}

So the following LINQ workflow with Task<> monad is also immediate and impure:

internal static async Task WorkflowAsync(string uri)
{
    Task<string> query = from response in new HttpClient().GetAsync(uri) // Return Task<HttpResponseMessage>.
                         from stream in response.Content.ReadAsStreamAsync() // Return Task<Stream>.
                         from text in new StreamReader(stream).ReadToEndAsync() // Return Task<string>.
                         select text; // Define and execute query.
    string result = await query; // Query result.
}

It is easy to verify all the above SelectMany methods satisfy the monad laws, and all the above (Multiply, Unit) methods preserve the monoid laws. However, not any SelectMany or (Multiply, Unit) methods can automatically satisfy those laws. Take the ValueTuple<T,> functor as example, here are its SelectMany and (Multiply, Unit):

public static partial class ValueTupleExtensions // ValueTuple<T, TResult> : IMonad<ValueTuple<T,>>
{
    // Multiply: ValueTuple<T, ValueTuple<T, TSource> -> ValueTuple<T, TSource>
    public static (T, TSource) Multiply<T, TSource>(this (T, (T, TSource)) sourceWrapper) =>
        sourceWrapper.SelectMany(source => source, (source, value) => value); // Immediate execution.

    // Unit: TSource -> ValueTuple<T, TSource>
    public static (T, TSource) Unit<T, TSource>(TSource value) => ValueTuple<T, TSource>(value);

    // SelectMany: (ValueTuple<T, TSource>, TSource -> ValueTuple<T, TSelector>, (TSource, TSelector) -> TResult) -> ValueTuple<T, TResult>
    public static (T, TResult) SelectMany<T, TSource, TSelector, TResult>(
        this (T, TSource) source,
        Func<TSource, (T, TSelector)> selector,
        Func<TSource, TSelector, TResult> resultSelector) =>
            (source.Item1, resultSelector(source.Item2, selector(source.Item2).Item2)); // Immediate execution.
}

The above (Multiply, Unit) implementations cannot preserve the monoid left unit law:

internal static void MonoidLaws()
{
    (string, int) source = ("a", 1);

    // Associativity preservation: source.Wrap().Multiply().Wrap().Multiply() == source.Wrap().Wrap().Multiply().Multiply().
    source
        .ValueTuple<string, (string, int)>()
        .Multiply()
        .ValueTuple<string, (string, int)>()
        .Multiply()
        .WriteLine(); // (, 1)
    source
        .ValueTuple<string, (string, int)>()
        .ValueTuple<string, (string, (string, int))>()
        .Multiply()
        .Multiply()
        .WriteLine(); // (, 1)
    // Left unit preservation: Unit(f).Multiply() == source.
    Unit<string, (string, int)>(source).Multiply().WriteLine(); // (, 1)
    // Right unit preservation: source == source.Select(Unit).Multiply().
    source.Select(Unit<string, int>).Multiply().WriteLine(); // (a, 1)
}

And the above SelectMany implementation breaks the left unit monad law too:

internal static void MonadLaws()
{
    ValueTuple<string, int> source = ("a", 1);
    Func<int, ValueTuple<string, char>> selector = int32 => ("b", '@');
    Func<int, ValueTuple<string, double>> selector1 = int32 => ("c", Math.Sqrt(int32));
    Func<double, ValueTuple<string, string>> selector2 = @double => ("d", @double.ToString("0.00"));
    const int Value = 5;

    // Associativity: source.SelectMany(selector1).SelectMany(selector2) == source.SelectMany(value => selector1(value).SelectMany(selector2)).
    (from value in source
        from result1 in selector1(value)
        from result2 in selector2(result1)
        select result2).WriteLine(); // (a, 1.00)
    (from value in source
        from result in (from result1 in selector1(value) from result2 in selector2(result1) select result2)
        select result).WriteLine(); // (a, 1.00)
    // Left unit: value.Wrap().SelectMany(selector) == selector(value).
    (from value in Value.ValueTuple<string, int>()
        from result in selector(value)
        select result).WriteLine(); // (, @)
    selector(Value).WriteLine(); // (b, @)
    // Right unit: source == source.SelectMany(Wrap).
    (from value in source
        from result in value.ValueTuple<string, int>()
        select result).WriteLine(); // (a, 1)
}

Category Theory via C# (6) Monoidal Functor and Applicative Functor

Wed, 25 Dec 2024 13:12:00 GMT

[FP & LINQ via C# series]

[Category Theory via C# series]

Monoidal functor

Given monoidal categories (C, ⊗, I_C) and (D, ⊛, I_D), a strong lax monoidal functor is a functor F: C → D equipped with:

Monoid binary multiplication operation, which is a natural transformation φ: F(X) ⊛ F(Y) ⇒ F(X ⊗ Y)
Monoid unit, which is a morphism ι: I_D → F(I_C)

F preserves the monoid laws in D:

Associativity law is preserved with D’s associator α_D:
Left unit law is preserved with D’s left unitor λ_D:

and right unit law is preserved with D’s right unitor ρ_D:

In this tutorial, strong lax monoidal functor is called monoidal functor for short. In DotNet category, monoidal functors are monoidal endofunctors. In the definition, (C, ⊗, I_C) and (D, ⊛, I_D) are both (DotNet, ValueTuple<,>, Unit), so monoidal functor can be IEnumerable<T1>, IEnumerable<T2>defined as:

public interface IMonoidalFunctor<TMonoidalFunctor<>> : IFunctor<TMonoidalFunctor<>>
    where TMonoidalFunctor : IMonoidalFunctor<TMonoidalFunctor<>>
{
    // From IFunctor<TMonoidalFunctor<>>:
    // Select: (TSource -> TResult) -> (TMonoidalFunctor<TSource> -> TMonoidalFunctor<TResult>)
    // Func<TMonoidalFunctor<TSource>, TMonoidalFunctor<TResult>> Select<TSource, TResult>(Func<TSource, TResult> selector);

    // Multiply: TMonoidalFunctor<T1> x TMonoidalFunctor<T2> -> TMonoidalFunctor<T1 x T2>
    // Multiply: ValueTuple<TMonoidalFunctor<T1>, TMonoidalFunctor<T2>> -> TMonoidalFunctor<ValueTuple<T1, T2>>
    TMonoidalFunctor<ValueTuple<T1, T2>> Multiply<T1, T2>(
        ValueTuple<TMonoidalFunctor<T1>, TMonoidalFunctor<T2>> bifunctor);

    // Unit: Unit -> TMonoidalFunctor<Unit>
    TMonoidalFunctor<Unit> Unit(Unit unit);
}

Multiply accepts a ValueTuple<IEnumerable<T1>, IEnumerable<T2>> bifunctor, which is literally a 2-tuple (IEnumerable<T1>, IEnumerable<T2>). For convenience, the explicit ValueTuple<,> parameter can be represented by an implicit tuple, a pair of parameters. So the monoidal functor definition is equivalent to:

public interface IMonoidalFunctor<TMonoidalFunctor<>> : IFunctor<TMonoidalFunctor<>>
    where TMonoidalFunctor : IMonoidalFunctor<TMonoidalFunctor<>>
{
    // Multiply: TMonoidalFunctor<T1> x TMonoidalFunctor<T2> -> TMonoidalFunctor<T1 x T2>
    // Multiply: (TMonoidalFunctor<T1>, TMonoidalFunctor<T2>) -> TMonoidalFunctor<(T1, T2)>
    TMonoidalFunctor<(T1, T2)> Multiply<T1, T2>(
        TMonoidalFunctor<T1> source1, TMonoidalFunctor<T2>> source2); // Unit: Unit

    // Unit: Unit -> TMonoidalFunctor<Unit>
    TMonoidalFunctor<Unit> Unit(Unit unit);
}

IEnumerable<> monoidal functor

IEnumerable<> functor is a monoidal functor. Its Multiply method can be implemented as its extension method:

public static partial class EnumerableExtensions // IEnumerable<T> : IMonoidalFunctor<IEnumerable<>>
{
    // Multiply: IEnumerable<T1> x IEnumerable<T2> -> IEnumerable<T1 x T2>
    // Multiply: ValueTuple<IEnumerable<T1>, IEnumerable<T2>> -> IEnumerable<ValueTuple<T1, T2>>
    // Multiply: (IEnumerable<T1>, IEnumerable<T2>) -> IEnumerable<(T1, T2)>
    public static IEnumerable<(T1, T2)> Multiply<T1, T2>(
        this IEnumerable<T1> source1, IEnumerable<T2> source2) // Implicit tuple.
    {
        foreach (T1 value1 in source1)
        {
            foreach (T2 value2 in source2)
            {
                yield return (value1, value2);
            }
        }
    }

    // Unit: Unit -> IEnumerable<Unit>
    public static IEnumerable<Unit> Unit(Unit unit = default)
    {
        yield return unit;
    }
}

Now extension method Multiply can be used as a infix operator. It can be verified that the above Multiply and Unit implementations preserve the monoid laws by working with associator, left unitor and right unitor of DotNet monoidal category:

// using static Dixin.Linq.CategoryTheory.DotNetCategory;
internal static void MonoidalFunctorLaws()
{
    IEnumerable<Unit> unit = Unit();
    IEnumerable<int> source1 = new int[] { 0, 1 };
    IEnumerable<char> source2 = new char[] { '@', '#' };
    IEnumerable<bool> source3 = new bool[] { true, false };
    IEnumerable<int> source = new int[] { 0, 1, 2, 3, 4 };

    // Associativity preservation: source1.Multiply(source2).Multiply(source3).Select(Associator) == source1.Multiply(source2.Multiply(source3)).
    source1.Multiply(source2).Multiply(source3).Select(Associator).WriteLines();
        // (0, (@, True)) (0, (@, False)) (0, (#, True)) (0, (#, False))
        // (1, (@, True)) (1, (@, False)) (1, (#, True)) (1, (#, False))
    source1.Multiply(source2.Multiply(source3)).WriteLines();
        // (0, (@, True)) (0, (@, False)) (0, (#, True)) (0, (#, False))
        // (1, (@, True)) (1, (@, False)) (1, (#, True)) (1, (#, False))
    // Left unit preservation: unit.Multiply(source).Select(LeftUnitor) == source.
    unit.Multiply(source).Select(LeftUnitor).WriteLines(); // 0 1 2 3 4
    // Right unit preservation: source == source.Multiply(unit).Select(RightUnitor).
    source.Multiply(unit).Select(RightUnitor).WriteLines(); // 0 1 2 3 4
}

How could these methods be useful? Remember functor’s Select method enables selector working with value(s) wrapped by functor:

internal static void Selector1Arity(IEnumerable<int> xs)
{
    Func<int, bool> selector = x => x > 0;
    // Apply selector with xs.
    IEnumerable<bool> applyWithXs = xs.Select(selector);
}

So Select can be viewed as applying 1 arity selector (a TSource –> TResult function) with TFunctor<TSource>. For a N arity selector, to have it work with value(s) wrapped by functor, first curry it, so that it can be viewed as 1 arity function. In the following example, the (T1, T2, T3) –> TResult selector is curried to T1 –> (T2 –> T3 –> TResult) function, so that it can be viewed as only have 1 parameter, and can work with TFunctor<T1>:

internal static void SelectorNArity(IEnumerable<int> xs, IEnumerable<long> ys, IEnumerable<double> zs)
{
    Func<int, long, double, bool> selector = (x, y, z) => x + y + z > 0;

    // Curry selector.
    Func<int, Func<long, Func<double, bool>>> curriedSelector = 
        selector.Curry(); // 1 arity: x => (y => z => x + y + z > 0)
    // Partially apply selector with xs.
    IEnumerable<Func<long, Func<double, bool>>> applyWithXs = xs.Select(curriedSelector);

So partially applying the T1 –> (T2 –> T3 –> TResult) selector with TFunctor<T1> returns TFunctor<T2 –> T3 –> TResult>, where the T2 –> T3 –> TResult function is wrapped by the TFunctor<> functor. To further apply TFunctor<T2 –> T3 –> TResult> with TFunctor<T2>, Multiply can be called:

    // Partially apply selector with ys.
    IEnumerable<(Func<long, Func<double, bool>>, long)> multiplyWithYs = applyWithXs.Multiply(ys);
    IEnumerable<Func<double, bool>> applyWithYs = multiplyWithYs.Select(product =>
    {
        Func<long, Func<double, bool>> partialAppliedSelector = product.Item1;
        long y = product.Item2;
        return partialAppliedSelector(y);
    });

The result of Multiply is TFunctor<(T2 –> T3 –> TResult, T2)>, where each T2 –> T3 –> TResult function is paired with each T2 value, so that each function can be applied with each value, And TFunctor<(T2 –> T3 –> TResult, T2)> is mapped to TFunctor<(T3 –> TResult)>, which can be applied with TFunctor<T3> in the same way:

    // Partially apply selector with zs.
    IEnumerable<(Func<double, bool>, double)> multiplyWithZs = applyWithYs.Multiply(zs);
    IEnumerable<bool> applyWithZs = multiplyWithZs.Select(product =>
    {
        Func<double, bool> partialAppliedSelector = product.Item1;
        double z = product.Item2;
        return partialAppliedSelector(z);
    });
}

So Multiply enables applying functor-wrapped functions (TFunctor<T –> TResult>) with functor-wrapped values (TFunctor<TSource>), which returns functor-wrapped results (TFunctor<TResult>). Generally, the Multiply and Select calls can be encapsulated as the following Apply method:

// Apply: (IEnumerable<TSource -> TResult>, IEnumerable<TSource>) -> IEnumerable<TResult>
public static IEnumerable<TResult> Apply<TSource, TResult>(
    this IEnumerable<Func<TSource, TResult>> selectorWrapper, IEnumerable<TSource> source) =>
        selectorWrapper.Multiply(source).Select(product => product.Item1(product.Item2));

So that the above N arity selector application becomes:

internal static void Apply(IEnumerable<int> xs, IEnumerable<long> ys, IEnumerable<double> zs)
{
    Func<int, long, double, bool> selector = (x, y, z) => x + y + z > 0;
    // Partially apply selector with xs.
    IEnumerable<Func<long, Func<double, bool>>> applyWithXs = xs.Select(selector.Curry());
    // Partially apply selector with ys.
    IEnumerable<Func<double, bool>> applyWithYs = applyWithXs.Apply(ys);
    // Partially apply selector with zs.
    IEnumerable<bool> applyWithZs = applyWithYs.Apply(zs);
}

Applicative functor

A functor, with the above ability to apply functor-wrapped functions with functor-wrapped values, is also called applicative functor. The following is the definition of applicative functor:

// Cannot be compiled.
public interface IApplicativeFunctor<TApplicativeFunctor<>> : IFunctor<TApplicativeFunctor<>>
    where TApplicativeFunctor<> : IApplicativeFunctor<TApplicativeFunctor<>>
{
    // From: IFunctor<TApplicativeFunctor<>>:
    // Select: (TSource -> TResult) -> (TApplicativeFunctor<TSource> -> TApplicativeFunctor<TResult>)
    // Func<TApplicativeFunctor<TSource>, TApplicativeFunctor<TResult>> Select<TSource, TResult>(Func<TSource, TResult> selector);

    // Apply: (TApplicativeFunctor<TSource -> TResult>, TApplicativeFunctor<TSource> -> TApplicativeFunctor<TResult>
    TApplicativeFunctor<TResult> Apply<TSource, TResult>(
        TApplicativeFunctor<Func<TSource, TResult>> selectorWrapper, TApplicativeFunctor<TSource> source);

    // Wrap: TSource -> TApplicativeFunctor<TSource>
    TApplicativeFunctor<TSource> Wrap<TSource>(TSource value);
}

And applicative functor must satisfy the applicative laws:

Functor preservation: applying function is equivalent to applying functor-wrapped function
Identity preservation: applying functor-wrapped identity function, is equivalent to doing nothing.
Composition preservation: functor-wrapped functions can be composed by applying.
Homomorphism: applying functor-wrapped function with functor-wrapped value, is equivalent to functor-wrapping the result of applying that function with that value.
Interchange: when applying functor-wrapped functions with a functor-wrapped value, the functor-wrapped functions and the functor-wrapped value can interchange position.

IEnumerable<> applicative functor

IEnumerable<> functor is a applicative functor. Again, these methods are implemented as extension methods. And for IEnumerable<>, the Wrap method is called Enumerable to be intuitive:

public static partial class EnumerableExtensions // IEnumerable<T> : IApplicativeFunctor<IEnumerable<>>
{
    // Apply: (IEnumerable<TSource -> TResult>, IEnumerable<TSource>) -> IEnumerable<TResult>
    public static IEnumerable<TResult> Apply<TSource, TResult>(
        this IEnumerable<Func<TSource, TResult>> selectorWrapper, IEnumerable<TSource> source)
    {
        foreach (Func<TSource, TResult> selector in selectorWrapper)
        {
            foreach (TSource value in source)
            {
                yield return selector(value);
            }
        }
    }

    // Wrap: TSource -> IEnumerable<TSource>
    public static IEnumerable<TSource> Enumerable<TSource>(this TSource value)
    {
        yield return value;
    }
}

It can be verified that the above Apply and Wrap (Enumerable) implementations satisfy the applicative laws:

internal static void ApplicativeLaws()
{
    IEnumerable<int> source = new int[] { 0, 1, 2, 3, 4 };
    Func<int, double> selector = int32 => Math.Sqrt(int32);
    IEnumerable<Func<int, double>> selectorWrapper1 =
        new Func<int, double>[] { int32 => int32 / 2D, int32 => Math.Sqrt(int32) };
    IEnumerable<Func<double, string>> selectorWrapper2 =
        new Func<double, string>[] { @double => @double.ToString("0.0"), @double => @double.ToString("0.00") };
    Func<Func<double, string>, Func<Func<int, double>, Func<int, string>>> o =
        new Func<Func<double, string>, Func<int, double>, Func<int, string>>(Linq.FuncExtensions.o).Curry();
    int value = 5;

    // Functor preservation: source.Select(selector) == selector.Wrap().Apply(source).
    source.Select(selector).WriteLines(); // 0 1 1.4142135623731 1.73205080756888 2
    selector.Enumerable().Apply(source).WriteLines(); // 0 1 1.4142135623731 1.73205080756888 2
    // Identity preservation: Id.Wrap().Apply(source) == source.
    new Func<int, int>(Functions.Id).Enumerable().Apply(source).WriteLines(); // 0 1 2 3 4
    // Composition preservation: o.Wrap().Apply(selectorWrapper2).Apply(selectorWrapper1).Apply(source) == selectorWrapper2.Apply(selectorWrapper1.Apply(source)).
    o.Enumerable().Apply(selectorWrapper2).Apply(selectorWrapper1).Apply(source).WriteLines();
        // 0.0  0.5  1.0  1.5  2.0
        // 0.0  1.0  1.4  1.7  2.0 
        // 0.00 0.50 1.00 1.50 2.00
        // 0.00 1.00 1.41 1.73 2.00
    selectorWrapper2.Apply(selectorWrapper1.Apply(source)).WriteLines();
        // 0.0  0.5  1.0  1.5  2.0
        // 0.0  1.0  1.4  1.7  2.0 
        // 0.00 0.50 1.00 1.50 2.00
        // 0.00 1.00 1.41 1.73 2.00
    // Homomorphism: selector.Wrap().Apply(value.Wrap()) == selector(value).Wrap().
    selector.Enumerable().Apply(value.Enumerable()).WriteLines(); // 2.23606797749979
    selector(value).Enumerable().WriteLines(); // 2.23606797749979
    // Interchange: selectorWrapper.Apply(value.Wrap()) == (selector => selector(value)).Wrap().Apply(selectorWrapper).
    selectorWrapper1.Apply(value.Enumerable()).WriteLines(); // 2.5 2.23606797749979
    new Func<Func<int, double>, double>(function => function(value)).Enumerable().Apply(selectorWrapper1)
        .WriteLines(); // 2.5 2.23606797749979
}

Monoidal functor vs. applicative functor

The applicative functor definition is actually equivalent to above monoidal functor definition. First, applicative functor’s Apply and Wrap methods can be implemented by monoidal functor’s Multiply and Unit methods:

public static partial class EnumerableExtensions // IEnumerable<T> : IApplicativeFunctor<IEnumerable<>>
{
    // Apply: (IEnumerable<TSource -> TResult>, IEnumerable<TSource>) -> IEnumerable<TResult>
    public static IEnumerable<TResult> Apply<TSource, TResult>(
        this IEnumerable<Func<TSource, TResult>> selectorWrapper, IEnumerable<TSource> source) =>
            selectorWrapper.Multiply(source).Select(product => product.Item1(product.Item2));

    // Wrap: TSource -> IEnumerable<TSource>
    public static IEnumerable<TSource> Enumerable<TSource>(this TSource value) => Unit().Select(unit => value);
}

On the other hand, monoidal functor’s Multiply and Unit methods can be implemented by applicative functor’s Apply and Wrap methods:

public static partial class EnumerableExtensions // IEnumerable<T> : IMonoidalFunctor<IEnumerable<>>
{
    // Multiply: IEnumerable<T1> x IEnumerable<T2> -> IEnumerable<T1 x T2>
    // Multiply: (IEnumerable<T1>, IEnumerable<T2>) -> IEnumerable<(T1, T2)>
    public static IEnumerable<(T1, T2)> Multiply<T1, T2>(
        this IEnumerable<T1> source1, IEnumerable<T2> source2) =>
            new Func<T1, T2, (T1, T2)>(ValueTuple.Create).Curry().Enumerable().Apply(source1).Apply(source2);

    // Unit: Unit -> IEnumerable<Unit>
    public static IEnumerable<Unit> Unit(Unit unit = default) => unit.Enumerable();
}

Generally, for any applicative functor, its (Apply, Wrap) method pair can implement the (Multiply, Unit) method pair required as monoidal functor, and vice versa. This can be virtually demonstrated as:

// Cannot be compiled.
public static class MonoidalFunctorExtensions // (Multiply, Unit) implements (Apply, Wrap).
{
    // Apply: (TMonoidalFunctor<TSource -> TResult>, TMonoidalFunctor<TSource>) -> TMonoidalFunctor<TResult>
    public static TMonoidalFunctor<TResult> Apply<TMonoidalFunctor<>, TSource, TResult>(
        this TMonoidalFunctor<Func<TSource, TResult>> selectorWrapper, TMonoidalFunctor<TSource> source) 
        where TMonoidalFunctor<> : IMonoidalFunctor<TMonoidalFunctor<>> =>
            selectorWrapper.Multiply(source).Select(product => product.Item1(product.Item2));

    // Wrap: TSource -> TMonoidalFunctor<TSource>
    public static TMonoidalFunctor<TSource> Wrap<TMonoidalFunctor<>, TSource>(this TSource value) 
        where TMonoidalFunctor<> : IMonoidalFunctor<TMonoidalFunctor<>> =>TMonoidalFunctor<TSource>
            TMonoidalFunctor<TSource>.Unit().Select(unit => value);
}

// Cannot be compiled.
public static class ApplicativeFunctorExtensions // (Apply, Wrap) implements (Multiply, Unit).
{
    // Multiply: TApplicativeFunctor<T1> x TApplicativeFunctor<T2> -> TApplicativeFunctor<T1 x T2>
    // Multiply: (TApplicativeFunctor<T1>, TApplicativeFunctor<T2>) -> TApplicativeFunctor<(T1, T2)>
    public static TApplicativeFunctor<(T1, T2)> Multiply<TApplicativeFunctor<>, T1, T2>(
        this TApplicativeFunctor<T1> source1, TApplicativeFunctor<T2> source2) 
        where TApplicativeFunctor<> : IApplicativeFunctor<TApplicativeFunctor<>> =>
            new Func<T1, T2, (T1, T2)>(ValueTuple.Create).Curry().Wrap().Apply(source1).Apply(source2);

    // Unit: Unit -> TApplicativeFunctor<Unit>
    public static TApplicativeFunctor<Unit> Unit<TApplicativeFunctor<>>(Unit unit = default)
        where TApplicativeFunctor<> : IApplicativeFunctor<TApplicativeFunctor<>> => unit.Wrap();
}

More Monoidal functors and applicative functors

The Lazy<>, Func<>, Func<T,> functors are also monoidal/applicative functors:

public static partial class LazyExtensions // Lazy<T> : IMonoidalFunctor<Lazy<>>
{
    // Multiply: Lazy<T1> x Lazy<T2> -> Lazy<T1 x T2>
    // Multiply: (Lazy<T1>, Lazy<T2>) -> Lazy<(T1, T2)>
    public static Lazy<(T1, T2)> Multiply<T1, T2>(this Lazy<T1> source1, Lazy<T2> source2) =>
        new Lazy<(T1, T2)>(() => (source1.Value, source2.Value));

    // Unit: Unit -> Lazy<Unit>
    public static Lazy<Unit> Unit(Unit unit = default) => new Lazy<Unit>(() => unit);
}

public static partial class LazyExtensions // Lazy<T> : IApplicativeFunctor<Lazy<>>
{
    // Apply: (Lazy<TSource -> TResult>, Lazy<TSource>) -> Lazy<TResult>
    public static Lazy<TResult> Apply<TSource, TResult>(
        this Lazy<Func<TSource, TResult>> selectorWrapper, Lazy<TSource> source) =>
            selectorWrapper.Multiply(source).Select(product => product.Item1(product.Item2));

    // Wrap: TSource -> Lazy<TSource>
    public static Lazy<T> Lazy<T>(this T value) => Unit().Select(unit => value);
}

public static partial class FuncExtensions // Func<T> : IMonoidalFunctor<Func<>>
{
    // Multiply: Func<T1> x Func<T2> -> Func<T1 x T2>
    // Multiply: (Func<T1>, Func<T2>) -> Func<(T1, T2)>
    public static Func<(T1, T2)> Multiply<T1, T2>(this Func<T1> source1, Func<T2> source2) =>
        () => (source1(), source2());

    // Unit: Unit -> Func<Unit>
    public static Func<Unit> Unit(Unit unit = default) => () => unit;
}

public static partial class FuncExtensions // Func<T> : IApplicativeFunctor<Func<>>
{
    // Apply: (Func<TSource -> TResult>, Func<TSource>) -> Func<TResult>
    public static Func<TResult> Apply<TSource, TResult>(
        this Func<Func<TSource, TResult>> selectorWrapper, Func<TSource> source) =>
            selectorWrapper.Multiply(source).Select(product => product.Item1(product.Item2));

    // Wrap: TSource -> Func<TSource>
    public static Func<T> Func<T>(this T value) => Unit().Select(unit => value);
}

public static partial class FuncExtensions // Func<T, TResult> : IMonoidalFunctor<Func<T,>>
{
    // Multiply: Func<T, T1> x Func<T, T2> -> Func<T, T1 x T2>
    // Multiply: (Func<T, T1>, Func<T, T2>) -> Func<T, (T1, T2)>
    public static Func<T, (T1, T2)> Multiply<T, T1, T2>(this Func<T, T1> source1, Func<T, T2> source2) =>
        value => (source1(value), source2(value));

    // Unit: Unit -> Func<T, Unit>
    public static Func<T, Unit> Unit<T>(Unit unit = default) => _ => unit;
}

public static partial class FuncExtensions // Func<T, TResult> : IApplicativeFunctor<Func<T,>>
{
    // Apply: (Func<T, TSource -> TResult>, Func<T, TSource>) -> Func<T, TResult>
    public static Func<T, TResult> Apply<T, TSource, TResult>(
        this Func<T, Func<TSource, TResult>> selectorWrapper, Func<T, TSource> source) =>
            selectorWrapper.Multiply(source).Select(product => product.Item1(product.Item2));

    // Wrap: TSource -> Func<T, TSource>
    public static Func<T, TSource> Func<T, TSource>(this TSource value) => Unit<T>().Select(unit => value);
}

public static partial class OptionalExtensions // Optional<T> : IMonoidalFunctor<Optional<>>
{
    // Multiply: Optional<T1> x Optional<T2> -> Optional<T1 x T2>
    // Multiply: (Optional<T1>, Optional<T2>) -> Optional<(T1, T2)>
    public static Optional<(T1, T2)> Multiply<T1, T2>(this Optional<T1> source1, Optional<T2> source2) =>
        new Optional<(T1, T2)>(() => source1.HasValue && source2.HasValue
            ? (true, (source1.Value, source2.Value))
            : (false, (default, default)));

    // Unit: Unit -> Optional<Unit>
    public static Optional<Unit> Unit(Unit unit = default) =>
        new Optional<Unit>(() => (true, unit));
}

public static partial class OptionalExtensions // Optional<T> : IApplicativeFunctor<Optional<>>
{
    // Apply: (Optional<TSource -> TResult>, Optional<TSource>) -> Optional<TResult>
    public static Optional<TResult> Apply<TSource, TResult>(
        this Optional<Func<TSource, TResult>> selectorWrapper, Optional<TSource> source) =>
            selectorWrapper.Multiply(source).Select(product => product.Item1(product.Item2));

    // Wrap: TSource -> Optional<TSource>
    public static Optional<T> Optional<T>(this T value) => Unit().Select(unit => value);
}

The ValueTuple<> and Task<> functors are monoidal/applicative functors too. Notice their Multiply/Apply methods cannot defer the execution, and Task<>’s Multiply/Apply methods are impure.

public static partial class ValueTupleExtensions // ValueTuple<T> : IMonoidalFunctor<ValueTuple<>>
{
    // Multiply: ValueTuple<T1> x ValueTuple<T2> -> ValueTuple<T1 x T2>
    // Multiply: (ValueTuple<T1>, ValueTuple<T2>) -> ValueTuple<(T1, T2)>
    public static ValueTuple<(T1, T2)> Multiply<T1, T2>(this ValueTuple<T1> source1, ValueTuple<T2> source2) =>
        new ValueTuple<(T1, T2)>((source1.Item1, source2.Item1)); // Immediate execution.

    // Unit: Unit -> ValueTuple<Unit>
    public static ValueTuple<Unit> Unit(Unit unit = default) => new ValueTuple<Unit>(unit);
}

public static partial class ValueTupleExtensions // ValueTuple<T> : IApplicativeFunctor<ValueTuple<>>
{
    // Apply: (ValueTuple<TSource -> TResult>, ValueTuple<TSource>) -> ValueTuple<TResult>
    public static ValueTuple<TResult> Apply<TSource, TResult>(
        this ValueTuple<Func<TSource, TResult>> selectorWrapper, ValueTuple<TSource> source) =>
            selectorWrapper.Multiply(source).Select(product => product.Item1(product.Item2)); // Immediate execution.

    // Wrap: TSource -> ValueTuple<TSource>
    public static ValueTuple<T> ValueTuple<T>(this T value) => Unit().Select(unit => value);
}

public static partial class TaskExtensions // Task<T> : IMonoidalFunctor<Task<>>
{
    // Multiply: Task<T1> x Task<T2> -> Task<T1 x T2>
    // Multiply: (Task<T1>, Task<T2>) -> Task<(T1, T2)>
    public static async Task<(T1, T2)> Multiply<T1, T2>(this Task<T1> source1, Task<T2> source2) =>
        ((await source1), (await source2)); // Immediate execution, impure.

    // Unit: Unit -> Task<Unit>
    public static Task<Unit> Unit(Unit unit = default) => System.Threading.Tasks.Task.FromResult(unit);
}

public static partial class TaskExtensions // Task<T> : IApplicativeFunctor<Task<>>
{
    // Apply: (Task<TSource -> TResult>, Task<TSource>) -> Task<TResult>
    public static Task<TResult> Apply<TSource, TResult>(
        this Task<Func<TSource, TResult>> selectorWrapper, Task<TSource> source) =>
            selectorWrapper.Multiply(source).Select(product => product.Item1(product.Item2)); // Immediate execution, impure.

    // Wrap: TSource -> Task<TSource>
    public static Task<T> Task<T>(this T value) => Unit().Select(unit => value);
}

It is easy to verify all the above (Multiply, Unit) method pairs preserve the monoid laws, and all the above (Apply, Wrap) method pairs satisfy the applicative laws. However, not any (Multiply, Unit) or any (Apply, Wrap) can automatically satisfy the laws. Take the ValueTuple<T,> functor as example:

public static partial class ValueTupleExtensions // ValueTuple<T1, T2 : IMonoidalFunctor<ValueTuple<T,>>
{
    // Multiply: ValueTuple<T, T1> x ValueTuple<T, T2> -> ValueTuple<T, T1 x T2>
    // Multiply: (ValueTuple<T, T1>, ValueTuple<T, T2>) -> ValueTuple<T, (T1, T2)>
    public static (T, (T1, T2)) Multiply<T, T1, T2>(this (T, T1) source1, (T, T2) source2) =>
        (source1.Item1, (source1.Item2, source2.Item2)); // Immediate execution.

    // Unit: Unit -> ValueTuple<Unit>
    public static (T, Unit) Unit<T>(Unit unit = default) => (default, unit);
}

public static partial class ValueTupleExtensions // ValueTuple<T, TResult> : IApplicativeFunctor<ValueTuple<T,>>
{
    // Apply: (ValueTuple<T, TSource -> TResult>, ValueTuple<T, TSource>) -> ValueTuple<T, TResult>
    public static (T, TResult) Apply<T, TSource, TResult>(
        this (T, Func<TSource, TResult>) selectorWrapper, (T, TSource) source) =>
            selectorWrapper.Multiply(source).Select(product => product.Item1(product.Item2)); // Immediate execution.

    // Wrap: TSource -> ValueTuple<T, TSource>
    public static (T, TSource) ValueTuple<T, TSource>(this TSource value) => Unit<T>().Select(unit => value);
}

The above (Multiply, Unit) implementations cannot preserve the left unit law:

internal static void MonoidalFunctorLaws()
{
    (string, int) source = ("a", 1);
    (string, Unit) unit = Unit<string>();
    (string, int) source1 = ("b", 2);
    (string, char) source2 = ("c", '@');
    (string, bool) source3 = ("d", true);

    // Associativity preservation: source1.Multiply(source2).Multiply(source3).Select(Associator) == source1.Multiply(source2.Multiply(source3)).
    source1.Multiply(source2).Multiply(source3).Select(Associator).WriteLine(); // (b, (2, (@, True)))
    source1.Multiply(source2.Multiply(source3)).WriteLine(); // (b, (2, (@, True)))
    // Left unit preservation: unit.Multiply(source).Select(LeftUnitor) == source.
    unit.Multiply(source).Select(LeftUnitor).WriteLine(); // (, 1)
    // Right unit preservation: source == source.Multiply(unit).Select(RightUnitor).
    source.Multiply(unit).Select(RightUnitor).WriteLine(); // (a, 1)
}

And the above (Apply, Wrap) implementation breaks all applicative laws:

internal static void ApplicativeLaws()
{
    (string, int) source = ("a", 1);
    Func<int, double> selector = int32 => Math.Sqrt(int32);
    (string, Func<int, double>) selectorWrapper1 = 
        ("b", new Func<int, double>(int32 => Math.Sqrt(int32)));
    (string, Func<double, string>) selectorWrapper2 =
        ("c", new Func<double, string>(@double => @double.ToString("0.00")));
    Func<Func<double, string>, Func<Func<int, double>, Func<int, string>>> o = 
        new Func<Func<double, string>, Func<int, double>, Func<int, string>>(Linq.FuncExtensions.o).Curry();
    int value = 5;

    // Functor preservation: source.Select(selector) == selector.Wrap().Apply(source).
    source.Select(selector).WriteLine(); // (a, 1)
    selector.ValueTuple<string, Func<int, double>>().Apply(source).WriteLine(); // (, 1)
    // Identity preservation: Id.Wrap().Apply(source) == source.
    new Func<int, int>(Functions.Id).ValueTuple<string, Func<int, int>>().Apply(source).WriteLine(); // (, 1)
    // Composition preservation: o.Curry().Wrap().Apply(selectorWrapper2).Apply(selectorWrapper1).Apply(source) == selectorWrapper2.Apply(selectorWrapper1.Apply(source)).
    o.ValueTuple<string, Func<Func<double, string>, Func<Func<int, double>, Func<int, string>>>>()
        .Apply(selectorWrapper2).Apply(selectorWrapper1).Apply(source).WriteLine(); // (, 1.00)
    selectorWrapper2.Apply(selectorWrapper1.Apply(source)).WriteLine(); // (c, 1.00)
    // Homomorphism: selector.Wrap().Apply(value.Wrap()) == selector(value).Wrap().
    selector.ValueTuple<string, Func<int, double>>().Apply(value.ValueTuple<string, int>()).WriteLine(); // (, 2.23606797749979)
    selector(value).ValueTuple<string, double>().WriteLine(); // (, 2.23606797749979)
    // Interchange: selectorWrapper.Apply(value.Wrap()) == (selector => selector(value)).Wrap().Apply(selectorWrapper).
    selectorWrapper1.Apply(value.ValueTuple<string, int>()).WriteLine(); // (b, 2.23606797749979)
    new Func<Func<int, double>, double>(function => function(value))
        .ValueTuple<string, Func<Func<int, double>, double>>().Apply(selectorWrapper1).WriteLine(); // (, 2.23606797749979)
}

Category Theory via C# (5) Bifunctor

Sun, 15 Dec 2024 13:11:00 GMT

[FP & LINQ via C# series]

[Category Theory via C# series]

Bifunctor

A functor is the mapping from 1 object to another object, with a “Select” ability to map 1 morphism to another morphism. A bifunctor (binary functor), as the name implies, is the mapping from 2 objects and from 2 morphisms. Giving category C, D and E, bifunctor F from category C, D to E is a structure-preserving morphism from C, D to E, denoted F: C × D → E:

F maps objects X ∈ ob(C), Y ∈ ob(D) to object F(X, Y) ∈ ob(E)
F also maps morphisms m_C: X → X’ ∈ hom(C), m_D: Y → Y’ ∈ hom(D) to morphism m_E: F(X, Y) → F(X’, Y’) ∈ hom(E)

In DotNet category, bifunctors are binary endofunctors, and can be defined as:

// Cannot be compiled.
public interface IBifunctor<TBifunctor<,>> where TBifunctor<,> : IBifunctor<TBifunctor<,>>
{
    Func<TBifunctor<TSource1, TSource2>, TBifunctor<TResult1, TResult2>> Select<TSource1, TSource2, TResult1, TResult2>(
        Func<TSource1, TResult1> selector1, Func<TSource2, TResult2> selector2);
}

The most intuitive built-in bifunctor is ValueTuple<,>. Apparently ValueTuple<,> can be viewed as a type constructor of kind * –> * –> *, which accepts 2 concrete types to and return another concrete type. Its Select implementation is also straightforward:

public static partial class ValueTupleExtensions // ValueTuple<T1, T2> : IBifunctor<ValueTuple<,>>
{
    // Bifunctor Select: (TSource1 -> TResult1, TSource2 -> TResult2) -> (ValueTuple<TSource1, TSource2> -> ValueTuple<TResult1, TResult2>).
    public static Func<ValueTuple<TSource1, TSource2>, ValueTuple<TResult1, TResult2>> Select<TSource1, TSource2, TResult1, TResult2>(
        Func<TSource1, TResult1> selector1, Func<TSource2, TResult2> selector2) => source =>
            Select(source, selector1, selector2);

    // LINQ-like Select: (ValueTuple<TSource1, TSource2>, TSource1 -> TResult1, TSource2 -> TResult2) -> ValueTuple<TResult1, TResult2>).
    public static ValueTuple<TResult1, TResult2> Select<TSource1, TSource2, TResult1, TResult2>(
        this ValueTuple<TSource1, TSource2> source,
        Func<TSource1, TResult1> selector1,
        Func<TSource2, TResult2> selector2) =>
            (selector1(source.Item1), selector2(source.Item2));
}

However, similar to ValueTuple<> functor’s Select method, ValueTuple<,> bifunctor’s Select method has to call selector1 and selector2 immediately. To implement deferred execution, the following Lazy<,> bifunctor can be defined:

public class Lazy<T1, T2>
{
    private readonly Lazy<(T1, T2)> lazy;

    public Lazy(Func<(T1, T2)> factory) => this.lazy = new Lazy<(T1, T2)>(factory);

    public T1 Value1 => this.lazy.Value.Item1;

    public T2 Value2 => this.lazy.Value.Item2;

    public override string ToString() => this.lazy.Value.ToString();
}

Lazy<,> is simply the lazy version of ValueTuple<,>. Jut like Lazy<>, Lazy<,> can be constructed with a factory function, so that the call to selector1 and selector2 are deferred:

public static partial class LazyExtensions // Lazy<T1, T2> : IBifunctor<Lazy<,>>
{
    // Bifunctor Select: (TSource1 -> TResult1, TSource2 -> TResult2) -> (Lazy<TSource1, TSource2> -> Lazy<TResult1, TResult2>).
    public static Func<Lazy<TSource1, TSource2>, Lazy<TResult1, TResult2>> Select<TSource1, TSource2, TResult1, TResult2>(
        Func<TSource1, TResult1> selector1, Func<TSource2, TResult2> selector2) => source =>
            Select(source, selector1, selector2);

    // LINQ-like Select: (Lazy<TSource1, TSource2>, TSource1 -> TResult1, TSource2 -> TResult2) -> Lazy<TResult1, TResult2>).
    public static Lazy<TResult1, TResult2> Select<TSource1, TSource2, TResult1, TResult2>(
        this Lazy<TSource1, TSource2> source,
        Func<TSource1, TResult1> selector1,
        Func<TSource2, TResult2> selector2) =>
            new Lazy<TResult1, TResult2>(() => (selector1(source.Value1), selector2(source.Value2)));
}

Monoidal category

With the help of bifunctor, monoidal category can be defined. A monoidal category is a category C equipped with:

A bifunctor ⊗ as the monoid binary multiplication operation: bifunctor ⊗ maps 2 objects in C to another object in C, denoted C ⊗ C → C, which is also called the monoidal product or tensor product.
An unit object I ∈ ob(C) as the monoid unit, also called tensor unit

For (C, ⊗, I) to be a monoid, it also needs to be equipped with the following natural transformations, so that the monoid laws are satisfied:

Associator α_{X, Y, Z}: (X ⊗ Y) ⊗ Z ⇒ X ⊗ (Y ⊗ Z) for the associativity law, where X, Y, Z ∈ ob(C)
Left unitor λ_X: I ⊗ X ⇒ X for the left unit law, and right unitor ρ_X: X ⊗ I ⇒ X for the right unit law, where X ∈ ob(C)

The following monoid triangle identity and pentagon identity diagrams still commute for monoidal category:

Here for monoidal category, the above ⊙ (general multiplication operator) becomes ⊗ (bifunctor).

Monoidal category can be simply defined as:

public interface IMonoidalCategory<TObject, TMorphism> : ICategory<TObject, TMorphism>, IMonoid<TObject> { }

DotNet category is monoidal category, with the most intuitive bifunctor ValueTuple<,> as the monoid multiplication, and Unit type as the monoid unit:

public partial class DotNetCategory : IMonoidalCategory<Type, Delegate>
{
    public static Type Multiply(Type value1, Type value2) => typeof(ValueTuple<,>).MakeGenericType(value1, value2);

    public static Type Unit => typeof(Unit);
}

To have (DotNet, ValueTuple<,>, Unit) satisfy the monoid laws, the associator, left unitor and right unitor are easy to implement:

public partial class DotNetCategory
{
    // Associator: (T1 x T2) x T3 -> T1 x (T2 x T3)
    // Associator: ValueTuple<ValueTuple<T1, T2>, T3> -> ValueTuple<T1, ValueTuple<T2, T3>>
    public static (T1, (T2, T3)) Associator<T1, T2, T3>(((T1, T2), T3) product) =>
        (product.Item1.Item1, (product.Item1.Item2, product.Item2));

    // LeftUnitor: Unit x T -> T
    // LeftUnitor: ValueTuple<Unit, T> -> T
    public static T LeftUnitor<T>((Unit, T) product) => product.Item2;

    // RightUnitor: T x Unit -> T
    // RightUnitor: ValueTuple<T, Unit> -> T
    public static T RightUnitor<T>((T, Unit) product) => product.Item1;
}

Category Theory via C# (4) Natural Transformation

Sat, 14 Dec 2024 13:10:00 GMT

[FP & LINQ via C# series]

[Category Theory via C# series]

Natural transformation and naturality

If F: C → D and G: C → D are both functors from categories C to category D, the mapping from F to G is called natural transformation and denoted α: F ⇒ G. α: F ⇒ G is actually family of morphisms from F to G, For each object X in category C, there is a specific morphism α_X: F(X) → G(X) in category D, called the component of α at X. For each morphism m: X → Y in category C and 2 functors F: C → D, G: C → D, there is a naturality square in D:

In another word, for m: X → Y in category C, there must be α_Y ∘ F(m) ≡ G(m) ∘ α_X , or equivalently α_Y ∘ Select_F(m) ≡ Select_G(m) ∘ α_Xin category D.

In DotNet category, the following ToLazy<> generic method transforms Func<> functor to Lazy<> functor:

public static partial class NaturalTransformations
{
    // ToLazy: Func<> -> Lazy<>
    public static Lazy<T> ToLazy<T>(this Func<T> function) => new Lazy<T>(function);
}

Apparently, for above natural transformation: ToLazy<>: Func<> ⇒ Lazy<>:

for each specific object T, there is an object Func<T>, an object Lazy<T>, and a morphism ToFunc<T>: Func<T> → Lazy<T>.
For each specific morphism selector: TSource → TResult, there is a naturality square, which consists of 4 morphisms:

ToLazy<TResult>: Func<TResult> → Lazy<TResult>, which is the component of ToLazy<> at TResult
FuncExtensions.Select(selector): Func<TSource> → Func<TResult>
LazyExtensions.Select(selector): Lazy<TSource> → Lazy<TResult>
ToLazy<TSource>: Func<TSource> → Lazy<TSource>, which is the component of ToLazy<> at TSource

The following example is a simple naturality square that commutes for ToLazy<>:

internal static void Naturality()
{
    Func<int, string> selector = int32 => Math.Sqrt(int32).ToString("0.00");

    // Naturality square:
    // ToFunc<string>.o(LazyExtensions.Select(selector)) == FuncExtensions.Select(selector).o(ToFunc<int>)
    Func<Func<string>, Lazy<string>> funcStringToLazyString = ToLazy<string>;
    Func<Func<int>, Func<string>> funcInt32ToFuncString = FuncExtensions.Select(selector);
    Func<Func<int>, Lazy<string>> leftComposition = funcStringToLazyString.o(funcInt32ToFuncString);
    Func<Lazy<int>, Lazy<string>> lazyInt32ToLazyString = LazyExtensions.Select(selector);
    Func<Func<int>, Lazy<int>> funcInt32ToLazyInt32 = ToLazy<int>;
    Func<Func<int>, Lazy<string>> rightComposition = lazyInt32ToLazyString.o(funcInt32ToLazyInt32);

    Func<int> funcInt32 = () => 2;
    Lazy<string> lazyString = leftComposition(funcInt32);
    lazyString.Value.WriteLine(); // 1.41
    lazyString = rightComposition(funcInt32);
    lazyString.Value.WriteLine(); // 1.41
}

And the following are a few more examples of natural transformations:

// ToFunc: Lazy<T> -> Func<T>
public static Func<T> ToFunc<T>(this Lazy<T> lazy) => () => lazy.Value;

// ToEnumerable: Func<T> -> IEnumerable<T>
public static IEnumerable<T> ToEnumerable<T>(this Func<T> function)
{
    yield return function();
}

// ToEnumerable: Lazy<T> -> IEnumerable<T>
public static IEnumerable<T> ToEnumerable<T>(this Lazy<T> lazy)
{
    yield return lazy.Value;
}

Functor Category

Now there are functors, and mappings between functors, which are natural transformations. Naturally, they lead to category of functors. Given 2 categories C and D, there is a functor category, denoted D^C:

Its objects ob(D^C) are the functors from category C to D .
Its morphisms hom(D^C) are the natural transformations between those functors.
The composition of natural transformations α: F ⇒ G and β: G ⇒ H, is natural transformations (β ∘ α): F ⇒ H.
The identity natural transformation id_F: F ⇒ F maps each functor to itself

Regarding the category laws:

Associativity law: As fore mentioned, natural transformation’s components are morphisms in D, so natural transformation composition in D^C can be viewed as morphism composition in D: (β ∘ α)_X: F(X) → H(X) = (β_X: G(X) → H(X)) ∘ (α_X: F(X) → G(X)). Natural transformations’ composition in D^C is associative, since all component morphisms’ composition in D is associative
Identity law: similarly, identity natural transform’s components are the id morphisms id_F(X): F(X) → F(X) in D. Identity natural transform satisfy identity law, since all its components satisfy identity law.

Here is an example of natural transformations composition:

// ToFunc: Lazy<T> -> Func<T>
public static Func<T> ToFunc<T>(this Lazy<T> lazy) => () => lazy.Value;
#endif

// ToOptional: Func<T> -> Optional<T>
public static Optional<T> ToOptional<T>(this Func<T> function) =>
    new Optional<T>(() => (true, function()));

// ToOptional: Lazy<T> -> Optional<T>
public static Optional<T> ToOptional<T>(this Lazy<T> lazy) =>
    // new Func<Func<T>, Optional<T>>(ToOptional).o(new Func<Lazy<T>, Func<T>>(ToFunc))(lazy);
    lazy.ToFunc().ToOptional();
}

Endofunctor category

Given category C, there is a endofunctors category, denoted C^C, or End(C), where the objects are the endofunctors from category C to C itself, and the morphisms are the natural transformations between those endofunctors.

All the functors in C# are endofunctors from DotNet category to DotNet. They are the objects of endofunctor category DotNet^DotNet or End(DotNet).

Category Theory via C# (3) Functor and LINQ to Functors

Fri, 13 Dec 2024 13:10:00 GMT

[FP & LINQ via C# series]

[Category Theory via C# series]

Functor and functor laws

In category theory, functor is a mapping from category to category. Giving category C and D, functor F from category C to D is a structure-preserving morphism from C to D, denoted F: C → D:

F maps objects in C to objects in D, for example, X, Y, Z, … ∈ ob(C) are mapped to F(X), F(Y), F(Z), … ∈ in ob(D)
F also maps morphisms in C to morphisms in D, for example, m: X → Y ∈ hom(C) is mapped to morphism F(m): F(X) → F(Y) ∈ hom(D). In this tutorial, to align to C#/.NET terms, this morphism mapping capability of functor is also called “select”. so F(m) is also denoted Select_F(m).

And F must satisfy the following functor laws:

Composition preservation: F(m₂ ∘ m₁) ≡ F(m₂) ∘ F(m₁), or Select_F(m₂ ∘ m₁) ≡ Select_F(m₂) ∘ Select_F(m₁), F maps composition in C to composition in D
Identity preservation: F(id_X) ≡ id_F(X), or Select_F(id_X) ≡ id_F(X), F maps each identity morphism in C to identity morphism in D

Endofunctor

When a functor F’s source category and target category are the same category C, it is called endofunctor, denoted F: C → C. In the DotNet category, there are endofunctors mapping objects (types) and morphisms (functions) in DotNet category to other objects and morphisms in itself. In C#, endofunctor in DotNet can be defined as:

// Cannot be compiled.
public interface IFunctor<TFunctor<>> where TFunctor<> : IFunctor<TFunctor>
{
    Func<TFunctor<TSource>, TFunctor<TResult>> Select<TSource, TResult>(Func<TSource, TResult> selector);
}

In DotNet category, objects are types, so the functor’s type mapping capability is represented by generic type TFunctor<>, which maps type T to another type TFunctor<T>. And in DotNet category, morphisms are functions, so the functor’s function mapping capability is represented by the Select method, which maps function of type TSource –> TResult to another function of type TFunctor<TSource> –> TFunctor<TResult>.

Unfortunately, the above interface cannot be compiled, because C#/.NET do not support higher-kinded polymorphism for types.

Type constructor and higher-kinded type

Kind is the meta type of a type:

A concrete type has the simplest kind, denoted *. All non generic types (types without type parameters) are of kind *. Closed generic types (types with concrete type arguments) are also concrete types of kind *.
An open generic type definition with type parameter can be viewed as a type constructor, which works like a function. For example, IEnumerable<> can accept a type of kind * (like int), and return another closed type of kind * (like IEnumerable<int>), so IEnumerable<> is a type constructor, its kind is denoted * –> *; ValueTuple<,> can accept 2 types of kind * (like string and bool), and return another closed type of kind * (like ValueTuple<string, bool>) so ValueTuple<,> is a type constructor, its kind is denoted (*, *) –> *, or * –> * –> * in curried style.

In above IFunctor<TFunctor<>> generic type definition, its type parameter TFunctor<> is an open generic type of kind * –> *. As a result, IFunctor<TFunctor<>> can be viewed as a type constructor, which works like a higher-order function, accepting a TFunctor<> type constructor of kind * –> *, and returning a concrete type of kind *. So IFunctor<TFunctor<>> is of kind (* –> *) –> *. This is called a higher-kinded type, and not supported by .NET and C# compiler. In another word, C# generic type definition does not support its type parameter to have type parameters. In C#, functor support is implemented by LINQ query comprehensions instead of type system.

LINQ to Functors

Built-in IEnumerable<> functor

IEnumerable<> is a built-in functor of DotNet category, which can be viewed as virtually implementing above IFunctor<TFunctor<>> interface:

public interface IEnumerable<T> : IFunctor<IEnumerable<>>, IEnumerable
{
    // Func<IEnumerable<TSource>, IEnumerable<TResult>> Select<TSource, TResult>(Func<TSource, TResult> selector);

    // Other members.
}

Endofunctor IEnumerable<> in DotNet category maps each T object (type) to IEnumerable<T> object (type), and its Select method maps TSource→ TResult morphism (function) to IEnumerable<TSource> → IEnumerable<TResult> morphism (function). So its Select method is of type (TSource –> TResult) –> (IEnumerable<TSource> –> IEnumerable<TResult>), which can be uncurried to (TSource –> TResult, IEnumerable<TSource>) –> IEnumerable<TResult>:

public interface IEnumerable<T> : IFunctor<IEnumerable<T>>, IEnumerable
{
    // Func<IEnumerable<TSource>, IEnumerable<TResult>> Select<TSource, TResult>(Func<TSource, TResult> selector);
    // can be equivalently converted to:
    // IEnumerable<TResult> Select<TSource, TResult>(Func<TSource, TResult> selector, IEnumerable<TSource> source);

    // Other members.
}

Now swap the 2 parameters of the uncurried Select, then its type becomes (IEnumerable<TSource>, TSource –> TResult) –> IEnumerable<TResult>:

public interface IEnumerable<T> : IFunctor<IEnumerable<T>>, IEnumerable
{
    // Func<IEnumerable<TSource>, IEnumerable<TResult>> Select<TSource, TResult>(Func<TSource, TResult> selector);
    // can be equivalently converted to:
    // IEnumerable<TResult> Select<TSource, TResult>(IEnumerable<TSource> source, Func<TSource, TResult> selector);

    // Other members.
}

In .NET, this equivalent version of Select is exactly the LINQ query method Select. The following is the comparison of functor Select method and LINQ Select method:

public static partial class EnumerableExtensions // IEnumerable<T> : IFunctor<IEnumerable<>>
{
    // Functor Select: (TSource -> TResult) -> (IEnumerable<TSource> -> IEnumerable<TResult>).
    public static Func<IEnumerable<TSource>, IEnumerable<TResult>> Select<TSource, TResult>(
        Func<TSource, TResult> selector) => source => 
            Select(source, selector);

    // 1. Uncurry to Select: (TSource -> TResult, IEnumerable<TSource>) -> IEnumerable<TResult>.
    // 2. Swap 2 parameters to Select: (IEnumerable<TSource>, TSource -> TResult) -> IEnumerable<TResult>.
    // 3. Define as LINQ extension method.
    public static IEnumerable<TResult> Select<TSource, TResult>(
        this IEnumerable<TSource> source, Func<TSource, TResult> selector)
    {
        foreach (TSource value in source)
        {
            yield return selector(value);
        }
    }
}

So the IEnumerable<> functor’s morphism mapping capability is implemented as the LINQ mapping query. As a part of the LINQ query expression pattern, functor support is built in in the C# language:

internal static void Map()
{
    IEnumerable<int> source = System.Linq.Enumerable.Range(0, 5);
    // Map int to string.
    Func<int, string> selector = Convert.ToString;
    // Map IEnumerable<int> to IEnumerable<string>.
    IEnumerable<string> query = from value in source
                                select selector(value); // Define query.
    query.WriteLines(); // Execute query.
}

And the above Select implementation satisfies the functor laws:

// using static Dixin.Linq.CategoryTheory.Functions;
internal static void FunctorLaws()
{
    IEnumerable<int> source = new int[] { 0, 1, 2, 3, 4 };
    Func<int, double> selector1 = int32 => Math.Sqrt(int32);
    Func<double, string> selector2 = @double => @double.ToString("0.00");

    // Associativity preservation: source.Select(selector2.o(selector1)) == source.Select(selector1).Select(selector2).
    (from value in source
        select selector2.o(selector1)(value)).WriteLines();  // 0.00 1.00 1.41 1.73 2.00
    (from value in source
        select selector1(value) into value
        select selector2(value)).WriteLines();  // 0.00 1.00 1.41 1.73 2.00
    // Identity preservation: source.Select(Id) == Id(source).
    (from value in source
        select Id(value)).WriteLines(); // 0 1 2 3 4
    Id(source).WriteLines(); // 0 1 2 3 4
}

Functor pattern of LINQ

So LINQ Select mapping query’s quintessential mathematics is functor. Generally, in DotNet category, a type is a functor if:

This type is an open generic type definition, which can be viewed as type constructor of kind * –> *, so that it maps a concrete type T to another concrete functor-wrapped type.
It is equipped with the standard LINQ query method Select, which can be either instance method or extension method.
The implementation of Select satisfies the functor laws, so that DotNet category’s associativity law and identity law are preserved.

On the other hand, to enable the LINQ functor query expression (single from clauses with select clause) for a type does not require that type to be strictly a functor. This LINQ syntax can be enabled for any generic or non generic type with as long as it has such a Select method, , which can be virtually demonstrated as:

// Cannot be compiled.
internal static void Map<TFunctor<>, TSource, TResult>( // Non generic TFunctor can work too.
    TFunctor<TSource> functor, Func<TSource, TResult> selector) where TFunctor<> : IFunctor<TFunctor<>>
{
    TFunctor<TResult> query = from /* TSource */ value in /* TFunctor<TSource> */ functor
                              select /* TResult */ selector(value); // Define query.
}

More LINQ to Functors

Many other open generic type definitions provided by .NET can be functor. Take Lazy<> as example, first, apparently it is a type constructor of kind * –> *. Then, its Select query method can be defined as extension method:

public static partial class LazyExtensions // Lazy<T> : IFunctor<Lazy<>>
{
    // Functor Select: (TSource -> TResult) -> (Lazy<TSource> -> Lazy<TResult>)
    public static Func<Lazy<TSource>, Lazy<TResult>> Select<TSource, TResult>(
        Func<TSource, TResult> selector) => source =>
            Select(source, selector);

    // LINQ Select: (Lazy<TSource>, TSource -> TResult) -> Lazy<TResult>
    public static Lazy<TResult> Select<TSource, TResult>(
        this Lazy<TSource> source, Func<TSource, TResult> selector) =>
            new Lazy<TResult>(() => selector(source.Value));

    internal static void Map()
    {
        Lazy<int> source = new Lazy<int>(() => 1);
        // Map int to string.
        Func<int, string> selector = Convert.ToString;
        // Map Lazy<int> to Lazy<string>.
        Lazy<string> query = from value in source
                             select selector(value); // Define query.
        string result = query.Value; // Execute query.
    }
}

Func<> with 1 type parameter is also a functor with the following Select implementation:

public static partial class FuncExtensions // Func<T> : IFunctor<Func<>>
{
    // Functor Select: (TSource -> TResult) -> (Func<TSource> -> Func<TResult>)
    public static Func<Func<TSource>, Func<TResult>> Select<TSource, TResult>(
        Func<TSource, TResult> selector) => source =>
            Select(source, selector);

    // LINQ Select: (Func<TSource>, TSource -> TResult) -> Func<TResult>
    public static Func<TResult> Select<TSource, TResult>(
        this Func<TSource> source, Func<TSource, TResult> selector) =>
            () => selector(source());

    internal static void Map()
    {
        Func<int> source = () => 1;
        // Map int to string.
        Func<int, string> selector = Convert.ToString;
        // Map Func<int> to Func<string>.
        Func<string> query = from value in source
                             select selector(value); // Define query.
        string result = query(); // Execute query.
    }
}

Here Select maps TSource –> TResult function to Func<TSource> –> Func<TResult> function, which is straightforward. The other Func generic delegate types, like Func<,> with 2 type parameters, could be more interesting. Just like fore mentioned ValueTuple<,>, Func<,> is of kind * –> * –> *, and can be viewed as a type constructor accepting 2 concrete types and returning another concrete type, which is different from functor. However, if Func<,> already has a concrete type T as its first type parameter, then Func<T,> can be viewed as a partially applied type constructor of kind * –> *, which can map one concrete type (its second type parameter) to another concrete type. So that Func<T,> is also a functor, with the following Select method:

public static partial class FuncExtensions // Func<T, TResult> : IFunctor<Func<T,>>
{
    // Functor Select: (TSource -> TResult) -> (Func<T, TSource> -> Func<T, TResult>)
    public static Func<Func<T, TSource>, Func<T, TResult>> Select<T, TSource, TResult>(
        Func<TSource, TResult> selector) => source =>
            Select(source, selector);

    // LINQ Select: (Func<T, TSource>, TSource -> TResult) -> Func<T, TResult>
    public static Func<T, TResult> Select<T, TSource, TResult>(
        this Func<T, TSource> source, Func<TSource, TResult> selector) =>
            value => selector(source(value)); // selector.o(source);
}

This time Select maps TSource –> TResult function to Func<T, TSource> –> Func<T, TResult> function. Actually, Func<T,> functor’s Select is exactly the function composition:

internal static void Map<T>(T input)
{
    Func<T, string> source = value => value.ToString();
    // Map string to bool.
    Func<string, bool> selector = string.IsNullOrWhiteSpace;
    // Map Func<T, string> to Func<T, bool>.
    Func<T, bool> query = from value in source
                          select selector(value); // Define query.
    bool result = query(input); // Execute query.

    // Equivalent to:
    Func<T, string> function1 = source;
    Func<string, bool> function2 = selector;
    Func<T, bool> composition = function2.o(function1);
    result = composition(input);
}

ValueTuple<> with 1 type parameter simply wraps a value. It is the eager version of Lazy<>, and it is also functor, with the following Select method:

public static partial class ValueTupleExtensions // ValueTuple<T> : IFunctor<ValueTuple<>>
{
    // Functor Select: (TSource -> TResult) -> (ValueTuple<TSource> -> ValueTuple<TResult>)
    public static Func<ValueTuple<TSource>, ValueTuple<TResult>> Select<TSource, TResult>(
        Func<TSource, TResult> selector) => source =>
            Select(source, selector); // Immediate execution.

    // LINQ Select: (ValueTuple<TSource>, TSource -> TResult) -> ValueTuple<TResult>
    public static ValueTuple<TResult> Select<TSource, TResult>(
        this ValueTuple<TSource> source, Func<TSource, TResult> selector) =>
            new ValueTuple<TResult>(selector(source.Item1)); // Immediate execution.
}

Unlike all the previous Select, here ValueTuple<>’s Select query method cannot implement deferred execution. To construct a ValueTuple<TResult> instance and return, selector must be called immediately to evaluate the result value.

internal static void Map()
{
    ValueTuple<int> source = new ValueTuple<int>(1);
    // Map int to string.
    Func<int, string> selector = int32 =>
        {
            $"{nameof(selector)} is called with {int32}.".WriteLine();
            return Convert.ToString(int32);
        };
    // Map ValueTuple<int> to ValueTuple<string>.
    ValueTuple<string> query = from value in source // Define and execute query.
                                select selector(value); // selector is called with 1.
    string result = query.Item1; // Query result.
}

Similar to Func<T,>, ValueTuple<T,> is also functor, with the following Select method of immediate execution:

public static partial class ValueTupleExtensions // ValueTuple<T, T2> : IFunctor<ValueTuple<T,>>
{
    // Functor Select: (TSource -> TResult) -> (ValueTuple<T, TSource> -> ValueTuple<T, TResult>)
    public static Func<(T, TSource), (T, TResult)> Select<T, TSource, TResult>(
        Func<TSource, TResult> selector) => source =>
            Select(source, selector); // Immediate execution.

    // LINQ Select: (ValueTuple<T, TSource>, TSource -> TResult) -> ValueTuple<T, TResult>
    public static (T, TResult) Select<T, TSource, TResult>(
        this(T, TSource) source, Func<TSource, TResult> selector) =>
            (source.Item1, selector(source.Item2)); // Immediate execution.

    internal static void Map<T>(T item1)
    {
        (T, int) source = (item1, 1);
        // Map int to string.
        Func<int, string> selector = int32 =>
        {
            $"{nameof(selector)} is called with {int32}.".WriteLine();
            return Convert.ToString(int32);
        };
        // Map ValueTuple<T, int> to ValueTuple<T, string>.
        (T, string) query = from value in source // Define and execute query.
                            select selector(value); // selector is called with 1.
        string result = query.Item2; // Query result.
    }
}

Task is also an example of functor, with the following Select method:

public static partial class TaskExtensions // Task<T> : IFunctor<Task<>>
{
    // Functor Select: (TSource -> TResult) -> (Task<TSource> -> Task<TResult>)
    public static Func<Task<TSource>, Task<TResult>> Select<TSource, TResult>(
        Func<TSource, TResult> selector) => source =>
            Select(source, selector); // Immediate execution, impure.

    // LINQ Select: (Task<TSource>, TSource -> TResult) -> Task<TResult>
    public static async Task<TResult> Select<TSource, TResult>(
        this Task<TSource> source, Func<TSource, TResult> selector) =>
            selector(await source); // Immediate execution, impure.

    internal static async Task MapAsync()
    {
        Task<int> source = System.Threading.Tasks.Task.FromResult(1);
        // Map int to string.
        Func<int, string> selector = Convert.ToString;
        // Map Task<int> to Task<string>.
        Task<string> query = from value in source
                             select selector(value); // Define and execute query.
        string result = await query; // Query result.
    }
}

Similar to ValueTuple<>, above Select implementation is not deferred either. When Select is called, if the source task is already completed, the selector function is called immediately. And unlike all the previous Select methods are pure (referential transparent and side effect free), this Select use the await syntactic sugar to construct a state machine and start it immediately. So it changes state and is impure.

Nullable<> is also an interesting type. It is of kind * –> * and the following Select method can be defined:

public static partial class NullableExtensions // Nullable<T> : IFunctor<Nullable<>>
{
    // Functor Select: (TSource -> TResult) -> (Nullable<TSource> -> Nullable<TResult>)
    public static Func<TSource?, TResult?> Select2<TSource, TResult>(
        Func<TSource, TResult> selector) where TSource : struct where TResult : struct => source =>
            Select(source, selector); // Immediate execution.

    // LINQ Select: (Nullable<TSource>, TSource -> TResult) -> Nullable<TResult>
    public static TResult? Select<TSource, TResult>(
        this TSource? source, Func<TSource, TResult> selector) where TSource : struct where TResult : struct =>
            source.HasValue ? selector(source.Value) : default; // Immediate execution.

    internal static void Map()
    {
        long? source1 = 1L;
        // Map int to string.
        Func<long, TimeSpan> selector = TimeSpan.FromTicks;
        // Map Nullable<int> to Nullable<TimeSpan>.
        TimeSpan? query1 = from value in source1
                           select selector(value); // Define and execute query.
        TimeSpan result1 = query1.Value; // Query result.

        long? source2 = null;
        // Map Nullable<int> to Nullable<TimeSpan>.
        TimeSpan? query2 = from value in source2
                           select selector(value); // Define and execute query.
        bool result2 = query2.HasValue; // Query result.
    }
}

In the above Select method, if the source Nullable<TSource> instance represents an actual value of TSource, that value is extracted to call selector, and the result is wrapped into another Nullable<TResult> instance to return; if the source represents null, selector is not called, and a Nullable<TResult> instance representing null is directly returned. There are 2 issues here. First, Nullable<>’s type parameter is constrained to be structures, so it can only map some objects of DotNet category (the value types). Second, the Select implementation cannot be deferred. As LINQ query method, deferred execution is always preferred whenever possible. So the following Optional<T> type can be defined to be used with any type parameter, and also be lazy:

public readonly struct Optional<T>
{
    private readonly Lazy<(bool, T)> factory;

    public Optional(Func<(bool, T)> factory = null) =>
        this.factory = factory == null ? null : new Lazy<(bool, T)>(factory);

    public bool HasValue => this.factory?.Value.Item1 ?? false;

    public T Value
    {
        get
        {
            if (!this.HasValue)
            {
                throw new InvalidOperationException($"{nameof(Optional<T>)} object must have a value.");
            }
            return this.factory.Value.Item2;
        }
    }
}

Optional<T> is still a structure just like Nullable<T>, so its instance cannot be null. Its parameter is not constrained, so it can wrap any valid or invalid value of any type, Its constructor accepts a factory function just like Lazy<>, s the evaluation of its wrapped value can be deferred. And the factory function returns a tuple of bool value and T value, where the bool value indicates if the other T value is a valid value, and that bool value can be returned by the the HasValue property.

internal static void Optional()
{
    int int32 = 1;
    Func<int, string> function = Convert.ToString;

    Nullable<int> nullableInt32 = new Nullable<int>(int32);
    Nullable<Func<int, string>> nullableFunction = new Nullable<Func<int, string>>(function); // Cannot be compiled.
    Nullable<string> nullableString = new Nullable<string>(); // Cannot be compiled.

    Optional<int> optionalInt32 = new Optional<int>(() => (true, int32));
    Optional<Func<int, string>> optionalFunction = new Optional<Func<int, string>>(() => true, function));
    Optional<string> optionalString = new Optional<string>(); // Equivalent to: new Optional<string>(() => false, default);
}

Apparently, Optional<> is a factor, and its Select can be defined with deferred execution:

public static partial class OptionalExtensions // Optional<T> : IFunctor<Optional<>>
{
    // Functor Select: (TSource -> TResult) -> (Optional<TSource> -> Optional<TResult>)
    public static Func<Optional<TSource>, Optional<TResult>> Select<TSource, TResult>(
        Func<TSource, TResult> selector) => source =>
            Select(source, selector);

    // LINQ Select: (Optional<TSource>, TSource -> TResult) -> Optional<TResult>
    public static Optional<TResult> Select<TSource, TResult>(
        this Optional<TSource> source, Func<TSource, TResult> selector) =>
            new Optional<TResult>(() => source.HasValue
                ? (true, selector(source.Value)) : (false, default));

    internal static void Map()
    {
        Optional<int> source1 = new Optional<int>(() => (true, 1));
        // Map int to string.
        Func<int, string> selector = Convert.ToString;
        // Map Optional<int> to Optional<string>.
        Optional<string> query1 = from value in source1
                                    select selector(value); // Define query.
        if (query1.HasValue) // Execute query.
        {
            string result1 = query1.Value;
        }

        Optional<int> source2 = new Optional<int>();
        // Map Optional<int> to Optional<string>.
        Optional<string> query2 = from value in source2
                                    select selector(value); // Define query.
        if (query2.HasValue) // Execute query.
        {
            string result2 = query2.Value;
        }
    }
}

It is easy to verify all the above Select methods satisfy the functor laws. However, not any Select can automatically satisfy the functor laws. The following is a different Select implementation for Lazy<>:

public static Lazy<TResult> Select<TSource, TResult>(
    this Lazy<TSource> source, Func<TSource, TResult> selector) =>
        new Lazy<TResult>(() => default);

And it breaks the functor because it does not preserve the identity law:

internal static void FunctorLaws()
{
    Lazy<int> lazy = new Lazy<int>(() => 1);
    Func<int, string> selector1 = Convert.ToString;
    Func<string, double> selector2 = Convert.ToDouble;

    // Associativity preservation: TFunctor<T>.Select(f2.o(f1)) == TFunctor<T>.Select(f1).Select(f2)
    lazy.Select(selector2.o(selector1)).Value.WriteLine(); // 0
    lazy.Select(selector1).Select(selector2).Value.WriteLine(); // 0
    // Identity preservation: TFunctor<T>.Select(Id) == Id(TFunctor<T>)
    lazy.Select(Id).Value.WriteLine(); // 0
    Id(lazy).Value.WriteLine(); // 1
}

Category Theory via C# (2) Monoid

Thu, 12 Dec 2024 13:09:00 GMT

[FP & LINQ via C# series]

[Category Theory via C# series]

Monoid and monoid laws

Monoid is an important algebraic structure in category theory. A monoid M is a set M equipped with a binary operation ⊙ and a special element I, denoted 3-tuple (M, ⊙, I), where

M is a set of elements
⊙ is a binary operator called multiplication, so that M ⊙ M → M, which means the multiplication of 2 elements in set M always results an element in set M. This operation is also denoted μ, so that μ(M, M) ≡ M ⊙ M.
I is a special unit element (aka neutral element, or identity element) in set M

And the binary operator and the unit element must satisfy the following monoid laws:

associative law α_{X, Y, Z}: (X ⊙ Y) ⊙ Z ≡ X ⊙ (Y ⊙ Z), where X ∈ M, Y ∈ M, Z ∈ M
left unit law λ_X: I ⊙ X ≡ X, where X ∈ M; and right unit law ρ_X: X ≡ X ⊙ I, where X ∈ M

so that:

the triangle identity commutes:
and the pentagon identity commutes::

In C#, the monoid definition can be represented as:

public interface IMonoid<T>
{
    static abstract T Multiply(T value1, T value2);

    static abstract T Unit { get; }
}

An intuitive example is the set ℤ of all integers, with binary operator + and unit element 0. The addition of 2 integers always results another integer; Also for integers x, y ,z, there is (x + y) + z ≡ x + (y + z) and 0 + x ≡ x ≡ x + 0 (ℤ, +, 0), so that (ℤ, +, 0) is monoid. Apparently (ℤ, *, 1) is monoid too.

public class Int32SumMonoid : IMonoid<int>
{
    public static int Multiply(int value1, int value2) => value1 + value2;

    public static int Unit => GenericIndirection.AdditiveUnit<int>(); // 0.
}

public class Int32ProductMonoid : IMonoid<int>
{
    public static int Multiply(int value1, int value2) => value1 * value2;

    public static int Unit => GenericIndirection.MultiplicativeUnit<int>(); // 1.
}

public static class GenericIndirection
{
    public static T AdditiveUnit<T>() where T : IAdditiveIdentity<T, T> => T.AdditiveIdentity;

    public static T MultiplicativeUnit<T>() where T : IMultiplicativeIdentity<T, T> => T.MultiplicativeIdentity;
}

Another monoid example is (string, string.Concat, string.Empty):

public class StringConcatMonoid : IMonoid<string>
{
    public static string Multiply(string value1, string value2) => string.Concat(value1, value2);

    public static string Unit => string.Empty;
}

Here string can be viewed as a sequence of char, and the unit string is an empty sequence. Generally, (IEnumerable<T>, Enumerable.Concat<T>, Enumerable.Empty<T>()) is a monoid:

public class EnumerableConcatMonoid<T> : IMonoid<IEnumerable<T>>
{
    public static IEnumerable<T> Multiply(IEnumerable<T> value1, IEnumerable<T> value2) => value1.Concat(value2);

    public static IEnumerable<T> Unit => Enumerable.Empty<T>();
}

The set of Boolean values { true, false }, with binary operator && and unit element true, is a monoid with only 2 element: ({true, false}, &&, true); And so is ({ true, false }, ||, false):

public class BooleanAndMonoid : IMonoid<bool>
{
    public static bool Multiply(bool value1, bool value2) => value1 && value2;

    public static bool Unit => true;
}

public class BooleanOrMonoid : IMonoid<bool>
{
    public static bool Multiply(bool value1, bool value2) => value1 || value2;

    public static bool Unit => false;
}

A monoid with 1 single element can be defined with the special type void (System.Void):

namespace System
{
    [ComVisible(true)]
    [Serializable]
    [StructLayout(LayoutKind.Sequential, Size = 1)]
    public struct Void
    {
    }
}

The set { default(void) } with the following operator and unit is a monoid:

public class VoidMonoid : IMonoid<void>
{
    public void Multiply(void value1, void value2) => default;

    public void Unit() => default;
}

However, C# compiler does not allow void keyword or System.Void type to be used in this way, so here System.Void can be replaced with its equivalency in F#, the Microsoft.FSharp.Core.Unit type:

namespace Microsoft.FSharp.Core
{
    [CompilationMapping(SourceConstructFlags.ObjectType)]
    [Serializable]
    public sealed class Unit : IComparable
    {
        internal Unit() { }

        public override int GetHashCode() => 0;

        public override bool Equals(object obj) => 
            obj == null || LanguagePrimitives.IntrinsicFunctions.TypeTestGeneric<Unit>(obj);

        int IComparable.CompareTo(object obj) => 0;
    }
}

With an internal constructor, Unit cannot be instantiated, a Unit variable can only be default(Unit), which is null. So similarly, set { default(Unit) } with the following operator and unit element is monoid:

public class UnitMonoid : IMonoid<Unit>
{
    public static Unit Multiply(Unit value1, Unit value2) => default;

    public static Unit Unit => default;
}

Monoid as category

An individual monoid (M, ⊙, I) can be a category C with 1 single object M, where:

The collection of objects ob(C) is { M }, which means, category C has 1 single object, that is M.
The collection of orphisms hom(C) is set M itself, which mean, each elements in set M is a morphism in category C.
The composition operation ∘ of C is ⊙: since each morphism in C is each element in M, the composition of morphisms is just the multiplication of elements.
The identity morphism id of C is unit element I: the identity morphism in C is the unit element in M

In this way, since M, ⊙, I satisfies the monoid laws, apparently the category laws are satisfied. In C#, this singleton category can be represented as:

public class MonoidCategory<T, TMonoid> : ICategory<Type, T> where TMonoid : IMonoid<T>
{
    public static IEnumerable<Type> Objects { get { yield return typeof(TMonoid); } }

    public static T Compose(T morphism2, T morphism1) => TMonoid.Multiply(morphism1, morphism2);

    public static T Id(Type @object) => TMonoid.Unit;
}

Category Theory via C# (1) Fundamentals

Sun, 01 Dec 2024 13:08:00 GMT

[FP & LINQ via C# series]

[Category Theory via C# series]

Category theory is a theoretical framework to describe abstract structures and relations in mathematics, first introduced by Samuel Eilenberg and Saunders Mac Lane in 1940s. It examines mathematical concepts and properties in an abstract way, by formalizing them as collections of items and their relations. Category theory is abstract, and called "general abstract nonsense" by Norman Steenrod; It is also general, therefore widely applied in many areas in mathematics, physics, and computer science, etc. For programming, category theory is the algebraic theory of types and functions, and also the rationale and foundation of LINQ and any functional programming. This chapter discusses category theory and its important concepts, including category, morphism, natural transform, monoid, functor, and monad, etc. These general abstract concepts will be demonstrated with intuitive diagrams and specific C# and LINQ examples. These knowledge also helps building a deep understanding of functional programming in C# or other languages, since any language with types and functions is a category-theoretic structure.

Category and category laws

In category theory, a category C is a algebraic structure consists of the following 3 kinds of mathematical entities:

A collection of objects, denoted ob(C). This is not the objects in object-oriented programming paradigm.
A collection of morphisms (relations, aka arrows or maps) between objects, denoted hom(C). A morphism m from source object X to target object Y is denoted m: X → Y.
A composition operation of morphisms, denoted ∘. For m₁: X → Y and m₂: Y → Z, their composition is also a morphism (m₂∘ m₁): Y → Z. Here the name of m₁ of m₂ also implies the order. m₂ ∘ m₁ can be read as m₂ after m₁.

And these entities must satisfy the following 2 category laws:

Associative law: the composition of morphisms associative: For m₁: W → X, m₂: X → Y and m₃: Y → Z, there is (m₃ ∘ m₂) ∘ m_1≡ ≡ m₃ ∘ (m₂ ∘ m₁).
Identity law: for each object X, there is an identity morphism: id_x : X → X, and identity morphism is neutral for morphism composition. For m: X → Y, there is id_Y∘ m ≡ m ≡ m ∘ id_X.

To make above abstract definitions intuitive, a category can be represented by the following interface:

public interface ICategory<TObject, TMorphism>
{
    static abstract IEnumerable<TObject> Objects { get; }

    static abstract TMorphism Compose(TMorphism morphism2, TMorphism morphism1);

    static abstract TMorphism Id(TObject @object);
}

A simple example of category is the category of integers, where the collection of objects are all integers, and the collection of morphisms are ≤ (less than or equal to) relations, from an integer either to itself, or to another integer greater than or equal to it, for example: m₁: 0 → 1 (0 ≤ 1), m₂: 1 → 10 (1 ≤ 10), etc. Regarding the transitivity of inequality, the ≤ morphisms can be composed, for example, m₁: 0 → 1 (0 ≤ 1) and m₂: 1 → 10 (1 ≤ 10) can be composed to another morphism (m₂ ∘ m₁): 0 → 10 (0 ≤ 10).

Apparently, the above composition is associative, foe example: ((1 ≤ 10) ∘ (0 ≤ 1)) ∘ (-1 ≤ 0) ≡ -1 ≤ 10 ≡ (1 ≤ 10) ∘ ((0 ≤ 1) ∘ (-1 ≤ 0)). And for each integer X, there is an identity morphism id_X: X → X (X ≤ X), and (Y ≤ Y) ∘ (X ≤ Y) ≡ X ≤ Y ≡ (X ≤ Y) ∘ (X ≤ X). So the category laws are satisfied. In C#, integer can be represented by int, and the morphism of ≤ relation can be represented by a BinaryExpression of node type LessThanOrEqual, so the category can be represented as:

public class Int32Category : ICategory<int, BinaryExpression>
{
    public static IEnumerable<int> Objects
    {
        get
        {
            for (int int32 = int.MinValue; int32 <= int.MaxValue; int32++)
            {
                yield return int32;
            }
        }
    }

    public static BinaryExpression Compose(BinaryExpression morphism2, BinaryExpression morphism1) =>
        Expression.LessThanOrEqual(morphism2.Left, morphism1.Right); // (Y <= Z) ∘ (X <= Y) => X <= Z.

    public static BinaryExpression Id(int @object) =>
        Expression.GreaterThanOrEqual(Expression.Constant(@object), Expression.Constant(@object)); // X <= X.
}

DotNet category

.NET can also be viewed as a category of types and functions, called DotNet:

ob(DotNet): the collection of objects in DotNet category are .NET types, like string (System.String), int (System.Int32), bool (System.Boolean), etc.
hom(DotNet): the collection of morphisms in DotNet category are .NET pure functions between the input type (source object) to the output type (target object), like int.Parse: string → int, DateTime.IsLeapYear: int → bool, etc.
∘: in DotNet category, the composition operation of morphisms is the composition of functions.

As already discussed in lambda calculus chapter, function composition is associative, and the unit function Id is the identity morphism:

public static partial class Functions
{
    public static Func<TSource, TResult> o<TSource, TMiddle, TResult>(
        this Func<TMiddle, TResult> function2, Func<TSource, TMiddle> function1) =>
            value => function2(function1(value));

    public static TSource Id<TSource>(T value) => value;
}

So that the category laws are satisfied.

The DotNet category can be represented as:

public partial class DotNetCategory : ICategory<Type, Delegate>
{
    public static IEnumerable<Type> Objects => AppDomain.CurrentDomain.GetAssemblies()
        .SelectMany(assembly => assembly.ExportedTypes);

    public static Delegate Compose(Delegate morphism2, Delegate morphism1) =>
        // return (Func<TSource, TResult>)Functions.Compose<TSource, TMiddle, TResult>(
        //    (Func<TMiddle, TResult>)morphism2, (Func<TSource, TMiddle>)morphism1);
        (Delegate)typeof(Tutorial.FuncExtensions).GetMethod(nameof(Tutorial.FuncExtensions.o))
            .MakeGenericMethod( // TSource, TMiddle, TResult.
                morphism1.Method.GetParameters().Single().ParameterType,
                morphism1.Method.ReturnType,
                morphism2.Method.ReturnType)
            .Invoke(null, new object[] { morphism2, morphism1 });

    public static Delegate Id(Type @object) => // Functions.Id<TSource>
        typeof(Functions).GetMethod(nameof(Functions.Id)).MakeGenericMethod(@object)
            .CreateDelegate(typeof(Func<,>).MakeGenericType(@object, @object));
}

In DotNet category, each object is a type represented by System.Type, so Objects method queries all available types in current assembly, and also recursively query all available assemblies in all reference assemblies. And each morphism is a function from one type to another, which can be represented by System.Delegate, so the composition is just to call the o operator with 2 Delegate instances.

Lambda Calculus via C# (8) Undecidability of Equivalence

Thu, 28 Nov 2024 13:07:00 GMT

[FP & LINQ via C# series]

[Lambda Calculus via C# series]

All the previous parts demonstrated what lambda calculus can do – defining functions to model the computing, applying functions to execute the computing, implementing recursion, encoding data types and data structures, etc. Lambda calculus is a powerful tool, and it is Turing complete. This part discuss some interesting problem that cannot be done with lambda calculus – asserting whether 2 lambda expressions are equivalent.

Assuming f₁ and f₂ are 2 functions, they are equivalent if for ∀x, there is f₁ x ≡ f₂ x. For example, the following 2 functions can alpha-convert to each other:

f1 := λx.Add x 1
f2 := λy.Add y 1

Apparently they are equivalent. And they are both equivalent to:

f3 := λx.Add 1 x

because Add is commutative. Undecidability of equivalence means, in lambda calculus, there is no function can takes 2 lambda expressions as input, and returns True/False to indicate whether those 2 lambda expressions are equivalent or not. Alonzo Church has a proof using normal form. An intuitive proof can be done by viewing equivalence problem as another version of halting problem. Actually, Alonzo Church’s publish on equivalence is earlier (April 1936) than Alan Turing’s publish on halting problem (May 1936). To make it simple, this part discusses the undecidability of halting problem first, then discuss the undecidability of equivalence.

Halting problem

The halting problem is the problem of determining, when running an arbitrary program with an input, whether the program halts (finish running) or does not halt (run forever). For example:

Function Increase halts (finish running) with argument x, and returns x + 1.
Function ω does not halt with argument ω, Ω := ω ω reduces (runs) forever.

No general algorithm can solve the halting problem for all possible program-input pairs. To prove this, first define a simple function Sequence.

Sequence := λa.λb.b

When applying Sequence, the reduction strategy matters. In normal order, both its first argument is never reduced. In this part, applicative order is always assumed - the same reduction strategy as C#. So Sequence can be viewed as - reduce (run) a then reduce (run) b sequentially, and return the reduction result of b. When applying Sequence with Ω and another lambda expression. It reduces forever in applicative order:

  Sequence Ω x
≡ Sequence (ω ω) x
≡ Sequence ((λx.x x) (λx.x x)) x
≡ Sequence ((λx.x x) (λx.x x)) x
≡ ...

Because Ω does not halt, Sequence Ω does not halt either. In C#:

public static partial class Functions<T1, T2>
{
    public static readonly Func<T1, Func<T2, T2>> 
        Sequence = value1 => value2 => value2;
}

Assume an IsHalting function exists, which takes 2 parameters f and x, and returns True/False if function f halts/does not halt with parameter x:

IsHalting := λf.λx.If (/* f halts with x */) (λx.True) (λx.False)

Then an IsNotHalting function can be defined to test whether function f does not halt with argument f (itself):

IsNotHalting := λf.If (IsHalting f f) (λx.Sequence Ω False) (λx.True)

When a certain function f does not halt with itself, by definition IsNotHalting f returns True:

  IsNotHalting f
≡ If (IsHalting f f) (λx.Sequence Ω False) (λx.True))
≡ If (False) (λx.Sequence Ω False) (λx.True))
≡ True

Remember the If function is lazy, here λx.Sequence Ω False is never reduced. When f halts with itself, the application reduces to Sequence Ω False:

  IsNotHalting f
≡ If (IsHalting f f) (λx.Sequence Ω False) (λx.True))
≡ If (True) (λx.Sequence Ω False) (λx.True))
≡ Sequence Ω False
≡ Sequence (ω ω) False
≡ Sequence ((λx.x x) (λx.x x)) False
≡ Sequence ((λx.x x) (λx.x x)) False
≡ ...

As fore mentioned, Sequence Ω does not halt. So in this case, IsNotHalting f never returns False.

In C# IsHalting and IsNotHalting functions can be represented as:

internal static class Halting<T, TResult>
{
    // IsHalting = f => x => True if f halts with x; otherwise, False
    internal static readonly Func<Func<T, TResult>, Func<T, Boolean>>
        IsHalting = f => x => throw new NotImplementedException();

    // IsNotHalting = f => If(IsHalting(f)(f))(_ => Sequence(Ω)(False))(_ => True)
    internal static readonly Func<SelfApplicableFunc<TResult>, Boolean>
        IsNotHalting = f =>
            If(Halting<SelfApplicableFunc<TResult>, TResult>.IsHalting(new Func<SelfApplicableFunc<TResult>, TResult>(f))(f))
                (_ => Functions<TResult, Boolean>.Sequence(OmegaCombinators<TResult>.Ω)(False))
                (_ => True);
}

Here since f can be applied with itself, it is represented with the SelfApplicableFunc<TResult> function type.

It is interesting when IsNotHalting is applied with argument IsNotHalting (itself). Assume IsNotHalting halts with IsNotHalting, in another word:

  IsHalting IsNotHalting IsNotHalting
≡ True

then there is:

  IsNotHalting IsNotHalting
≡ If (IsHalting IsNotHalting IsNotHalting) (λx.Sequence Ω False) (λx.True)
≡ If (True) (λx.Sequence Ω False) (λx.True)
≡ Sequence Ω False
≡ Sequence (ω ω) False
≡ Sequence ((λx.x x) (λx.x x)) False
≡ Sequence ((λx.x x) (λx.x x)) False
≡ ...

So IsNotHalting IsNotHalting is reduced to Sequence Ω False, and is then reduced forever, which means actually IsNotHalting does not halt with IsNotHalting.

On the other hand, Assume IsNotHalting does not halt with IsNotHalting, in another word:

  IsHalting IsNotHalting IsNotHalting
≡ False

then there is:

  IsNotHalting IsNotHalting
≡ If (IsHalting IsNotHalting IsNotHalting) (λx.Sequence Ω False) (λx.True)
≡ If (False) (λx.Sequence Ω False) (λx.True)
≡ True

So IsNotHalting IsNotHalting is reduced to True, which means IsNotHalting halts with IsNotHalting.

Therefore, if IsHalting exists, it leads to IsNotHalting with the following properties:

If IsNotHalting halts with IsNotHalting, then IsNotHalting does not halt with IsNotHalting
If IsNotHalting does not halt with IsNotHalting, then IsNotHalting halts with IsNotHalting.

This proves IsNotHalting and IsHalting cannot exist.

Equivalence problem

After understanding the halting problem, the equivalence problem becomes very easy to prove. Assume an AreEquivalent function exists:

AreEquivalent := λa.λb.If (/* a and b are equivalent */) (λx.True) (λx.False)

which takes 2 lambda expression as parameter, and returns True/False if they are/are not equivalent. Now define the following 2 functions:

GetTrue1 := λf.λx.λy.Sequence (f x) True
GetTrue2 := λf.λx.λy.True

Given arbitrary function f and its argument x:

  GetTrue1 f x
≡ λy.Sequence (f x) True

  GetTrue2 f x
≡ λy.True

For specified f and x:

if f halts with x, then, ∀y, (GetTrue1 f x y) and (GetTrue2 f x y) both always returns True. That is, partially applied functions GetTrue1 f x and GetTrue2 f x are equivalent.
if f does not halt with x, then, ∀y, (GetTrue1 f x y) never returns True, and (GetTrue2 f x y) always returns True. That is, partially applied functions (GetTrue1 f x) and (GetTrue2 f x) are not equivalent.

Now halting problem and equivalence problem are connected. IsHalting function can be directly defined by AreEquivalent function:

IsHalting := λf.λx.AreEquivalent (GetTrue1 f x) (GetTrue2 f x)

The partial application (GetTrue1 f x) and (GetTrue2 f x) can be substituted as:

IsHalting := λf.λx.AreEquivalent (λy.Sequence (f x) True) (λy.True)

In C#:

internal static class Equivalence<T, TResult>
{
    // IsEquivalent = f1 => f2 => True if f1 and f2 are equivalent; otherwise, False
    internal static readonly Func<Func<T, TResult>, Func<Func<T, TResult>, Boolean>>
        IsEquivalent = f1 => f2 => throw new NotImplementedException();

    // IsHalting = f => x => IsEquivalent(_ => Sequence(f(x))(True))(_ => True)
    internal static readonly Func<Func<T, TResult>, Func<T, Boolean>>
        IsHalting = f => x => Equivalence<T, Boolean>.IsEquivalent(_ => Functions<TResult, Boolean>.Sequence(f(x))(True))(_ => True);
}

If the above AreEquivalent function can be defined, then IsHalting can be defined. It is already approved that IsHalting cannot exist, so AreEquivalent cannot exist either. This demonstrates equivalence problem is just another version of halting problem. So, lambda expressions’ equivalence is undecidable. The undecidability is actually a very general topic in computability theory and mathematical logic. The undecidability of halting problem and lambda calculus’ undecidability of equivalence are examples of Rice's theorem, and also examples of Kurt Gödel's incompleteness theorems.

Lambda Calculus via C# (7) Fixed Point Combinator and Recursion

Sat, 23 Nov 2024 13:19:00 GMT

[FP & LINQ via C# series]

[Lambda Calculus via C# series]

p is the fixed point (aka invariant point) of function f if and only if:

  p
≡ f p

Take function Math.Sqrt as example, it has 2 fix point, 0 and 1, so that 0 ≡ Math.Sqrt(0) and 1 ≡ Math.Sqrt(1).

The above fixed point definition also leads to infinite substitution:

  p
≡ f p
≡ f (f p)
≡ f (f (f p))
≡ ...
≡ f (f (f ... (f p) ...))

Similarly, the fixed point combinator Y is defined as if Y f is the fixed point of f:

  (Y f)
≡ f (Y f)

Normal order fixed point combinator (Y combinator) and recursion

The following Y combinator is an implementation of fixed point combinator, discovered by Haskell Curry:

Y := λf.(λg.f (g g)) (λg.f (g g))

It is called the normal order fixed point combinator:

  Y f
≡ (λf.(λg.f (g g)) (λg.f (g g))) f
≡ (λg.f (g g)) (λg.f (g g))
≡ f ((λg.f (g g)) (λg.f (g g)))
≡ f (Y f)

The following is Y implemented in SKI:

Y := S (K (S I I)) (S (S (K S) K) (K (S I I)))

And just in SK:

Y := S S K (S (K (S S (S (S S K)))) K)

When Y f can also be substituted infinitely:

  (Y f)
≡ f (Y f)
≡ f (f (Y f))
≡ f (f (f (Y f)))
≡ ...
≡ f (f (f ... (f (Y f)) ...))

So Y can be used to implement recursion. As fore mentioned, in lambda calculus, a function cannot directly apply it self in its body. Take the factorial function as example, the factorial of n is defined recursively:

If n is greater than 0, then factorial of n is the multiplication of n and factorial of n – 1
if n is 0, then factorial of n is 1

So naturally:

Factorial := λn.If (n == 0) (λx.1) (λx.n * (Factorial (n - 1)))

However, in lambda calculus the above definition is illegal, because the self reference does not work anonymously:

λn.If (n == 0) (λx.1) (λx.n * (? (n - 1)))

Now with the power of Y combinator, the recursion can be implemented, but still in the anonymous way. First, in above definition, just pass the reference of itself as an variable/argument:

λf.λn.If (n == 0) (λx.1) (λx.n * (f (n - 1)))

If the above function is called FactorialHelper, then the Factorial function can be implemented as:

FactorialHelper := λf.λn.If (n == 0) (λx.1) (λx.n * (f (n - 1)))
Factorial := Y FactorialHelper

So the recursive Factorial is implemented anonymously:

  Factorial
≡ Y FactorialHelper
≡ (λf.(λg.f (g g)) (λg.f (g g))) FactorialHelper
≡ (λf.(λg.f (g g)) (λg.f (g g))) (λf.λn.If (n == 0) (λx.1) (λx.n * (f (n - 1))))

When Factorial is applied, according to the definition of Factorial and Y:

  Factorial 3
≡ Y FactorialHelper 3
≡ FactorialHelper (Y FactorialHelper) 3

Here (Y FactorialHelper) can be substituted by Factorial, according to the definition. So FactorialHelper is called with Factorial and n, exactly as expected.

The normal order Y combinator does not work with applicative order reduction. In applicative order, here FactorialHelper is applied with (Y FactorialHelper), so the right most argument Y FactorialHelper should be reduced first, which leads to infinite reduction:

  FactorialHelper (Y FactorialHelper) 3
≡ FactorialHelper (FactorialHelper (Y FactorialHelper)) 3
≡ FactorialHelper (FactorialHelper (FactorialHelper (Y FactorialHelper))) 3
≡ ...

The normal order Y combinator only works with normal order. In normal order, here FactorialHelper is applied with (Y FactorialHelper), so the left most function FactorialHelper should be reduced first:

  FactorialHelper (Y FactorialHelper) 3
≡ (λf.λn.If (n == 0) (λx.1) (λx.n * (f (n - 1)))) (Y FactorialHelper) 3
≡ (λn.If (n == 0) (λx.1) (λx.n * (Y FactorialHelper (n - 1)))) 3
≡ If (3 == 0) (λx.1) (λx.3 * (Y FactorialHelper (3 - 1)))
≡ If (False) (λx.1) (λx.3 * (Y FactorialHelper (3 - 1))
≡ 3 * (Y FactorialHelper (3 - 1))
≡ 3 * (FactorialHelper (Y FactorialHelper) (3 - 1))
≡ 3 * ((λf.λn.If (n == 0) (λx.1) (λx.n * (f (n - 1)))) (Y FactorialHelper) (3 - 1))
≡ 3 * ((λn.If (n == 0) (λx.1) (λx.n * (Y FactorialHelper (n - 1)))) (3 - 1))
≡ 3 * (If ((3 - 1) == 0) (λx.1) (λx.(3 - 1) * (Y FactorialHelper ((3 - 1) - 1))))
≡ 3 * ((3 - 1) * (Y FactorialHelper ((3 - 1) - 1)))
≡ 3 * (2 * (Y FactorialHelper ((3 - 1) - 1)))
≡ 3 * (2 * (FactorialHelper (Y FactorialHelper) ((3 - 1) - 1)))
≡ 3 * (2 * ((λf.λn.If (n == 0) (λx.1) (λx.n * (f (n - 1)))) (Y FactorialHelper) ((3 - 1) - 1)))
≡ 3 * (2 * ((λn.If (n == 0) (λx.1) (λx.n * (Y FactorialHelper (n - 1)))) ((3 - 1) - 1)))
≡ 3 * (2 * (If (((3 - 1) - 1) == 0) (λx.1) (λx.((3 - 1) - 1) * (Y FactorialHelper (((3 - 1) - 1) - 1)))))
≡ 3 * (2 * (((3 - 1) - 1) * (Y FactorialHelper (((3 - 1) - 1) - 1))))
≡ 3 * (2 * (1 * (Y FactorialHelper (((3 - 1) - 1) - 1))))
≡ 3 * (2 * (1 * (FactorialHelper (Y FactorialHelper) (((3 - 1) - 1) - 1))))
≡ 3 * (2 * (1 * ((f.λn.If (n == 0) (λx.1) (λx.n * (f (n - 1)))) (Y FactorialHelper) (((3 - 1) - 1) - 1))))
≡ 3 * (2 * (1 * ((n.If (n == 0) (λx.1) (λx.n * (Y FactorialHelper (n - 1)))) (((3 - 1) - 1) - 1))))
≡ 3 * (2 * (1 * (If ((((3 - 1) - 1) - 1) == 0) (λx.1) (λx.(((3 - 1) - 1) - 1) * (Y FactorialHelper ((((3 - 1) - 1) - 1) - 1))))))
≡ 3 * (2 * (1 * 1))

So the Y f infinite reduction is blocked in in normal order reduction. First, Y f is reduced to f (Y f), then the next reduction is to reduce leftmost expression f, not the the rightmost (Y f). In the above example Y FactorialHelper n:

If n is greater than 0, Y Factorial n is reduced to n * (Y Factorial (n - 1)), where Y Factorial can be further reduced, so the recursion continues.
If n is 0, Y Factorial n is reduced to 1. The reduction ends, so the recursion terminates.

Y combinator is easy to implement in C#. Generally, for a recursive function f of type T -> TResult, its helper function accepts the T -> TResult function and a T value, then return TResult, so its helper function is of type (T -> TResult) –> T -> TResult. Y can be viewed as accepting helper function and returns f. so Y is of type ((T -> TResult) –> T -> TResult) -> (T -> TResult). So:

public static partial class FixedPointCombinators<T, TResult>
{
    // Y = (g => f(g(g)))(g => f(g(g)))
    public static readonly Func<Func<Func<T, TResult>, Func<T, TResult>>, Func<T, TResult>>
        Y = f => new SelfApplicableFunc<Func<T, TResult>>(g => f(g(g)))(g => f(g(g)));
}

Here are the types of the elements in above lambda expression:

g: SelfApplicableFunc<T -> TResult>
g(g): T -> TResult
f: (T -> TResult) –> T -> TResult
f(g(g)): T => TResult
g => f(g(g)): SelfApplicableFunc<T -> TResult> –> T -> TResult, which is SelfApplicableFunc<T -> TResult> by definition
(g => f(g(g)))(g => f(g(g))): T -> TResult

For Factorial, apparently it is of function type Numeral -> Numeral, so FactorialHelper is of function type (Numeral -> Numeral) –> Numeral -> Numeral:

using static FixedPointCombinators<Numeral, Numeral>;

public static partial class ChurchNumeral
{
    // FactorialHelper = factorial => n => If(n == 0)(_ => 1)(_ => n * factorial(n - 1))
    public static readonly Func<Func<Numeral, Numeral>, Func<Numeral, Numeral>>
        FactorialHelper = factorial => n =>
            If(n.IsZero())
                (_ => One)
                (_ => n.Multiply(factorial(n.Subtract(One))));

    public static readonly Func<Numeral, Numeral>
        Factorial = Y(FactorialHelper);
}

Calling above Factorial always throws StackOverflowException, because in C# executes in applicative order. When Factorial is called, it calls normal order Y in applicative order, which causes infinite execution.

Applicative order fixed point combinator (Z combinator) and recursion

The above Y combinator does not work in C#. When reducing Y f in applicative order, the self application in expression f (g g) leads to infinite reduction, which need to be blocked. The solution is to eta convert f (g g) to λx.f (g g) x. So the applicative order fixed point combinator is:

Z := λf.(λg.λx.f (g g) x) (λg.λx.f (g g) x)

It is called Z combinator. Now reduce Z f in applicative order:

  Z f
≡ (λf.(λg.λx.f (g g) x) (λg.λx.f (g g) x)) f
≡ (λg.λx.f (g g) x) (λg.λx.f (g g) x)
≡ λx.f ((λg.λx.f (g g) x) (λg.λx.f (g g) x)) x
≡ λx.f (Z f) x

This time Z f is not reduced to f (Z f), but reduced to the eta expanded version λx.f (Z f) x, so any further reduction is blocked. Still take factorial as example:

  Factorial 3
≡ Z FactorialHelper 3
≡ (λx.FactorialHelper (Z FactorialHelper) x) 3
≡ FactorialHelper (Z FactorialHelper) 3
≡ FactorialHelper (λx.FactorialHelper (Z FactorialHelper) x) 3
≡ (λf.λn.If (n == 0) (λx.1) (λx.n * (f (n - 1)))) (λx.FactorialHelper (Z FactorialHelper) x) 3
≡ (λn.If (n == 0) (λx.1) (λx.n * ((λx.FactorialHelper (Z FactorialHelper) x) (n - 1)))) 3
≡ If (3 == 0) (λx.1) (λx.3 * ((λx.FactorialHelper (Z FactorialHelper) x) (3 - 1)))
≡ If (False) (λx.1) (λx.3 * ((λx.FactorialHelper (Z FactorialHelper) x) (3 - 1)))
≡ 3 * ((λx.FactorialHelper (Z FactorialHelper) x) (3 - 1))
≡ 3 * ((λx.FactorialHelper (Z FactorialHelper) x) 2)
≡ 3 * (FactorialHelper (Z FactorialHelper) 2)
≡ 3 * (FactorialHelper (λx.FactorialHelper (Z FactorialHelper) x) 2)
≡ 3 * ((λf.λn.If (n == 0) (λx.1) (λx.n * (f (n - 1)))) (λx.FactorialHelper (Z FactorialHelper) x) 2)
≡ 3 * ((λn.If (n == 0) (λx.1) (λx.n * ((λx.FactorialHelper (Z FactorialHelper) x) (n - 1)))) 2)
≡ 3 * (If (2 == 0) (λx.1) (λx.2 * ((λx.FactorialHelper (Z FactorialHelper) x) (2 - 1))))
≡ 3 * (If (False) (λx.1) (λx.2 * ((λx.FactorialHelper (Z FactorialHelper) x) (2 - 1))))
≡ 3 * (2 * ((λx.FactorialHelper (Z FactorialHelper) x) (2 - 1)))
≡ 3 * (2 * ((λx.FactorialHelper (Z FactorialHelper) x) 1))
≡ 3 * (2 * (FactorialHelper (Z FactorialHelper) 1))
≡ 3 * (2 * (FactorialHelper (λx.FactorialHelper (Z FactorialHelper) x) 1))
≡ 3 * (2 * ((λf.λn.If (n == 0) (λx.1) (λx.n * (f (n - 1)))) (λx.FactorialHelper (Z FactorialHelper) x) 1))
≡ 3 * (2 * ((λn.If (n == 0) (λx.1) (λx.n * ((λx.FactorialHelper (Z FactorialHelper) x) (n - 1)))) 1))
≡ 3 * (2 * (If (1 == 0) (λx.1) (λx.1 * ((λx.FactorialHelper (Z FactorialHelper) x) (1 - 1)))))
≡ 3 * (2 * (If (False) (λx.1) (λx.1 * ((λx.FactorialHelper (Z FactorialHelper) x) (1 - 1)))))
≡ 3 * (2 * (1 * ((λx.FactorialHelper (Z FactorialHelper) x) (1 - 1))))
≡ 3 * (2 * (1 * ((λx.FactorialHelper (Z FactorialHelper) x) 0)))
≡ 3 * (2 * (1 * (FactorialHelper (Z FactorialHelper) 0)))
≡ 3 * (2 * (1 * (FactorialHelper (λx.FactorialHelper (Z FactorialHelper) x) 0)))
≡ 3 * (2 * (1 * ((λf.λn.If (n == 0) (λx.1) (λx.n * (f (n - 1)))) (λx.FactorialHelper (Z FactorialHelper) x) 0)))
≡ 3 * (2 * (1 * ((λn.If (n == 0) (λx.1) (λx.n * ((λx.FactorialHelper (Z FactorialHelper) x) (n - 1)))) 0)))
≡ 3 * (2 * (1 * (If (0 == 0) (λx.1) (λx.0 * ((λx.FactorialHelper (Z FactorialHelper) x) (n - 1))))))
≡ 3 * (2 * (1 * (If (True) (λx.1) (λx.0 * ((λx.FactorialHelper (Z FactorialHelper) x) (n - 1))))))
≡ 3 * (2 * (1 * 1))

In C#, Z combinator can be implemented in the same pattern. Just eta expand f(g(g)) to x => f(g(g))(x):

public static partial class FixedPointCombinators<T, TResult>
{
    // Z = (g => x => f(g(g))(x))(g => x => f(g(g))(x))
    public static readonly Func<Func<Func<T, TResult>, Func<T, TResult>>, Func<T, TResult>>
        Z = f => new SelfApplicableFunc<Func<T, TResult>>(g => x => f(g(g))(x))(g => x => f(g(g))(x));
}

The types of the elements in above lambda expression are the same as in Y combinator, and x is of type T.

Now Factorial can be defined with Z and above FactorialHelper:

using static ChurchBoolean;
using static FixedPointCombinators<Numeral, System.Func<Numeral, Numeral>>;

public static partial class ChurchNumeral
{
    // DivideByHelper = divideBy => dividend => divisor => If(dividend >= divisor)(_ => 1 + divideBy(dividend - divisor)(divisor))(_ => 0)
    private static readonly Func<Func<Numeral, Func<Numeral, Numeral>>, Func<Numeral, Func<Numeral, Numeral>>> DivideByHelper = divideBy => dividend => divisor =>
            If(dividend.IsGreaterThanOrEqualTo(divisor))
                (_ => One.Add(divideBy(dividend.Subtract(divisor))(divisor)))
                (_ => Zero);

    public static readonly Func<Numeral, Func<Numeral, Numeral>> 
        DivideBy = Z(DivideByHelper);
}

Another recursion example is Fibonacci number. The nth Fibonacci number is defined recursively:

if n is greater than 1, then the nth Fibonacci number is the sum of the (n -1)th Fibonacci number and the (n -2)th Fibonacci number.
if n is 1 or 0, then the nth Fibonacci number is n

So naturally:

Fibonacci := λn.If (n > 1) (λx.(Fibonacci (n - 1)) + (Fibonacci (n - 2))) (λx.n)

Again, the above recursive definition is illegal in lambda calculus, because the self reference does not work anonymously:

λn.If (n > 1) (λx.(? (n - 1)) + (? (n - 2))) (λx.n)

Following the same helper function pattern as FactorialHelper, a FibonacciHelper can be defined to pass the Fibonacci function as a variable/argument, then Fibonacci can be defined with Z and FibonacciHelper:

FibonacciHelper := λf.λn.If (n > 1) (λx.(f (n - 1)) + (f (n - 2))) (λx.n)
Fibonacci := Z FibonacciHelper

Now Fibonacci is recursive but still can go anonymous, without any self reference:

  Fibonacci
≡ Z FibonacciHelper
≡ (λf.(λg.λx.f (g g) x) (λg.λx.f (g g) x)) FibonacciHelper
≡ (λf.(λg.λx.f (g g) x) (λg.λx.f (g g) x)) (λf.λn.If (n > 1) (λx.(f (n - 1)) + (f (n - 2))) (λx.n))

In C#:

// FibonacciHelper  = fibonacci  => n => If(n > 1)(_ => fibonacci(n - 1) + fibonacci(n - 2))(_ => n)
private static readonly Func<Func<Numeral, Numeral>, Func<Numeral, Numeral>>
    FibonacciHelper = fibonacci => n =>
        If(n.IsGreaterThan(One))
            (_ => fibonacci(n.Subtract(One)).Add(fibonacci(n.Subtract(Two))))
            (_ => n);

// Fibonacci = Z(FibonacciHelper)
public static readonly Func<Numeral, Numeral>
    Fibonacci = Z(FibonacciHelper);

Previously, in the Church numeral arithmetic, the following illegal DivideBy with self reference was temporarily used:

DivideBy := λa.λb.If (a >= b) (λx.1 + (DivideBy (a - b) b)) (λx.0)

Finally, with Z, an legal DivideBy in lambda calculus can be defined, following the same helper function pattern:

DivideByHelper := λf.λa.λb.If (a >= b) (λx.1 + (f (a - b) b)) (λx.0)
DivideBy := Z DivideByHelper

The following is the formal version of DivideBy:

  DivideBy
≡ Z DivideByHelper
≡ (λf.(λg.λx.f (g g) x) (λg.λx.f (g g) x)) DivideByHelper
≡ (λf.(λg.λx.f (g g) x) (λg.λx.f (g g) x)) (λf.λa.λb.If (a >= b) (λx.1 + (f (a - b) b)) (λx.0))

In C#:

// DivideByHelper = divideBy => dividend => divisor => If(dividend >= divisor)(_ => 1 + divideBy(dividend - divisor)(divisor))(_ => 0)
private static readonly Func<Func<Numeral, Func<Numeral, Numeral>>, Func<Numeral, Func<Numeral, Numeral>>>
    DivideByHelper = divideBy => dividend => divisor =>
        If(dividend.IsGreaterThanOrEqualTo(divisor))
            (_ => One.Add(divideBy(dividend.Subtract(divisor))(divisor)))
            (_ => Zero);

// DivideBy = Z(DivideByHelper)
public static readonly Func<Numeral, Func<Numeral, Numeral>>
    DivideBy = Z(DivideByHelper);

The following are a few examples

public static partial class NumeralExtensions
{
    public static Numeral Factorial(this Numeral n) => ChurchNumeral.Factorial(n);

    public static Numeral Fibonacci(this Numeral n) => ChurchNumeral.Fibonacci(n);

    public static Numeral DivideBy(this Numeral dividend, Numeral divisor) => 
        ChurchNumeral.DivideBy(dividend)(divisor);
}

[TestClass]
public partial class FixedPointCombinatorTests
{
    [TestMethod]
    public void FactorialTest()
    {
        Func<uint, uint> factorial = null; // Must have to be compiled.
        factorial = x => x == 0 ? 1U : x * factorial(x - 1U);

        Assert.AreEqual(factorial(0U), 0U.Church().Factorial().Unchurch());
        Assert.AreEqual(factorial(1U), 1U.Church().Factorial().Unchurch());
        Assert.AreEqual(factorial(2U), 2U.Church().Factorial().Unchurch());
        Assert.AreEqual(factorial(8U), 8U.Church().Factorial().Unchurch());
    }

    [TestMethod]
    public void FibonacciTest()
    {
        Func<uint, uint> fibonacci = null; // Must have. So that fibonacci can recursively refer itself.
        fibonacci = x => x > 1U ? fibonacci(x - 1) + fibonacci(x - 2) : x;

        Assert.AreEqual(fibonacci(0U), 0U.Church().Fibonacci().Unchurch());
        Assert.AreEqual(fibonacci(1U), 1U.Church().Fibonacci().Unchurch());
        Assert.AreEqual(fibonacci(2U), 2U.Church().Fibonacci().Unchurch());
        Assert.AreEqual(fibonacci(8U), 8U.Church().Fibonacci().Unchurch());
    }

    [TestMethod]
    public void DivideByTest()
    {
        Assert.AreEqual(1U / 1U, 1U.Church().DivideBy(1U.Church()).Unchurch());
        Assert.AreEqual(1U / 2U, 1U.Church().DivideBy(2U.Church()).Unchurch());
        Assert.AreEqual(2U / 2U, 2U.Church().DivideBy(2U.Church()).Unchurch());
        Assert.AreEqual(2U / 1U, 2U.Church().DivideBy(1U.Church()).Unchurch());
        Assert.AreEqual(8U / 3U, 8U.Church().DivideBy(3U.Church()).Unchurch());
        Assert.AreEqual(3U / 8U, 3U.Church().DivideBy(8U.Church()).Unchurch());
    }
}

Lambda Calculus via C# (6) Combinatory Logic

Tue, 19 Nov 2024 13:06:00 GMT

[FP & LINQ via C# series]

[Lambda Calculus via C# series]

In lambda calculus, the primitive is function, which can have free variables and bound variables. Combinatory logic was introduced by Moses Schönfinkel and Haskell Curry in 1920s. It is equivalent variant lambda calculus, with combinator as primitive. A combinator can be viewed as an expression with no free variables in its body.

Combinator

The following is the simplest function definition expression, with only bound variable and no free variable:

I := λx.x

In combinatory logic it is called I (Id) combinator. The following functions are combinators too:

S := λx.λy.λz.x z (y z)
K := λx.λy.x

Here S (Slider) combinator slides z to between x and y (In some materials S is called Substitution; In presentation of Dana Scott S is called Slider), and K (Killer) combinator kills y.

In C#, just leave the each combinator’s variables as dynamic:

public static partial class SkiCombinators
{
    public static readonly Func<dynamic, Func<dynamic, Func<dynamic, dynamic>>>
        S = x => y => z => x(z)(y(z));

    public static readonly Func<dynamic, Func<dynamic, dynamic>>
        K = x => y => x;

    public static readonly Func<dynamic, dynamic>
        I = x => x;
}

ω is the self application combinator. It applies variable f to f itself:

ω := λf.f f

Just like above f, ω can also be applied with ω itself, which is the definition of Ω:

Ω := ω ω ≡ (λf.f f) (λf.f f)

Here ω is a function definition expression without free variables, and Ω is a function application expression, which contains no free variables. For Ω, its function application can be beta reduced forever:

  (λf.f f) (λf.f f)
≡ (λf.f f) (λf.f f)
≡ (λf.f f) (λf.f f)
≡ ...

So ω ω is an infinite application. Ω is called the looping combinator.

In C#, it is easy to define the type of self applicable function, like above f. Assume the function’s return type is TResult, then this function is of type input –> TResult:

public delegate TResult Func<TResult>(?);

The input type is the function type itself, so it is:

public delegate TResult Func<TResult>(Func<TResult> self)

Above Func<TResult> is the self applicable function type. To be unambiguous with System.Func<TResult>, it can be renamed to SelfApplicableFunc<TResult>:

public delegate TResult SelfApplicableFunc<TResult>(SelfApplicableFunc<TResult> self);

So SelfApplicableFunc<TResult> is equivalent to SelfApplicableFunc<TResult> -> TResult. Since f is of type SelfApplicableFunc<TResult>, f(f) returns TResult. And since ω accept f and returns TResult. ω is of type SelfApplicableFunc<TResult> -> TResult, which is the definition of SelfApplicableFunc<TResult>, so ω is still of type SelfApplicableFunc<TResult>, ω(ω) is still of type TResult:

public static class OmegaCombinators<TResult>
{
    public static readonly SelfApplicableFunc<TResult>
        ω = f => f(f);

    public static readonly TResult
        Ω = ω(ω);
}

SKI combinator calculus

The SKI combinator calculus is a kind of combinatory logic. As a variant of lambda calculus, SKI combinatory logic has no general expression definition rules, or general expression reduction rules. It only has the above S, K, I combinators as the only 3 primitives, and the only 3 function application rules. It can be viewed as a reduced version of lambda calculus, and an extremely simple Turing complete language with only 3 elements: S, K, I.

Take the Boolean values as a simple example. Remember in lambda calculus, True and False are defined as:

True := λt.λf.t
False := λt.λf.f

So that when they are applied:

  True t f
≡ (λt.λf.t) t f
≡ t

  False t f
≡ (λt.λf.f) t f
≡ f

Here in SKI combinator calculus, SKI combinators are the only primitives, so True and False can be defined as:

True := K
False := S K

So that when they are applied, they return the same result as the lambda calculus definition:

  True t f
≡ K t f
≡ t

  False t f
≡ S K t f
≡ K f (t f) 
≡ f

Remember function composition is defined as:

(f₂ ∘ f₁) x := f₂ (f₁ x)

In SKI, the composition operator can be equivalently defined as:

Compose := S (K S) K

And this is how it works:

  Compose f₂ f₁ x
≡ S (K S) K f₂ f₁ x
≡ (K S) f₂ (K f₂) f₁ x
≡ S (K f₂) f₁ x
≡ (K f₂) x (f₁ x)
≡ f₂ (f₁ x)

In lambda calculus, numerals are defined as:

0 := λf.λx.x
1 := λf.λx.f x
2 := λf.λx.f (f x)
3 := λf.λx.f (f (f x))
...

In SKI, numerals are equivalently defined as:

0 := K I                     ≡ K I
1 := I                       ≡ I
2 := S Compose I             ≡ S (S (K S) K) I
3 := S Compose (S Compose I) ≡ S (S (K S) K) (S (S (K S) K) I)
...

When these numerals are applied, they return the same results as lambda calculus definition:

  0 f x
≡ K I f x
≡ I x
≡ x

  1 f x
≡ I f x
≡ f x

  2 f x
≡ S Compose I f x
≡ Compose f (I f) x
≡ Compose f f x
≡ f (f x)

  3 f x
≡ S Compose (S Compose I) f x
≡ Compose f (S Compose I f) x
≡ Compose f (Compose f f) x
≡ f (f (f x))

...

In SKI, the self application combinator ω is:

ω := S I I

When it is applied with f, it returns f f:

  S I I f
≡ I x (I f) 
≡ f f

So naturally, Ω is defined as:

Ω := (S I I) (S I I)

And it is infinite as in lambda calculus:

  S I I (S I I)
≡ I (S I I) (I (S I I)) 
≡ I (S I I) (S I I) 
≡ S I I (S I I)
...

Actually, I combinator can be defined with S and K in either of the following ways:

I := S K K
I := S K S

And they work the same:

  I x
≡ S K K x
≡ K x (K x)
≡ x

  I x
≡ S K S x
≡ K x (S x)
≡ x

So I is just a syntactic sugar in SKI calculus.

In C#, these combinators can be implemented as:

using static SkiCombinators;

public static partial class SkiCalculus
{
    public static readonly Boolean
        True = new Boolean(K);

    public static readonly Boolean
        False = new Boolean(S(K));

    public static readonly Func<dynamic, dynamic>
        Compose = S(K(S))(K);

    public static readonly Func<dynamic, dynamic>
        Zero = K(I);

    public static readonly Func<dynamic, dynamic>
        One = I;

    public static readonly Func<dynamic, dynamic>
        Two = S(Compose)(I);

    public static readonly Func<dynamic, dynamic>
        Three = S(Compose)(S(Compose)(I));

    // ...

    public static readonly Func<dynamic, Func<dynamic, dynamic>>
        Increase = S(Compose);

    public static readonly Func<dynamic, dynamic>
        ω = S(I)(I);

    public static readonly Func<dynamic, dynamic>
        Ω = S(I)(I)(S(I)(I));

    public static readonly Func<dynamic, dynamic>
        IWithSK = S(K)(K); // Or S(K)(S).
}

SKI compiler: compile lambda calculus expression to SKI calculus combinator

The S, K, I combinators can be composed to new combinator that equivalent to any lambda calculus expression. An arbitrary expression in lambda calculus can be converted to combinator in SKI calculus. Assume v is a variable in lambda calculus, and E is an expression in lambda calculus, the conversion ToSki is defined as:

ToSki (v) => v
ToSki (E₁ E₂) => (ToSki (E₁) (ToSki (E₂)))
ToSki (λv.E) => (K (ToSki (E))), if x does not occur free in E
ToSki (λv.v) => I
ToSki (λv₁.λv₂.E) => ToSki (λv₁.ToSki (λv₂.E))
ToSki (λv.(E₁ E₂)) => (S (ToSki (λ.v.E₁)) (ToSki (λv.E₂)))

Based on these rules, a compiler can be implemented to compile a expression in lambda calculus to combinator in SKI calculus. As mentioned before, the C# lambda expression can be compiled as function, and also expression tree data representing the logic of that function:

internal static void FunctionAsData<T>()
{
    Func<T, T> idFunction = value => value;
    Expression<Func<T, T>> idExpression = value => value;
}

The above idFunction and idExpression shares the same lambda expression syntax, but is executable function, while the idExpression is a abstract syntax tree data structure, representing the logic of idFunction:

Expression<Func<T, T>> (NodeType = Lambda, Type = Func<T, T>)
|_Parameters
| |_ParameterExpression (NodeType = Parameter, Type = T)
|   |_Name = "value"
|_Body
  |_ParameterExpression (NodeType = Parameter, Type = T)
    |_Name = "value"

This metaprogramming feature provides great convenience for the conversion – just build the lambda calculus expression as .NET expression tree, traverse the tree and apply the above rules, and convert the tree to another tree representing the SKI calculus combinator.

A SKI calculus combinator, like above Ω combinator (S I I) (S I I), is a composition of S, K, I. The S, K, I primitives can be represented with a constant expression:

public class CombinatorExpression : Expression
{
    private CombinatorExpression(string name) => this.Name = name;

    public static CombinatorExpression S { get; } = new CombinatorExpression(nameof(S));

    public static CombinatorExpression K { get; } = new CombinatorExpression(nameof(K));

    public static CombinatorExpression I { get; } = new CombinatorExpression(nameof(I));

    public string Name { get; }

    public override ExpressionType NodeType { get; } = ExpressionType.Constant;

    public override Type Type { get; } = typeof(object);
}

The composition can be represented with a function application expression:

public class ApplicationExpression : Expression
{
    internal ApplicationExpression(Expression function, Expression variable)
    {
        this.Function = function;
        this.Variable = variable;
    }

    public Expression Function { get; }

    public Expression Variable { get; }

    public override ExpressionType NodeType { get; } = ExpressionType.Invoke;

    public override Type Type { get; } = typeof(object);
}

So the above Ω combinator (S I I) (S I I) can be represented by the following expression tree:

ApplicationExpression (NodeType = Invoke, Type = object)
|_Function
| |_ApplicationExpression (NodeType = Invoke, Type = object)
|   |_Function
|   | |_ApplicationExpression (NodeType = Invoke, Type = object)
|   |   |_Function
|   |   | |_CombinatorExpression (NodeType = Constant, Type = object)
|   |   |   |_Name = "S"
|   |   |_Variable
|   |     |_CombinatorExpression (NodeType = Constant, Type = object)
|   |       |_Name = "I"
|   |_Variable
|     |_CombinatorExpression (NodeType = Constant, Type = object)
|       |_Name = "I"
|_Variable
  |_ApplicationExpression (NodeType = Invoke, Type = object)
    |_Function
    | |_ApplicationExpression (NodeType = Invoke, Type = object)
    |   |_Function
    |   | |_CombinatorExpression (NodeType = Constant, Type = object)
    |   |   |_Name = "S"
    |   |_Variable
    |     |_CombinatorExpression (NodeType = Constant, Type = object)
    |       |_Name = "I"
    |_Variable
      |_CombinatorExpression (NodeType = Constant, Type = object)
        |_Name = "I"

So in the following SkiCompiler type, the ToSki is implemented to traverse the input abstract syntax tree recursively, and apply the above conversion rules:

public static partial class SkiCompiler
{
    public static Expression ToSki(this Expression lambdaCalculus)
    {
        // Ignore type convertion specified in code or generated by C# compiler.
        lambdaCalculus = lambdaCalculus.IgnoreTypeConvertion();

        switch (lambdaCalculus.NodeType)
        {
            case ExpressionType.Constant:
                // 0. ToSki(S) = S, ToSki(K) = K, ToSki(I) = I.
                if (lambdaCalculus is CombinatorExpression)
                {
                    return lambdaCalculus;
                }
                break;

            case ExpressionType.Parameter:
                // 1. ToSki(v) = v.
                return lambdaCalculus;

            case ExpressionType.Invoke:
                // 2. ToSki(E1(E2)) = ToSki(E1)(ToSKi(E2)).
                ApplicationExpression application = lambdaCalculus.ToApplication();
                return new ApplicationExpression(ToSki(application.Function), ToSki(application.Variable));

            case ExpressionType.Lambda:
                LambdaExpression function = (LambdaExpression)lambdaCalculus;
                ParameterExpression variable = function.Parameters.Single();
                Expression body = function.Body.IgnoreTypeConvertion();

                // 3. ToSki(v => E) = K(ToSki(E)), if v does not occur free in E.
                if (!variable.IsFreeIn(body))
                {
                    return new ApplicationExpression(CombinatorExpression.K, ToSki(body));
                }

                switch (body.NodeType)
                {
                    case ExpressionType.Parameter:
                        // 4. ToSki(v => v) = I
                        if (variable == (ParameterExpression)body)
                        {
                            return CombinatorExpression.I;
                        }
                        break;

                    case ExpressionType.Lambda:
                        // 5. ToSki(v1 => v2 => E) = ToSki(v1 => ToSki(v2 => E)), if v1 occurs free in E.
                        LambdaExpression bodyFunction = (LambdaExpression)body;
                        if (variable.IsFreeIn(bodyFunction.Body))
                        {
                            return ToSki(Expression.Lambda(ToSki(bodyFunction), variable));
                        }
                        break;

                    case ExpressionType.Invoke:
                        // 6. ToSki(v => E1(E2)) = S(ToSki(v => E1))(ToSki(v => E2)).
                        ApplicationExpression bodyApplication = body.ToApplication();
                        return new ApplicationExpression(
                            new ApplicationExpression(
                                CombinatorExpression.S,
                                ToSki(Expression.Lambda(bodyApplication.Function, variable))),
                            ToSki(Expression.Lambda(bodyApplication.Variable, variable)));
                }
                break;
        }
        throw new ArgumentOutOfRangeException(nameof(lambdaCalculus));
    }
}

It calls a few helper functions:

private static Expression IgnoreTypeConvertion(this Expression lambdaCalculus) =>
    lambdaCalculus.NodeType == ExpressionType.Convert
        ? ((UnaryExpression)lambdaCalculus).Operand
        : lambdaCalculus;

private static ApplicationExpression ToApplication(this Expression expression)
{
    switch (expression)
    {
        case ApplicationExpression application:
            return application;
        case InvocationExpression invocation:
            return new ApplicationExpression(invocation.Expression, invocation.Arguments.Single());
    }
    throw new ArgumentOutOfRangeException(nameof(expression));
}

private static bool IsFreeIn(this ParameterExpression variable, Expression lambdaCalculus)
{
    // Ignore type convertion specified in code or generated by C# compiler.
    lambdaCalculus = lambdaCalculus.IgnoreTypeConvertion();

    switch (lambdaCalculus.NodeType)
    {
        case ExpressionType.Invoke:
            ApplicationExpression application = lambdaCalculus.ToApplication();
            return variable.IsFreeIn(application.Function) || variable.IsFreeIn(application.Variable);
        case ExpressionType.Lambda:
            LambdaExpression function = (LambdaExpression)lambdaCalculus;
            return variable != function.Parameters.Single() && variable.IsFreeIn(function.Body);
        case ExpressionType.Parameter:
            return variable == (ParameterExpression)lambdaCalculus;
        case ExpressionType.Constant:
            return false;
    }
    throw new ArgumentOutOfRangeException(nameof(lambdaCalculus));
}

Sometimes, in order to make the lambda calculus expression be compiled, some type information has to be added manually or automatically by C# compiler. These type conversion information is not needed, and can be removed by IgnoreTypeConvertion. In lambda expression, function invocation is compiled as InvocationExpression node with node type Invoke, which is the same as ApplicationExpression. For convenience, ToApplication unifies all Invoke nodes to ApplicationExpression. And IsFreeIn recursively test whether the specified variable occurs free in the specified lambda calculus expression.

Finally, for readability, the following ToSkiString method Converts the compiled SKI calculus expression to string representation:

public static string ToSkiString(this Expression skiCalculus) => skiCalculus.ToSkiString(false);

private static string ToSkiString(this Expression skiCalculus, bool parentheses)
{
    switch (skiCalculus.NodeType)
    {
        case ExpressionType.Invoke:
            ApplicationExpression application = (ApplicationExpression)skiCalculus;
            return parentheses
                ? $"({application.Function.ToSkiString(false)} {application.Variable.ToSkiString(true)})"
                : $"{application.Function.ToSkiString(false)} {application.Variable.ToSkiString(true)}";
        case ExpressionType.Parameter:
            return ((ParameterExpression)skiCalculus).Name;
        case ExpressionType.Constant:
            return ((CombinatorExpression)skiCalculus).Name;
    }
    throw new ArgumentOutOfRangeException(nameof(skiCalculus));
}

The following example demonstrates how to represent 2-tuple in SKI calculus combinator:

internal static void Tuple<T1, T2>()
{
    Expression<Func<T1, Func<T2, Tuple<T1, T2>>>>
        createTupleLambda = item1 => item2 => f => f(item1)(item2);
    Expression createTupleSki = createTupleLambda.ToSki();
    createTupleSki.ToSkiString().WriteLine();
    // S (S (K S) (S (K K) (S (K S) (S (K (S I)) (S (K K) I))))) (K (S (K K) I))
}

To verify the result, a tuple can be created with x as first item, and y as the second item:

  CreateTuple x y
≡ S (S (K S) (S (K K) (S (K S) (S (K (S I)) (S (K K) I))))) (K (S (K K) I)) x y
≡ S (K S) (S (K K) (S (K S) (S (K (S I)) (S (K K) I)))) x (K (S (K K) I) x) y
≡ K S x (S (K K) (S (K S) (S (K (S I)) (S (K K) I))) x) (K (S (K K) I) x) y
≡ S (S (K K) (S (K S) (S (K (S I)) (S (K K) I))) x) (K (S (K K) I) x) y
≡ S (K K) (S (K S) (S (K (S I)) (S (K K) I))) x y (K (S (K K) I) x y)
≡ K K x (S (K S) (S (K (S I)) (S (K K) I)) x) y (K (S (K K) I) x y)
≡ K (S (K S) (S (K (S I)) (S (K K) I)) x) y (K (S (K K) I) x y)
≡ S (K S) (S (K (S I)) (S (K K) I)) x (K (S (K K) I) x y)
≡ K S x (S (K (S I)) (S (K K) I) x) (K (S (K K) I) x y)
≡ S (S (K (S I)) (S (K K) I) x) (K (S (K K) I) x y)
≡ S (K (S I) x (S (K K) I x)) (K (S (K K) I) x y)
≡ S (S I (S (K K) I x)) (K (S (K K) I) x y)
≡ S (S I ((K K) x (I x))) (K (S (K K) I) x y)
≡ S (S I (K (I x))) (K (S (K K) I) x y)
≡ S (S I (K x)) (K (S (K K) I) x y)
≡ S (S I (K x)) (S (K K) I y)
≡ S (S I (K x)) (K K y (I y))
≡ S (S I (K x)) (K (I y))
≡ S (S I (K x)) (K y)

To get the first/second item of the above tuple, apply it with True/False:

  Item1 (CreateTuple x y)
≡ (CreateTuple x y) True
≡ S (S I (K x)) (K y) True
≡ S (S I (K x)) (K y) K
≡ S I (K x) K (K y K)
≡ I K (K x K) (K y K)
≡ K (K x K) (K y K)
≡ K x K
≡ x

  Item2 (CreateTuple x y)
≡ (CreateTuple x y) False
≡ S (S I (K x)) (K y) False
≡ S (S I (K x)) (K y) (S K)
≡ S I (K x) (S K) (K y (S K))
≡ I (S K) (K x (S K)) (K y (S K))
≡ S K (K x (S K)) (K y (S K))
≡ K y (K x (S K) y)
≡ y

So the compiled 2-tuple SKI calculus combinator is equivalent to the lambda calculus expression.

Another example is the logic operator And:

And := λa.λb.a b False ≡ λa.λb.a b (λt.λf.f)

So in C#:

internal static void And()
{
    Expression<Func<Boolean, Func<Boolean, Boolean>>>
        andLambda = a => b => a(b)((Boolean)(@true => @false => @false));
    Expression andSki = andLambda.ToSki();
    andSki.ToSkiString().WriteLine();;
}

Unfortunately, above expression tree cannot be compiled, with error CS1963: An expression tree may not contain a dynamic operation. The reason is, Boolean is the alias of Func<dynamic, Func<dynamic, dynamic>>, and C# compiler does not support dynamic operations in expression tree, like calling a(b) here. At compile time, dynamic is just object, so the solution is to replace dynamic with object, and replace Boolean with object –> object -> object, then the following code can be compiled:

internal static void And()
{
    Expression<Func<Func<object, Func<object, object>>, Func<Func<object, Func<object, object>>, Func<object, Func<object, object>>>>>
        andLambda = a => b => (Func<object, Func<object, object>>)a(b)((Func<object, Func<object, object>>)(@true => @false => @false));
    Expression andSki = andLambda.ToSki();
    andSki.ToSkiString().WriteLine();
    // S (S (K S) (S (S (K S) (S (K K) I)) (K I))) (K (K (K I)))
}

The compilation result can be verified in similar way:

  And True True
≡ S (S (K S) (S (S (K S) (S (K K) I)) (K I))) (K (K (K I))) True True
≡ S (S (K S) (S (S (K S) (S (K K) I)) (K I))) (K (K (K I))) K K
≡ S (K S) (S (S (K S) (S (K K) I)) (K I)) K (K (K (K I)) K) K
≡ K S K (S (S (K S) (S (K K) I)) (K I) K) (K (K (K I)) K) K
≡ S (S (S (K S) (S (K K) I)) (K I) K) (K (K (K I)) K) K
≡ S (S (K S) (S (K K) I)) (K I) K K (K (K (K I)) K K)
≡ S (K S) (S (K K) I) K (K I K) K (K (K (K I)) K K)
≡ K S K (S (K K) I K) (K I K) K (K (K (K I)) K K)
≡ S (S (K K) I K) (K I K) K (K (K (K I)) K K)
≡ S (K K) I K K (K I K K) (K (K (K I)) K K)
≡ K K K (I K) K (K I K K) (K (K (K I)) K K)
≡ K (I K) K (K I K K) (K (K (K I)) K K)
≡ I K (K I K K) (K (K (K I)) K K)
≡ K (K I K K) (K (K (K I)) K K)
≡ K I K K
≡ I K
≡ K
≡ True

  And True False
≡ S (S (K S) (S (S (K S) (S (K K) I)) (K I))) (K (K (K I))) True False
≡ S (S (K S) (S (S (K S) (S (K K) I)) (K I))) (K (K (K I))) K (S K)
≡ (S (K S)) (S (S (K S) (S (K K) I)) (K I)) K (K (K (K I)) K) (S K)
≡ K S K (S (S (K S) (S (K K) I)) (K I) K) (K (K (K I)) K) (S K)
≡ S (S (S (K S) (S (K K) I)) (K I) K) (K (K (K I)) K) (S K)
≡ S (S (K S) (S (K K) I)) (K I) K (S K) (K (K (K I)) K (S K))
≡ S (K S) (S (K K) I) K (K I K) (S K) (K (K (K I)) K (S K))
≡ K S K (S (K K) I K) (K I K) (S K) (K (K (K I)) K (S K))
≡ S (S (K K) I K) (K I K) (S K) (K (K (K I)) K (S K))
≡ S (K K) I K (S K) (K I K (S K)) (K (K (K I)) K (S K))
≡ K K K (I K) (S K) (K I K (S K)) (K (K (K I)) K (S K))
≡ K (I K) (S K) (K I K (S K)) (K (K (K I)) K (S K))
≡ I K (K I K (S K)) (K (K (K I)) K (S K))
≡ K (K I K (S K)) (K (K (K I)) K (S K))
≡ K I K (S K)
≡ I (S K)
≡ S K
≡ False

...

Iota combinator calculus

Another interesting example of combinator logic is Iota combinator calculus. It has only one combinator:

ι := λf.f S K ≡ λf.f (λx.λy.λz.x z (y z)) (λx.λy.x)

That’s the whole combinatory logic. It is an esoteric programming language with minimum element – only 1 single element, but still Turing-complete. With Iota combinator, SKI can be implemented as:

S := ι (ι (ι (ι ι)))
K := ι (ι (ι ι))
I := ι ι

So Iota is as Turing-complete as SKI. For example:

  I x
≡ ι ι x
≡ (λf.f S K) (λf.f S K) x
≡ (λf.f S K) S K x
≡ (S S K) K x
≡ S K (K K) x
≡ K x ((K K) x)
≡ x

In C#, these combinators can be implemented as:

public static partial class IotaCombinator
{
    public static readonly Func<dynamic, dynamic>
        ι = f => f
            (new Func<dynamic, Func<dynamic, Func<dynamic, dynamic>>>(x => y => z => x(z)(y(z)))) // S
            (new Func<dynamic, Func<dynamic, dynamic>>(x => y => x)); // K
}

public static class IotaCalculus
{
    public static readonly Func<dynamic, Func<dynamic, Func<dynamic, dynamic>>>
        S = ι(ι(ι(ι(ι))));

    public static readonly Func<dynamic, Func<dynamic, dynamic>>
        K = ι(ι(ι(ι)));

    public static readonly Func<dynamic, dynamic>
        I = ι(ι);
}

Lambda Calculus via C# (5) List

Wed, 13 Nov 2024 13:06:00 GMT

[FP & LINQ via C# series]

[Lambda Calculus via C# series]

In lambda calculus and Church encoding, there are various ways to represent a list with anonymous functions.

Tuple as list node

With Church pair, it is easy to model Church list as a linked list, where each list node is a a Church pair (2-tuple) of current node’s value and the next node, So that

CreateListNode := CreateTuple = λv.λn.λf.f v n
ListNode := Tuple = λf.f v n

Here variable v is the value of the current node, so it is the first item of the tuple; And variable n is the next node of the current node, so it is the second item of the tuple:

Value := Item1 = λl.l (λv.λn.v)
Next := Item2 = λl.l (λv.λn.n)

Here variable l is the list node. The C# implementation is similar to tuple and signed numeral, except ListNode<T> function type now has 1 type parameter, which is the type of its value:

// ListNode<T> is the alias of Tuple<T, ListNode<T>>.
public delegate dynamic ListNode<out T>(Boolean f);

public static partial class ChurchList<T>
{
    // Create = value => next => (value, next)
    public static readonly Func<T, Func<ListNode<T>, ListNode<T>>>
        Create = value => next => new ListNode<T>(ChurchTuple<T, ListNode<T>>.Create(value)(next));

    // Value = node => node.Item1()
    public static readonly Func<ListNode<T>, T> 
        Value = node => new Tuple<T, ListNode<T>>(node).Item1();

    // Next = node => node.Item2()
    public static readonly Func<ListNode<T>, ListNode<T>> 
        Next = node => new Tuple<T, ListNode<T>>(node).Item2();
}

Usually, when a list ends, its last node’s next node is flagged as a special null node. Here in lambda calculus, since a node is an anonymous function, the null node is also an anonymous function:

Null := λf.λx.x

And IsNull predicate returns a Church Boolean to indicate whether a list node is null:

IsNull := λl.l (λv.λn.λx.False) True

When IsNull is applied with a null node:

  IsNull Null
≡ (λl.l (λv.λn.λx.False) True) (λf.λx.x)
≡ (λf.λx.x) (λv.λn.λx.False) True
≡ (λx.x) True
≡ True

And when IsNull is applied with a non-null node:

  IsNull (CreateListNode 0 Null)
≡ IsNull (λf.f 0 Null)
≡ (λl.l (λv.λn.λx.False) True) (λf.f 0 Null)
≡ (λf.f 0 Null) (λv.λn.λx.False) True
≡ (λv.λn.λx.False) 0 Null True
≡ (λn.λx.False) Null True
≡ (λx.False) True
≡ False

The C# implementation is noisy because a lot of type information has to be provided. This is Null:

using static ChurchBoolean;

public static partial class ChurchList<T>
{
    // Null = False;
    public static readonly ListNode<T>
        Null = new ListNode<T>(False);

    // IsNull = node => node(value => next => _ => False)(True)
    public static readonly Func<ListNode<T>, Boolean> 
        IsNull = node => node(value => next => new Func<Boolean, Boolean>(_ => False))(True);
}

And the indexer for list can be easily defined with as a function accepts a start node and a Church numeral i as the specified index. To return the node at the specified index, just call Next function for i times from the start node:

ListNodeAt := λl.λi.i Next l

C#:

public static readonly Func<ListNode<T>, Func<Numeral, ListNode<T>>>
    ListNodeAt = start => index => index(node => Next(node))(start);

The following are the extension methods wrapping the list operators:

public static class ListNodeExtensions
{
    public static T Value<T>(this ListNode<T> node) => ChurchList<T>.Value(node);

    public static ListNode<T> Next<T>(this ListNode<T> node) => ChurchList<T>.Next(node);

    public static Boolean IsNull<T>(this ListNode<T> node) => ChurchList<T>.IsNull(node);

    public static ListNode<T> ListNodeAt<T>(this ListNode<T> start, Numeral index) => ChurchList<T>.ListNodeAt(start)(index);
}

And the following code demonstrates how the list works:

[TestClass]
public class ChurchListTests
{
    [TestMethod]
    public void CreateValueNextTest()
    {
        ListNode<int> node1 = ChurchList<int>.Create(1)(ChurchList<int>.Null);
        ListNode<int> node2 = ChurchList<int>.Create(2)(node1);
        ListNode<int> node3 = ChurchList<int>.Create(3)(node2);
        Assert.AreEqual(1, node1.Value());
        Assert.AreEqual(ChurchList<int>.Null, node1.Next());
        Assert.AreEqual(2, node2.Value());
        Assert.AreEqual(node1, node2.Next());
        Assert.AreEqual(3, node3.Value());
        Assert.AreEqual(node2, node3.Next());
        Assert.AreEqual(node2.Value(), node3.Next().Value());
        Assert.AreEqual(node1.Value(), node3.Next().Next().Value());
        Assert.AreEqual(ChurchList<int>.Null, node3.Next().Next().Next());
        try
        {
            ChurchList<object>.Null.Next();
            Assert.Fail();
        }
        catch (InvalidCastException exception)
        {
            exception.WriteLine();
        }
    }

    [TestMethod]
    public void IsNullTest()
    {
        ListNode<int> node1 = ChurchList<int>.Create(1)(ChurchList<int>.Null);
        ListNode<int> node2 = ChurchList<int>.Create(2)(node1);
        ListNode<int> node3 = ChurchList<int>.Create(3)(node2);
        Assert.IsTrue(ChurchList<object>.Null.IsNull().Unchurch());
        Assert.IsFalse(node1.IsNull().Unchurch());
        Assert.IsFalse(node2.IsNull().Unchurch());
        Assert.IsFalse(node3.IsNull().Unchurch());
        Assert.IsTrue(node1.Next().IsNull().Unchurch());
        Assert.IsFalse(node2.Next().IsNull().Unchurch());
        Assert.IsFalse(node3.Next().IsNull().Unchurch());
    }

    [TestMethod]
    public void IndexTest()
    {
        ListNode<int> node1 = ChurchList<int>.Create(1)(ChurchList<int>.Null);
        ListNode<int> node2 = ChurchList<int>.Create(2)(node1);
        ListNode<int> node3 = ChurchList<int>.Create(3)(node2);
        Assert.AreEqual(node3, node3.NodeAt(0U.Church()));
        Assert.AreEqual(node2, node3.NodeAt(1U.Church()));
        Assert.AreEqual(node1, node3.NodeAt(2U.Church()));
        Assert.IsTrue(node3.NodeAt(3U.Church()).IsNull().Unchurch());
        try
        {
            node3.NodeAt(4U.Church());
            Assert.Fail();
        }
        catch (InvalidCastException exception)
        {
            exception.WriteLine();
        }
    }
}

Aggregate function as list node

Remember the LINQ Aggregate query method accepting a seed and a accumulator function:

TAccumulate Aggregate<TSource, TAccumulate>(this IEnumerable<TSource> source, TAccumulate seed, Func<TAccumulate, TSource, TAccumulate> func);

Assume seed is x, and accumulator function is f:

When source is empty, the aggregation result is x
When source is { 0 }, the aggregation result is f(x, 0)
When source is { 1, 0 }, the aggregation result is f(f(x, 1), 0)
When source is { 2, 1, 0 }, the aggregation result is f(f(f(x, 2), 1), 0)

Church list can also be encoded with a similar Aggregate function with seed and accumulator function:

dynamic AggregateListNode<T>(dynamic x, Func<dynamic, T, dynamic> f);

Its type parameter T is the type of node value. And since the seed can be anything, just leave it as dynamic as usual. So the list node is of above aggregate function type (dynamic, (dynamic , T) -> dynamic) -> dynamic. After currying the aggregate function and the accumulator function, it becomes dynamic -> (dynamic –> T -> dynamic) -> dynamic. So this is the function type of list node, and an alias can be defined as:

// Curried from: (dynamic, dynamic -> T -> dynamic) -> dynamic.
// AggregateListNode is the alias of: dynamic -> (dynamic -> T -> dynamic) -> dynamic.
public delegate Func<Func<dynamic, Func<T, dynamic>>, dynamic> AggregateListNode<out T>(dynamic x);

And this is the creation and definition of list node:

CreateListNode := λv.λn.λx.λf.f (n x f) v
ListNode := λx.λf.f (n x f) v

In C#:

public static partial class ChurchAggregateList<T>
{
    public static readonly Func<T, Func<AggregateListNode<T>, AggregateListNode<T>>>
        Create = value => next => x => f => f(next(x)(f))(value);
}

Similarly, here variable v is the value of current node, variable n is the next node of the current node. And variable x is the seed for aggregation, variable f is the accumulator function. The list is still modeled as a linked list, so Null is also needed to represent the end of list:

Null := λx.λf.x

Null is defined to call f for 0 times. For example, to create a linked list { 2, 1, 0 }, first create the last list node, with value 2 and Null as its next node:

  CreateListNode 0 Null
≡ (λv.λn.λx.λf.f (n x f) v) 0 (λx.λf.x)
≡ (λn.λx.λf.f (n x f) 0) (λx.λf.x)
≡ λx.λf.f ((λx.λf.x) x f) 0
≡ λx.λf.f x 0

Then the previous node can be created with value 1 and the above node:

  CreateListNode 1 (CreateListNode 0 Null)
≡ CreateListNode 1 (λx.λf.f x 0)
≡ (λv.λn.λx.λf.f (n x f) v) 1 (λx.λf.f x 0)
≡ (λn.λx.λf.f (n x f) 1) (λx.λf.f x 0)
≡ λx.λf.f ((λx.λf.f x 0) x f) 1
≡ λx.λf.f (f x 0) 1

And the first node has value 0:

  CreateListNode 2 (CreateListNode 1 (CreateListNode 0 Null))
≡ CreateListNode 2 (λx.λf.f (f x 0) 1)
≡ (λv.λn.λx.λf.f (n x f) v) 2 (λx.λf.f (f x 0) 1)
≡ (λn.λx.λf.f (n x f) 2) (λx.λf.f (f x 0) 1)
≡ λx.λf.f (λx.λf.f (f x 0) 1) x f) 2
≡ λx.λf.f (f (f x 0) 1) 2

So the list nodes are represented in the same pattern as LINQ aggregation.

The IsNull predicate can be defined as following:

IsNull := λl.l True (λx.λv.False)

The variable l is the list node, which is an aggregate function, and is applied with seed True and accumulate function λv.λx.False. When IsNull is applied with a null node, the accumulate function is not applied, and seed True is directly returned:

  IsNull Null
≡ (λl.l True (λx.λv.False)) (λx.λf.x)
≡ (λx.λf.x) True (λx.λv.False)
≡ (λf.True) (λx.λv.False)
≡ True

And when IsNull is applied with a non null node, the accumulator function is applied and constantly returns False, so IsNull returns False:

  IsNull (CreateListNode 2 Null)
≡ IsNull (λx.λf.f x 2)
≡ (λl.l True (λx.λv.False)) (λx.λf.f x 2)
≡ (λx.λf.f x 2) True (λx.λv.False)
≡ (λf.f True 2) (λx.λv.False)
≡ (λx.λv.False) True 2
≡ False

In C#:

using static ChurchBoolean;

public static partial class ChurchAggregateList<T>
{
    public static readonly AggregateListNode<T>
        Null = x => f => x;

    public static readonly Func<AggregateListNode<T>, Boolean>
        IsNull = node => node(True)(x => value => False);
}

The following function returns the value from the specified node:

Value := λl.l Id (λx.λv.v)

When Value is applied with a node, which has value v and next node n:

  Value (CreateListNode v n)
≡ Value (λx.λf.f (n x f) v)
≡ (λl.l Id (λx.λv.v)) (λx.λf.f (n x f) v)
≡ (λx.λf.f (n x f) v) Id (λx.λv.v)
≡ (λf.f (n Id f) v) (λx.λv.v)
≡ (λx.λv.v) (n Id f) v
≡ (λv.v) v
≡ v

In C#:

// Value = node => node(Id)(x => value => value)
public static readonly Func<AggregateListNode<T>, T>
    Value = node => node(Functions<T>.Id)(x => value => value);

It is not very intuitive to get a node’s next node:

Next := λl.λx.λf.l (λf.x) (λx.λv.λg.g (x f) v) (λx.λv.v)

In C#:

// Next = node => x => f => node(_ => x)(accumulate => value => (g => g(accumulate(f))(value)))(accumulate => value => accumulate);
public static readonly Func<AggregateListNode<T>, AggregateListNode<T>>
    Next = node => x => f => node(new Func<Func<dynamic, Func<T, dynamic>>, dynamic>(_ => x))(accumulate => value => new Func<Func<dynamic, Func<T, dynamic>>, dynamic>(g => g(accumulate(f))(value)))(new Func<dynamic, Func<T, dynamic>>(accumulate => value => accumulate));

The above definition is similar to the the pattern of initial version Subtract function for Church numeral. So it can be defined by shifting tuple too. Again, list node with value v and next node n is a aggregate function, it can be applied with a tuple of Null nodes as seed, and a accumulator function to swap the tuple:

  (CreateListNode v n) (Null, Null) (λt.λv.Shift (CreateListNode v) t)
≡ (λx.λf.f (n x f) v) (Null, Null) (λt.λv.Shift (CreateListNode v) t)
≡ (λf.f (n (Null, Null) f) v) (λt.λv.Shift (CreateListNode v) t)
≡ (λt.λv.Shift (CreateListNode v) t) (n (Null, Null) (λt.λv.Shift (CreateListNode v)) t) v
≡ (λv.Shift (CreateListNode v) (n (Null, Null) (λt.λv.Shift (CreateListNode v)) t)) v
≡ Shift (CreateListNode v) (n (Null, Null) (λt.λv.Shift (CreateListNode v)) t)

Take list { n, n – 1, …, 2, 1, 0 } as example, assume its nodes are ListNode_n, ListNode_{n - 1}, …, ListNode₂, ListNode₁, ListNode₀:

the last node is: CreateListNode 0 Null
the second last node is: CreateListNode 1 (CreateListNode 0 Null)
the third last node is: CreateListNode 2 (CreateListNode 1 (CreateListNode 0 Null))
…

Now apply these nodes with above tuple seed and tuple shifting accumulator function:

  ListNode₀ (Null, Null) (λt.λv.Shift (CreateListNode v) t)
≡ (CreateListNode 0 Null) (Null, Null) (λt.λv.Shift (CreateListNode v) t)
≡ Shift (CreateListNode 0) (Null (Null, Null) (λt.λv.Shift (CreateListNode v)) t)
≡ Shift (CreateListNode 0) ((λx.λf.λx) (Null, Null) (λt.λv.Shift (CreateListNode v)) t)
≡ Shift (CreateListNode 0) (Null, Null)
≡ (Null, CreateListNode 0 Null)
≡ (Null, ListNode₀)

  ListNode₁ (Null, Null) (λt.λv.Shift (CreateListNode v) t)
≡ (CreateListNode 1 (CreateListNode 0 Null)) (Null, Null) (λt.λv.Shift (CreateListNode v) t)
≡ Shift (CreateListNode 1) ((CreateListNode 0 Null) (Null, Null) (λt.λv.Shift (CreateListNode v)) t)
≡ Shift (CreateListNode 1) (Null, Create ListNode 0 Null)
≡ (CreateListNode 0 Null, (CreateListNode 1 (CreateListNode 0 Null))
≡ (ListNode₀, ListNode₁)

  ListNode₂ (Null, Null) (λt.λv.Shift (CreateListNode v) t)
≡ (CreateListNode 2 (CreateListNode 1 (CreateListNode 0 Null))) (Null, Null) (λt.λv.Shift (CreateListNode v) t)
≡ Shift (CreateListNode 2) ((CreateListNode 1 (CreateListNode 0 Null)) (Null, Null) (λt.λv.Shift (CreateListNode v)) t)
≡ Shift (CreateListNode 2) (CreateListNode 0 Null, (CreateListNode 1 (CreateListNode 0 Null))
≡ ((CreateListNode 1 (CreateListNode 0 Null), CreateListNode 2 (CreateListNode 1 (CreateListNode 0 Null)))
≡ (ListNode₁, ListNode₂)

...

  ListNode_n (Null, Null) (λt.λv.Shift (CreateListNode v) t)
≡ (ListNode_{n - 1}, ListNode_n)

Generally, there is:

  (CreateListNode v n) (Null, Null) (λt.λv.Shift (CreateListNode v) t)
≡ (n, Create v n)

So Next can be defined as:

Next := λl.Item2 (l (CreateTuple Null Null) (λt.λv.Shift (CreateListNode v) t))

In C#:

// Next = node => node((Null, Null))(tuple => value => tuple.Shift(ChurchTuple.Create(value))).Item1()
public static readonly Func<AggregateListNode<T>, AggregateListNode<T>>
    Next = node =>
        ((Tuple<AggregateListNode<T>, AggregateListNode<T>>)node
            (ChurchTuple<AggregateListNode<T>, AggregateListNode<T>>.Create(Null)(Null))
            (tuple => value => ((Tuple<AggregateListNode<T>, AggregateListNode<T>>)tuple).Shift(Create(value))))
        .Item1();

The indexer can be defined the same as above:

ListNodeAt := λl.λi.i Next l

In C#;

public static readonly Func<AggregateListNode<T>, Func<Numeral, AggregateListNode<T>>>
    ListNodeAt = start => index => index(node => Next(node))(start);

The following are the extension methods wrapping the list operators:

public static class AggregateListNodeExtensions
{
    public static Boolean IsNull<T>(this AggregateListNode<T> node) => ChurchAggregateList<T>.IsNull(node);

    public static T Value<T>(this AggregateListNode<T> node) => ChurchAggregateList<T>.Value(node);

    public static AggregateListNode<T> Next<T>(this AggregateListNode<T> node) => 
        ChurchAggregateList<T>.Next(node);

    public static AggregateListNode<T> ListNodeAt<T>(this AggregateListNode<T> start, Numeral index) => 
        ChurchAggregateList<T>.ListNodeAt(start)(index);
}

And the following code demonstrate how the list works:

[TestClass]
public class ChurchAggregateListTests
{
    [TestMethod]
    public void CreateValueNextTest()
    {
        AggregateListNode<int> node1 = ChurchAggregateList<int>.Create(1)(ChurchAggregateList<int>.Null);
        AggregateListNode<int> node2 = ChurchAggregateList<int>.Create(2)(node1);
        AggregateListNode<int> node3 = ChurchAggregateList<int>.Create(3)(node2);
        Assert.AreEqual(1, node1.Value());
        Assert.IsTrue(node1.Next().IsNull().Unchurch());
        Assert.AreEqual(2, node2.Value());
        Assert.AreEqual(node1.Value(), node2.Next().Value());
        Assert.AreEqual(3, node3.Value());
        Assert.AreEqual(node2.Value(), node3.Next().Value());
        Assert.AreEqual(node1.Value(), node3.Next().Next().Value());
        Assert.IsTrue(node3.Next().Next().Next().IsNull().Unchurch());
    }

    [TestMethod]
    public void IsNullTest()
    {
        AggregateListNode<int> node1 = ChurchAggregateList<int>.Create(1)(ChurchAggregateList<int>.Null);
        AggregateListNode<int> node2 = ChurchAggregateList<int>.Create(2)(node1);
        AggregateListNode<int> node3 = ChurchAggregateList<int>.Create(3)(node2);
        Assert.IsTrue(ChurchAggregateList<int>.Null.IsNull().Unchurch());
        Assert.IsFalse(node1.IsNull().Unchurch());
        Assert.IsFalse(node2.IsNull().Unchurch());
        Assert.IsFalse(node3.IsNull().Unchurch());
        Assert.IsTrue(node1.Next().IsNull().Unchurch());
        Assert.IsFalse(node2.Next().IsNull().Unchurch());
        Assert.IsFalse(node3.Next().IsNull().Unchurch());
    }

    [TestMethod]
    public void IndexTest()
    {
        AggregateListNode<int> node1 = ChurchAggregateList<int>.Create(1)(ChurchAggregateList<int>.Null);
        AggregateListNode<int> node2 = ChurchAggregateList<int>.Create(2)(node1);
        AggregateListNode<int> node3 = ChurchAggregateList<int>.Create(3)(node2);
        Assert.AreEqual(node3.Value(), node3.NodeAt(0U.Church()).Value());
        Assert.AreEqual(node2.Value(), node3.NodeAt(1U.Church()).Value());
        Assert.AreEqual(node1.Value(), node3.NodeAt(2U.Church()).Value());
        Assert.IsTrue(node3.NodeAt(3U.Church()).IsNull().Unchurch());
    }
}

Model everything

Once again, in lambda calculus the only primitive is anonymous function. So far many data types and operations are modeled by anonymous functions, including Boolean, unsigned and signed numeral, tuple, list, logic, arithmetic (except division, which will be implemented later), predicate, etc. With these facilities, many other data types and operations can be modeled too. For example:

Floating point number can be represented in the form of significand * base^exponent. In IEEE 754 (aka IEC 60559), floating point numbers are represented as binary format (sign) significand * 2^exponent (System.Single and System.Double in .NET), and decimal format (sign) significand * 10^exponent (System.Decimal). So either representation can be modeled with a 3-tuple of (Boolean, unsigned numeral, signed numeral).
Character (System.Char in .NET) can be represented by unsigned numeral.
String (System.String in .NET) can be modeled by a list of characters.
Tuple and list can represent other data structures, like tree, stack, queue, etc.
…

And eventually everything can be modeled with anonymous function represented by lambda expression. Actually, lambda calculus is a classic example of Turing completeness. Lambda calculus is introduced by Alonzo Church before Turing machine was introduced by Alan Turing, and they are equivalent. Lambda calculus, as a universal model of computation, is the rationale and foundations of functional programming. Functional languages (or the functional subset of languages) can be viewed as lambda calculus with more specific syntax, and the execution of functional program can be viewed as reduction of lambda calculus expression.

Lambda Calculus via C# (4) Tuple and Signed Numeral

Sun, 10 Nov 2024 13:05:00 GMT

[FP & LINQ via C# series]

[Lambda Calculus via C# series]

Besides modeling values like Boolean and numeral, anonymous function can also model data structures. In Church encoding, Church pair is an approach to use functions to represent a tuple of 2 items.

Church pair (2-tuple)

A tuple can be constructed with its first item x, its second item y, and a function f:

CreateTuple := λx.λy.λf.f x y

So a tuple is can be created by partially applying CreateTuple with 2 items x and y:

Tuple := CreateTuple x y
       ≡ (λx.λy.λf.f x y) x y
       ≡ λf.f x y

So a tuple is a higher-order function, which accept a function f, and apply it with its 2 items. So f accepts 2 arguments, it is in the form of λx.λy.E.

To get the tuple’s first item x, just apply the tuple function with a specific function f, where f simply accepts 2 items and returns the first item:

  Tuple (λx.λy.x)
≡ (λf.f x y) (λx.λy.x)
≡ (λx.λy.x) x y
≡ x

Similarly, to get the tuple’s second item y, just apply tuple function with a specific function f, where f simply accepts 2 items and returns the first item:

  Tuple (λx.λy.y)
≡ (λf.f x y) (λx.λy.y)
≡ (λx.λy.y) x y
≡ y

So the following Item1 function is defined to accept a tuple, apply the tuple function with function λx.λy.x, and return the tuple’s first item:

Item1 := λt.t (λx.λy.x)

Again, this is how it works:

  Item1 (CreateTuple x y)
≡ (λt.t (λx.λy.x)) (CreateTuple x y)
≡ (λt.t (λx.λy.x)) (λf.f x y)
≡ (λf.f x y) (λx.λy.x)
≡ (λx.λy.x) x y
≡ x

And Item2 function can ne defined in the same way to get the tuple’s second item:

Item2 := λt.t (λx.λy.y)

Notice functions λx.λy.x and λx.λy.y can be alpha converted to λt.λf.t and λt.λf.f, which are just Church Boolean True and False. So Item1 and Item2 can be defined as:

Item1 := λt.t True
Item2 := λt.t False

To implement tuple in C#, its function type needs to be identified. The tuple function accepts argument f, which is either function True of function False, so f is of function type Boolean. In the body of tuple function, f is applied, and f returns dynamic. So tuple virtually is of function type Boolean -> dynamic:

using static ChurchBoolean;

// Tuple is the alias of (dynamic -> dynamic -> dynamic) -> dynamic.
public delegate dynamic Tuple<out T1, out T2>(Boolean f);

public static partial class ChurchTuple<T1, T2>
{
    public static readonly Func<T1, Func<T2, Tuple<T1, T2>>> 
        Create = item1 => item2 => f => f(item1)(item2);

    // Item1 = tuple => tuple(True)
    public static readonly Func<Tuple<T1, T2>, T1> 
        Item1 = tuple => (T1)(object)tuple(True);

    // Item2 = tuple => tuple(False)
    public static readonly Func<Tuple<T1, T2>, T2> 
        Item2 = tuple => (T2)(object)tuple(False);
}

There are type conversions in Item1/Item2 functions. At compiled time, the tuple function returns dynamic, and at runtime it actually it calls True/False function to return either item1 or item2 . So the type conversions are always safe. Also notice here tuple function’s return value cannot be directly converted to T1 or T2, because of a bug of C# runtime binding layer. The workaround is to convert dynamic to object first, then convert to T1 or T2.

The following are the extension methods for convenience:

public static partial class TupleExtensions
{
    public static T1 Item1<T1, T2>(this Tuple<T1, T2> tuple) => ChurchTuple<T1, T2>.Item1(tuple);

    public static T2 Item2<T1, T2>(this Tuple<T1, T2> tuple) => ChurchTuple<T1, T2>.Item2(tuple);
}

For example, a point can be a tuple of 2 numerals:

internal static void Point(Numeral x, Numeral y)
{
    Tuple<Numeral, Numeral> point1 = ChurchTuple<Numeral, Numeral>.Create(x)(y);
    Numeral x1 = point1.Item1();
    Numeral y1 = point1.Item1();

    // Move up.
    Numeral y2 = y1.Increase();
    Tuple<Numeral, Numeral> point2 = ChurchTuple<Numeral, Numeral>.Create(x1)(y2);
}

Tuple operators

The Swap function accepts a tuple (x, y), swaps its first item and second item, and returns a new tuple (y, x):

Swap := λt.CreateTuple (Item2 t)(Item1 t)

Apparently, Swap is of function type Tuple<T1, T2> -> Tuple<T2, T1>:

// Swap = tuple => Create(tuple.Item2())(tuple.Item1())
public static readonly Func<Tuple<T1, T2>, Tuple<T2, T1>>
    Swap = tuple => ChurchTuple<T2, T1>.Create(tuple.Item2())(tuple.Item1());

The Shift function accepts a tuple (x, y) and a function f, and returns a new tuple (y, f y):

Shift := λf.λt.CreateTuple (Item2 t) (f (Item2 t))

Here assume the argument tuple (x, y) is of type Tuple<T1, T2>, regarding f is applied with y, assume f returns TResult type, then f is of function type T2 -> TResult, so that the returned new tuple (y, f y) is of type Tuple<T2, TResult>. As a result, Shift is of type Tuple<T1, T2> -> (T2 -> TResult) -> Tuple<T2, TResult>:

public static partial class ChurchTuple<T1, T2, TResult>
{
    // Shift = f => tuple => Create(tuple.Item2())(f(tuple.Item1()))
    public static readonly Func<Func<T2, TResult>, Func<Tuple<T1, T2>, Tuple<T2, TResult>>>
        Shift = f => tuple => ChurchTuple<T2, TResult>.Create(tuple.Item2())(f(tuple.Item2()));
}

And their extension methods:

public static Tuple<T2, T1> Swap<T1, T2>(this Tuple<T1, T2> tuple) => ChurchTuple<T1, T2>.Swap(tuple);

public static Tuple<T2, TResult> Shift<T1, T2, TResult>(this Tuple<T1, T2> tuple, Func<T2, TResult> f) => 
    ChurchTuple<T1, T2, TResult>.Shift(f)(tuple);

Here Shift function can be used to define the Subtract function for Church numerals. Remember a Church numeral n can be viewed as to apply Increase n times from 0:

  n Increase 0
≡ n

Applying Shift with Increase and a tuple of Church numerals, it returns a new tuple of Church numerals, so this application can repeat forever:

  Shift Increase (0, 0)
≡ (0, Increase 0)
≡ (0, 1)

  Shift Increase (0, 1)
≡ (1, Increase 1)
≡ (1, 2)

  Shift Increase (1, 2)
≡ (2, Increase 2)
≡ (2, 3)

...

In another word, partially applying Shift with Increase is a function that can be repeatedly applied with a tuple of Church numerals:

  (Shift Increase) (0, 0)                                       ≡ (Shift Increase)¹ (0, 0) ≡ 1 (Shift Increase) (0, 0) 
≡ (0, 1)

  (Shift Increase) (0, 1)
≡ (Shift Increase) ((Shift Increase) (0, 0))
≡ (Shift Increase) ∘ (Shift Increase) (0, 0)                    ≡ (Shift Increase)² (0, 0) ≡ 2 (Shift Increase) (0, 0) 
≡ (1, 2)

  (Shift Increase) (1, 2)
≡ (Shift Increase) ((Shift Increase) ∘ (Shift Increase) (0, 0))
≡ (Shift Increase) ∘ (Shift Increase) ∘ (Shift Increase) (0, 0) ≡ (Shift Increase)³ (0, 0) ≡ 3 (Shift Increase) (0, 0) 
≡ (2, 3)

...

So generally:

  n (Shift Increase) (0, 0)
≡ (n - 1, n)

As a result, to decrease n to n – 1, just apply n with function (Shift Increase) and tuple (0, 0), get the result tuple (n – 1, n), and return its first item:

  Item1 (n (Shift Increase) (0, 0))
≡ Item1 (n - 1, n)
≡ n - 1

So Decrease can be defined as:

Decrease := λn.Item1 (n (Shift Increase) (CreateTuple 0 0))

And C#:

// Decrease = n => n(tuple => tuple.Shift(Increase))(0, 0).Item1();
public static readonly Func<Numeral, Numeral> Decrease = n =>
    ((Tuple<Numeral, Numeral>)n
        (tuple => ((Tuple<Numeral, Numeral>)tuple).Shift(Increase))
        (ChurchTuple<Numeral, Numeral>.Create(Zero)(Zero)))
    .Item1();

N-tuple

An easy way is to model n-tuple as a 2-tuple of the first value and a (n-1)-tuple of the rest values. A 3 tuple of values 1, 2, 3 can be represented by nested 2-tuples as (a, (b, c)), a 4-tuple of values 1, 2, 3, 4 can be represented by nested 2-tuples (1, (2, (3, 4))), etc., and a n tuple of values 1, 2, 3, …, n can be represented by nested 2 tuples (1, (2, (3, (…(n-1, n)…)))). For example, the following is the definition of 3 tuple:

Create3Tuple := λx.λy.λz.CreateTuple x (CreateTuple y z)

3TupleItem1 := λt.Item1 t
3TupleItem2 := λt.Item1 (Item2 t)
3TupleItem3 := λt.Item2 (Item2 t)

And in C#:

public delegate dynamic Tuple<out T1, out T2, out T3>(Boolean f);

public static partial class ChurchTuple<T1, T2, T3>
{
    // Create = item1 => item2 => item3 => Create(item1)(Create(item2)(item3))
    public static readonly Func<T1, Func<T2, Func<T3, Tuple<T1, T2, T3>>>>
        Create = item1 => item2 => item3 => new Tuple<T1, T2, T3>(ChurchTuple<T1, Tuple<T2, T3>>.Create(item1)(ChurchTuple<T2, T3>.Create(item2)(item3)));

    // Item1 = tuple.Item1()
    public static readonly Func<Tuple<T1, T2, T3>, T1>
        Item1 = tuple => new Tuple<T1, Tuple<T2, T3>>(tuple).Item1();

    // Item2 = tuple.Item2().Item1()
    public static readonly Func<Tuple<T1, T2, T3>, T2>
        Item2 = tuple => new Tuple<T1, Tuple<T2, T3>>(tuple).Item2().Item1();

    // Item3 = tuple.Item2().Item2()
    public static readonly Func<Tuple<T1, T2, T3>, T3>
        Item3 = tuple => new Tuple<T1, Tuple<T2, T3>>(tuple).Item2().Item2();
}

public static partial class TupleExtensions
{
    public static T1 Item1<T1, T2, T3>(this Tuple<T1, T2, T3> tuple) => ChurchTuple<T1, T2, T3>.Item1(tuple);

    public static T2 Item2<T1, T2, T3>(this Tuple<T1, T2, T3> tuple) => ChurchTuple<T1, T2, T3>.Item2(tuple);

    public static T3 Item3<T1, T2, T3>(this Tuple<T1, T2, T3> tuple) => ChurchTuple<T1, T2, T3>.Item3(tuple);
}

Signed numeral

With tuple, a signed numeral (integer) can be modeled by a pair of Church numerals (natural numbers), where the first item represents the positive value, and the second item represents the negative value:

SignedNumeral := Tuple

For example (1, 0) and (2, 1) models 1, (0, 2) and (1, 3) models –2, (0, 0) and (1, 1) models 0, etc.:

 1 := (1, 0) ≡ (2, 1) ≡ (3, 2) ≡ (4, 3) ≡ ...
 0 := (0, 0) ≡ (1, 1) ≡ (2, 2) ≡ (3, 3) ≡ ...
-2 := (0, 2) ≡ (1, 3) ≡ (2, 4) ≡ (3, 5) ≡ ...

In C#, the function type SignedNumeral is the same as Tuple, except SignedNumeral is not open generic type:

// SignedNumeral is the alias of Tuple<Numeral, Numeral>.
public delegate dynamic SignedNumeral(Boolean f);

Church numeral represents natural number. So Converting a Church numeral n to signed number is easy, just make it a tuple (n, 0):

Sign := λn.CreateTuple n 0

To negate a signed numeral, just swap its positive value and negative value:

Negate := Swap

And it is straightforward to get the positive value and the negative value from a signed number:

Positive := Item1
Negative := Item2

Signed numeral like (4, 3), (3, 3), (3, 5) can be formatted to have at least one 0: (1, 0), (0, 0), (0, 2). For a signed number s represented by (p, n), If p >= n, then it is (p - n, 0), otherwise it is (0, n – p):

Format := λs.If (s_p >=  s_n) (λx.(s_p - s_n, 0)) (λx.(0, s_n - s_p))

Here S_p is the positive value of s, and s_n the the negative value of s.

The following are these function’s C# implementation, and the extension methods:

using static ChurchBoolean;
using static ChurchNumeral;

public static partial class ChurchSignedNumeral
{
    // Sign = n => (n, 0)
    public static readonly Func<Numeral, SignedNumeral>
        Sign = n => new SignedNumeral(ChurchTuple<Numeral, Numeral>.Create(n)(Zero));

    // Negate = signed => signed.Swap()
    public static readonly Func<SignedNumeral, SignedNumeral>
        Negate = signed => new SignedNumeral(new Tuple<Numeral, Numeral>(signed).Swap());

    // Positive = signed => signed.Item1()
    public static readonly Func<SignedNumeral, Numeral>
        Positive = signed => new Tuple<Numeral, Numeral>(signed).Item1();

    // Negative = signed => signed.Item2()
    public static readonly Func<SignedNumeral, Numeral>
        Negative = signed => new Tuple<Numeral, Numeral>(signed).Item2();

    // Format = signed =>
    //    If(positive >= negative)
    //        (_ => (positive - negative, 0))
    //        (_ => (0, negative - positive))
    public static readonly Func<SignedNumeral, SignedNumeral>
        Format = signed =>
            If(signed.Positive().IsGreaterThanOrEqualTo(signed.Negative()))
                (_ => signed.Positive().Subtract(signed.Negative()).Sign())
                (_ => signed.Negative().Subtract(signed.Positive()).Sign().Negate());
}

public static partial class SignedNumeralExtensions
{
    public static SignedNumeral Sign(this Numeral n) => ChurchSignedNumeral.Sign(n);

    public static SignedNumeral Negate(this SignedNumeral signed) => ChurchSignedNumeral.Negate(signed);

    public static Numeral Positive(this SignedNumeral signed) => ChurchSignedNumeral.Positive(signed);

    public static Numeral Negative(this SignedNumeral signed) => ChurchSignedNumeral.Negative(signed);

    public static SignedNumeral Format(this SignedNumeral signed) => ChurchSignedNumeral.Format(signed);
}

Arithmetic operators

Naturally, for signed numbers a, b:

  a + b
≡ (a_p, a_n) + (b_p, b_n)
≡ (a_p - a_n) + (b_p - b_n)
≡ (a_p + b_p, a_n + b_n)

  a - b
≡ (a_p, a_n) - (b_p, b_n)
≡ (a_p - a_n) - (b_p - b_n)
≡ (a_p + b_n, a_n + b_p)

  a * b
≡ (a_p, a_n) * (b_p, b_n)
≡ (a_p - a_n) * (b_p - b_n)
≡ (a_p * b_p + a_n * b_n, a_p * b_n + a_n * b_p)

  a / b
≡ (a_p, a_n) / (b_p, b_n)
≡ (a_p - a_n) / (b_p - b_n)
≡ (a_p / b_p + a_n / b_n, a_p / b_n + a_n / b_p)

So in lambda calculus:

AddSigned := λa.λb.Format (CreateTuple (a_p + b_p) (a_n + b_n))
SubtractSigned := λa.λb.Format (CreateTuple (a_p + b_n) (a_n + b_p))
MultiplySigned := λa.λb.Format (CreateTuple (a_p * b_p + a_n * b_n) (a_p * b_n + a_n * b_p))

Division is more tricky because a and b’s positive and negative values can be 0. In this case, just return 0 when dividing by 0:

DivideByIgnoreZero := λa.λb.If (IsZero b) (λx.0) (λx.DivideBy a b)

Here the DivideBy function for Church numeral is used. As fore mentioned, this DivideBy function is not well defined. It is temporarily used here and will be revisited later. So division can be defined as:

DivideBySigned := λa.λb.Format (CreateTuple ((DivideByIgnoreZero a_p b_p) + (DivideByIgnoreZero a_n b_n)) ((DivideByIgnoreZero a_p b_n) + (DivideByIgnoreZero a_n b_p)))

The following are the C# implementations and the extension methods:

public static partial class ChurchSignedNumeral
{
    // Add = a => b => (a.Positive() + b.Positive(), a.Negative() + b.Negative()).Format()
    public static readonly Func<SignedNumeral, Func<SignedNumeral, SignedNumeral>>
        Add = a => b => new SignedNumeral(ChurchTuple<Numeral, Numeral>.Create
                (a.Positive().Add(b.Positive()))
                (a.Negative().Add(b.Negative())))
            .Format();

    // Subtract = a => b => (a.Positive() + b.Negative(), a.Negative() + b.Positive()).Format()
    public static readonly Func<SignedNumeral, Func<SignedNumeral, SignedNumeral>>
        Subtract = a => b => new SignedNumeral(ChurchTuple<Numeral, Numeral>.Create
                (a.Positive().Add(b.Negative()))
                (a.Negative().Add(b.Positive())))
            .Format();

    // Multiply = a => b => (a.Positive() * b.Positive() + a.Negative() * b.Negative(), a.Positive() * b.Negative() + a.Negative() * b.Positive()).Format()
    public static readonly Func<SignedNumeral, Func<SignedNumeral, SignedNumeral>>
        Multiply = a => b => new SignedNumeral(ChurchTuple<Numeral, Numeral>.Create
                (a.Positive().Multiply(b.Positive()).Add(a.Negative().Multiply(b.Negative())))
                (a.Positive().Multiply(b.Negative()).Add(a.Negative().Multiply(b.Positive()))))
            .Format();

    // / = dividend => divisor => If(divisor.IsZero())(_ => 0)(_ => dividend.DivideBy(divisor))
    private static readonly Func<Numeral, Func<Numeral, Numeral>> 
        DivideByIgnoreZero = dividend => divisor =>
            ChurchBoolean<Numeral>.If(divisor.IsZero())
                (_ => Zero)
                (_ => dividend.DivideBy(divisor));

    // DivideBy = dividend => divisor => (dividend.Positive() / divisor.Positive() + dividend.Negative() / divisor.Negative(), dividend.Positive() / divisor.Negative() + dividend.Negative() / divisor.Positive()).Format();
    public static readonly Func<SignedNumeral, Func<SignedNumeral, SignedNumeral>>
        DivideBy = dividend => divisor => new SignedNumeral(ChurchTuple<Numeral, Numeral>.Create
                (DivideByIgnoreZero(dividend.Positive())(divisor.Positive()).Add(DivideByIgnoreZero(dividend.Negative())(divisor.Negative())))
                (DivideByIgnoreZero(dividend.Positive())(divisor.Negative()).Add(DivideByIgnoreZero(dividend.Negative())(divisor.Positive()))))
            .Format();
}

public static partial class SignedNumeralExtensions
{
    public static SignedNumeral Add(this SignedNumeral a, SignedNumeral b) => ChurchSignedNumeral.Add(a)(b);

    public static SignedNumeral Subtract(this SignedNumeral a, SignedNumeral b) => ChurchSignedNumeral.Subtract(a)(b);

    public static SignedNumeral Multiply(this SignedNumeral a, SignedNumeral b) => ChurchSignedNumeral.Multiply(a)(b);

    public static SignedNumeral DivideBy(this SignedNumeral dividend, SignedNumeral divisor) => ChurchSignedNumeral.DivideBy(dividend)(divisor);
}

And the following code demonstrate how these operators work:

[TestClass]
public class ChurchSignedNumeralTests
{
    [TestMethod]
    public void SignNegatePositiveNegativeTest()
    {
        SignedNumeral signed = 0U.Church().Sign();
        Assert.IsTrue(0U == signed.Positive().Unchurch());
        Assert.IsTrue(0U == signed.Negative().Unchurch());
        signed = signed.Negate();
        Assert.IsTrue(0U == signed.Positive().Unchurch());
        Assert.IsTrue(0U == signed.Negative().Unchurch());

        signed = 1U.Church().Sign();
        Assert.IsTrue(1U == signed.Positive().Unchurch());
        Assert.IsTrue(0U == signed.Negative().Unchurch());
        signed = signed.Negate();
        Assert.IsTrue(0U == signed.Positive().Unchurch());
        Assert.IsTrue(1U == signed.Negative().Unchurch());

        signed = 2U.Church().Sign();
        Assert.IsTrue(2U == signed.Positive().Unchurch());
        Assert.IsTrue(0U == signed.Negative().Unchurch());
        signed = signed.Negate();
        Assert.IsTrue(0U == signed.Positive().Unchurch());
        Assert.IsTrue(2U == signed.Negative().Unchurch());

        signed = 123U.Church().Sign();
        Assert.IsTrue(123U == signed.Positive().Unchurch());
        Assert.IsTrue(0U == signed.Negative().Unchurch());
        signed = signed.Negate();
        Assert.IsTrue(0U == signed.Positive().Unchurch());
        Assert.IsTrue(123U == signed.Negative().Unchurch());

        signed = new SignedNumeral(ChurchTuple<Numeral, Numeral>.Create(12U.Church())(23U.Church()));
        Assert.IsTrue(12U == signed.Positive().Unchurch());
        Assert.IsTrue(23U == signed.Negative().Unchurch());
        signed = signed.Negate();
        Assert.IsTrue(23U == signed.Positive().Unchurch());
        Assert.IsTrue(12U == signed.Negative().Unchurch());
    }

    [TestMethod]
    public void FormatWithZeroTest()
    {
        SignedNumeral signed = new SignedNumeral(ChurchTuple<Numeral, Numeral>.Create(12U.Church())(23U.Church()));
        signed = signed.Format();
        Assert.IsTrue(0U == signed.Positive().Unchurch());
        Assert.IsTrue(11U == signed.Negative().Unchurch());

        signed = new SignedNumeral(ChurchTuple<Numeral, Numeral>.Create(23U.Church())(12U.Church()));
        signed = signed.Format();
        Assert.IsTrue(11U == signed.Positive().Unchurch());
        Assert.IsTrue(0U == signed.Negative().Unchurch());
    }

    [TestMethod]
    public void AddTest()
    {
        SignedNumeral a = 0U.Church().Sign();
        SignedNumeral b = 0U.Church().Sign();
        SignedNumeral result = a.Add(b);
        Assert.IsTrue(0U == result.Positive().Unchurch());
        Assert.IsTrue(0U == result.Negative().Unchurch());

        a = 1U.Church().Sign();
        b = 1U.Church().Sign().Negate();
        result = a.Add(b);
        Assert.IsTrue(0U == result.Positive().Unchurch());
        Assert.IsTrue(0U == result.Negative().Unchurch());

        a = 3U.Church().Sign();
        b = 5U.Church().Sign().Negate();
        result = a.Add(b);
        Assert.IsTrue(0U == result.Positive().Unchurch());
        Assert.IsTrue(2U == result.Negative().Unchurch());
    }

    [TestMethod]
    public void SubtractTest()
    {
        SignedNumeral a = 0U.Church().Sign();
        SignedNumeral b = 0U.Church().Sign();
        SignedNumeral result = a.Subtract(b);
        Assert.IsTrue(0U == result.Positive().Unchurch());
        Assert.IsTrue(0U == result.Negative().Unchurch());

        a = 1U.Church().Sign();
        b = 1U.Church().Sign().Negate();
        result = a.Subtract(b);
        Assert.IsTrue(2U == result.Positive().Unchurch());
        Assert.IsTrue(0U == result.Negative().Unchurch());

        a = 3U.Church().Sign();
        b = 5U.Church().Sign().Negate();
        result = a.Subtract(b);
        Assert.IsTrue(8U == result.Positive().Unchurch());
        Assert.IsTrue(0U == result.Negative().Unchurch());
    }

    [TestMethod]
    public void MultiplyTest()
    {
        SignedNumeral a = 0U.Church().Sign();
        SignedNumeral b = 0U.Church().Sign();
        SignedNumeral result = a.Multiply(b);
        Assert.IsTrue(0U == result.Positive().Unchurch());
        Assert.IsTrue(0U == result.Negative().Unchurch());

        a = 1U.Church().Sign();
        b = 1U.Church().Sign().Negate();
        result = a.Multiply(b);
        Assert.IsTrue(0U == result.Positive().Unchurch());
        Assert.IsTrue(1U == result.Negative().Unchurch());

        a = 3U.Church().Sign();
        b = 5U.Church().Sign().Negate();
        result = a.Multiply(b);
        Assert.IsTrue(0U == result.Positive().Unchurch());
        Assert.IsTrue(15U == result.Negative().Unchurch());
    }

    [TestMethod]
    public void DivideByTest()
    {
        SignedNumeral a = 0U.Church().Sign();
        SignedNumeral b = 0U.Church().Sign();
        SignedNumeral result = a.DivideBy(b);
        Assert.IsTrue(0U == result.Positive().Unchurch());
        Assert.IsTrue(0U == result.Negative().Unchurch());

        a = 1U.Church().Sign();
        b = 1U.Church().Sign().Negate();
        result = a.DivideBy(b);
        Assert.IsTrue(0U == result.Positive().Unchurch());
        Assert.IsTrue(1U == result.Negative().Unchurch());

        a = 11U.Church().Sign();
        b = 5U.Church().Sign().Negate();
        result = a.DivideBy(b);
        Assert.IsTrue(0U == result.Positive().Unchurch());
        Assert.IsTrue(2U == result.Negative().Unchurch());
    }
}

Lambda Calculus via C# (3) Numeral, Arithmetic and Predicate

Thu, 07 Nov 2024 13:05:00 GMT

[FP & LINQ via C# series]

[Lambda Calculus via C# series]

Anonymous functions can also model numerals and their arithmetic. In Church encoding, a natural number n is represented by a function that calls a given function for n times. This representation is called Church Numeral.

Church numerals

Church numerals are defined as:

0 := λfx.x                  ≡ λf.λx.x
1 := λfx.f x                ≡ λf.λx.f x
2 := λfx.f (f x)            ≡ λf.λx.f (f x)
3 := λfx.f (f (f x))        ≡ λf.λx.f (f (f x))
...
n := λfx.f (f ... (f x)...) ≡ λf.λx.f (f .u.. (f x)...)

So a Church numeral n is a higher order function, it accepts a function f and an argument x. When n is applied, it repeatedly applies f for n times by starting with x, and returns the result. If n is 0, f is not applied (in another word, f is applied 0 times), and x is directly returned.

0 f x ≡ x
1 f x ≡ f x
2 f x ≡ f (f x)
3 f x ≡ f (f (f x))
...
n f x ≡ f (f (... (f x)...))

According to the definition of function composition:

f (f x) ≡ (f ∘ f) x

This definition is equivalent to compose f for n time:

0 := λfx.x                  ≡ λf.λx.x                   ≡ λf.λx.f⁰ x
1 := λfx.f x                ≡ λf.λx.f x                 ≡ λf.λx.f¹ x
2 := λfx.f (f x)            ≡ λf.λx.(f ∘ f) x           ≡ λf.λx.f² x
3 := λfx.f (f (f x))        ≡ λf.λx.(f ∘ f ∘ f) x       ≡ λf.λx.f³ x
...
n := λfx.f (f ... (f x)...) ≡ λf.λx.(f ∘ f ∘ ... ∘ f) x ≡ λf.λx.fⁿ x

The partial application with f is the composition of f, so Church numeral n can be simply read as – do something n times:

0 f ≡ f⁰
1 f ≡ f¹
2 f ≡ f²
3 f ≡ f³
...
n f ≡ fⁿ

In C#, x can be anything, so leave its type as dynamic. f can be viewed as a function accept a value x and returns something, and f can also accept its returned value again, so f is of type dynamic -> dynamic. And n’ return type is the same as f’s return type, so n returns dynamic too. As a result, n can be virtually viewed as curried function type (dynamic -> dynamic) –> dynamic -> dynamic, which in C# is represented by Func<Func<dynamic, dynamic>, Func<dynamic, dynamic>>. Similar to the C# implementation of Church Boolean, a alias Numeral can be defined:

// Curried from (dynamic -> dynamic, dynamic) -> dynamic.
// Numeral is the alias of (dynamic -> dynamic) -> dynamic -> dynamic.
public delegate Func<dynamic, dynamic> Numeral(Func<dynamic, dynamic> f);

Based on the definition:

public static partial class ChurchNumeral
{
    public static readonly Numeral
        Zero = f => x => x;

    public static readonly Numeral
        One = f => x => f(x);

    public static readonly Numeral
        Two = f => x => f(f(x));

    public static readonly Numeral
        Three = f => x => f(f(f(x)));

    // ...
}

Also since n f ≡ fⁿ, n can be also implemented with composition of f:

public static readonly Numeral
    OneWithComposition = f => f;

// Two = f => f o f
public static readonly Numeral
    TwoWithComposition = f => f.o(f);

// Three = f => f o f o f
public static readonly Numeral
    ThreeWithComposition = f => f.o(f).o(f);

// ...

Here the o operator is the forward composition extension method defined previously. Actually, instead of defining each number individually, Church numeral can be defined recursively by increase or decrease.

Increase and decrease

By observing the definition and code, there are some patterns when the Church numeral increases from 0 to 3. In the definitions of Church numerals:

0 := λf.λx.x
1 := λf.λx.f (x)
2 := λf.λx.f (f x)
3 := λf.λx.f (f (f x))
...

The expressions in the parenthesis can be reduced from the following function applications expressions:

0 f x ≡ x
1 f x ≡ f x
2 f x ≡ f (f x)
...

With substitution, Church numerals’ definition become:

0 := λf.λx.x
1 := λf.λx.f (0 f x)
2 := λf.λx.f (1 f x)
3 := λf.λx.f (2 f x)
...

This shows how the the Church numerals increases. Generally, given a Church numeral n, the next numeral n + 1 is λf.λx.f (n f x). So:

Increase := λn.λf.λx.f (n f x)

In C#, this is:

public static Func<Numeral, Numeral> 
    Increase = n => f => x => f(n(f)(x));

In the other way, Church numeral n is to compose f for n times:

n f ≡ fⁿ

So increasing n means to compose f for one more time:

Increase := λn.λf.f ∘ fⁿ ≡ λn.λf.f ∘ (n f)

And in C#:

public static readonly Func<Numeral, Numeral> 
    IncreaseWithComposition = n => f => f.o(n(f));

To decrease a Church numeral n, when n is 0, the result is defined as 0, when n is positive, the result is n – 1. The Decrease function is more complex:

Decrease := λn.λf.λx.n (λg.λh.h (g f)) (λv.x) Id

When n is 0, regarding n f ≡ fⁿ, applying Decrease with 0 can be reduced as:

  Decrease 0
≡ λf.λx.0 (λg.λh.h (g f)) (λv.x) Id
≡ λf.λx.(λg.λh.h (g f))⁰ (λv.x) Id
≡ λf.λx.(λv.x) Id
≡ λf.λx.x
≡ λf.λx.f⁰ x

The last expression is the definition of 0.

When n is positive, regarding function function composition is associative, the expression n (λg.λh.h (g f)) (λu.x) can be reduced first. When n is 1, 2, 3, ...:

  1 (λg.λh.h (g f)) (λv.x)
≡ (λg.λh.h (g f))¹ (λv.x)
≡ (λg.λh.h (g f)) (λv.x)
≡ λh.h ((λv.x) f)
≡ λh.h x
≡ λh.h (f⁰ x) 

  2 (λg.λh.h (g f)) (λv.x)
≡ (λg.λh.h (g f))² (λv.x)
≡ (λg.λh.h (g f)) ∘ (λg.λh.h (g f))¹ (λv.x)
≡ (λg.λh.h (g f)) (λh.h (f⁰ x))
≡ λh.h (λh.h (f⁰ x) f)
≡ λh.h (f (f⁰ x))
≡ λh.h (f¹ x)

  3 (λg.λh.h (g f)) (λv.x)
≡ (λg.λh.h (g f))³ (λv.x)
≡ (λg.λh.h (g f)) ∘ (λg.λh.h (g f))² (λv.x)
≡ (λg.λh.h (g f)) (λh.h (f¹ x))
≡ λh.h ((λh.h (f¹ x)) f)
≡ λh.h (f (f¹ x))
≡ λh.h (f² x)

...

And generally:

  n (λg.λh.h (g f)) (λv.x)
≡ λh.h (f^{n - 1} x)

So when Decrease is applied with positive n:

  Decrease n
≡ λf.λx.n (λg.λh.h (g f)) (λv.x) Id
≡ λf.λx.(λh.h (f^{n - 1} x)) Id
≡ λf.λx.Id (f^{n - 1} x)
≡ λf.λx.f^{n - 1} x

The returned result is the definition of n – 1. In the following C# implementation, a lot of noise of type information is involved to implement complex lambda expression:

// Decrease = n => f => x => n(g => h => h(g(f)))(_ => x)(Id)
public static readonly Func<Numeral, Numeral> 
    Decrease = n => f => x => n(g => new Func<Func<dynamic, dynamic>, dynamic>(h => h(g(f))))(new Func<Func<dynamic, dynamic>, dynamic>(_ => x))(new Func<dynamic, dynamic>(Functions<dynamic>.Id));

Here are the actual types of the elements in above lambda expression at runtime:

g: (dynamic -> dynamic) -> dynamic
h: dynamic -> dynamic
g(f): dynamic
h(g(f)): dynamic
h => h(g(f)): (dynamic -> dynamic) -> dynamic
g => h => h(g(f)): ((dynamic -> dynamic) -> dynamic) -> (dynamic -> dynamic) -> dynamic
n(g => h => h(g(f))): ((dynamic -> dynamic) -> dynamic) -> (dynamic -> dynamic) -> dynamic
_ => x: (dynamic -> dynamic) -> dynamic
n(g => h => h(g(f)))(_ => x): (dynamic -> dynamic) -> dynamic
Id: dynamic -> dynamic
n(g => h => h(g(f)))(_ => x)(Id): dynamic

At compile time, function types must be provided for a few elements. When n is applied, C# compiler expects its first argument g => h => h(g(f)) to be of type dynamic => dynamic. So C# compiler infers g to dynamic, but cannot infer the type of h => h(g(f)), which can be expression tree or anonymous function, so the constructor call syntax is used here to specify it is a function of type (dynamic -> dynamic) -> dynamic. Similarly, C# compiler expects n’s second argument to be dynamic, and C# compiler cannot infer the type of _ => x, so the constructor syntax is used again for _ => x. Also, Functions<dynamic>.Id is of Unit<dynamic> type, while at runtime a dynamic -> dynamic function is expected. Unit<dynamic> is alias of function type dynamic –> dynamic, but the conversion does not happen automatically at runtime, so the constructor syntax is used once again to indicate the function type conversion.

Later after introducing Church pair, a cleaner version of Decrease will be implemented.

Arithmetic operators

To implement add operation, according to the definition, Church numeral a adding Church numeral b means to apply f for a times, then apply f again for b times:

Add := λa.λb.λf.λx.b f (a f x)

With the definition of function composition, Add can be also defined as:

Add := λa.λb.λf.f^a ∘ f^b ≡ λa.λb.λf.(a f) ∘ (b f)

So in C#:

public static readonly Func<Numeral, Func<Numeral, Numeral>>  
    Add = a => b => f => x => b(f)(a(f)(x));

public static readonly Func<Numeral, Func<Numeral, Numeral>> 
    AddWithComposition = a => b => f => a(f).o(b(f));

With Increase function, Add can also be defined as increase a for b times:

Add := λa.λb.b Increase a

In C#, there are some noise of type information again:

public static readonly Func<Numeral, Func<Numeral, Numeral>>
    AddWithIncrease = a => b => b(Increase)(a);

Unfortunately, the above code cannot be compiled, because b is a function of type (dynamic -> dynamic) -> dynamic x -> dynamic. So its first argument f must be a function of type dynamic -> dynamic. Here, Increase is of type Numeral -> Numeral, and b(Increase) cannot be compiled. The solution is to eta convert Increase to a wrapper function λn.Increase n:

Add := λa.λb.a (λn.Increase n) b

So that in C#:

// Add = a => b => b(Increase)(a)
// η conversion:
// Add = a => b => b(n => Increase(n))(a)
public static readonly Func<Numeral, Func<Numeral, Numeral>>
    AddWithIncrease = a => b => b(n => Increase(n))(a);

Since a dynamic -> dynamic function is expected and the wrapper function n => Increase(n), n inferred to be of type dynamic. Increase(n) still returns Numeral, so the wrapper function is of type dynamic -> Numeral. Regarding dynamic is just object, and Numeral derives from object, with support covariance in C#, the wrapper function is implicitly converted to dynamic -> dynamic, so calling b with the wrapper function can be compiled.

Similarly, Church numeral a subtracting b can be defined as decrease a for b times, a multiplying b can be defined as adding a for b times to 0, and raising a to the power b can be defined as multiplying a for n times with 1:

Subtract := λa.λb.b Decrease a
Multiply := λa.λb.b (Add a) 0
Power := λa.λb.b (Multiply a) 1

The C# implementation are in the same pattern:

// Subtract = a => b => b(Decrease)(a)
// η conversion:
// Subtract = a => b => b(n => Decrease(n))(a)
public static readonly Func<Numeral, Func<Numeral, Numeral>>
    Subtract = a => b => b(n => Decrease(n))(a);

// Multiply = a => b => b(Add(a))(a)
// η conversion:
// Multiply = a => b => b(n => Add(a)(n))(Zero)
public static readonly Func<Numeral, Func<Numeral, Numeral>>
    Multiply = a => b => b(n => Add(a)(n))(Zero);

// Pow = a => b => b(Multiply(a))(a)
// η conversion:
// Pow = a => b => b(n => Multiply(a)(n))(1)
public static readonly Func<Numeral, Func<Numeral, Numeral>>
    Pow = a => b => b(n => Multiply(a)(n))(One);

Similar to Church Boolean operators, the above arithmetic operators can also be wrapped as extension method for convenience:

public static partial class NumeralExtensions
{
    public static Numeral Increase(this Numeral n) => ChurchNumeral.Increase(n);

    public static Numeral Decrease(this Numeral n) => ChurchNumeral.Decrease(n);

    public static Numeral Add(this Numeral a, Numeral b) => ChurchNumeral.Add(a)(b);

    public static Numeral Subtract(this Numeral a, Numeral b) => ChurchNumeral.Subtract(a)(b);

    public static Numeral Multiply(this Numeral a, Numeral b) => ChurchNumeral.Multiply(a)(b);

    public static Numeral Pow(this Numeral mantissa, Numeral exponent) => ChurchNumeral.Pow(mantissa)(exponent);
}

Predicate and relational operators

Predicate is function returning Church Boolean. For example, the following function predicate whether a Church numeral n is 0:

IsZero := λn.n (λx.False) True

When n is 0, (λx.False) is not applied, and IsZero directly returns True. When n is positive, (λx.False) is applied for n times. (λx.False) always return False, so IsZero returns False. The following are the implementation and extension method:

public static partial class ChurchPredicate
{
    public static readonly Func<Numeral, Boolean> 
        IsZero = n => n(_ => False)(True);
}

public static partial class NumeralExtensions
{
    public static Boolean IsZero(this Numeral n) => ChurchPredicate.IsZero(n);
}

With IsZero, it is easy to define functions to compare 2 Church numerals a and b. According the to definition of Decrease and Subtract, when a – b is 0, a is either equal to b, or less than b. So IsLessThanOrEqualTo can be defined with IsZero and Subtract:

IsLessThanOrEqualTo := λa.λb.IsZero (Subtract a b)

IsGreaterThanOrEqualTo is similar:

IsGreaterThanOrEqualTo := λa.λb.IsZero (Subtract b a)

Then these 2 functions can define IsEqualTo:

IsEqualTo := λa.λb.And (IsLessThanOrEqualTo a b) (IsGreaterThanOrEqualTo a b)

The opposite of these functions are IsGreaterThan, IsLessThan, IsNotEqual. They can be defined with Not:

IsGreaterThan := λa.λb.Not (IsLessThanOrEqualTo a b)
IsLessThan := λa.λb.Not (IsGreaterThanOrEqualTo a b)
IsNotEqualTo := λa.λb.Not (IsEqualTo a b)

The following are the C# implementation of these 6 predicates:

public static partial class ChurchPredicate
{
    public static readonly Func<Numeral, Func<Numeral, Boolean>> 
        IsLessThanOrEqualTo = a => b => a.Subtract(b).IsZero();

    public static readonly Func<Numeral, Func<Numeral, Boolean>> 
        IsGreaterThanOrEqualTo = a => b => b.Subtract(a).IsZero();

    public static readonly Func<Numeral, Func<Numeral, Boolean>>
        IsEqualTo = a => b => IsLessThanOrEqualTo(a)(b).And(IsGreaterThanOrEqualTo(a)(b));

    public static readonly Func<Numeral, Func<Numeral, Boolean>>
        IsGreaterThan = a => b => IsLessThanOrEqualTo(a)(b).Not();

    public static readonly Func<Numeral, Func<Numeral, Boolean>> 
        IsLessThan = a => b => IsGreaterThanOrEqualTo(a)(b).Not();

    public static readonly Func<Numeral, Func<Numeral, Boolean>>
        IsNotEqualTo = a => b => IsEqualTo(a)(b).Not();
}

public static partial class NumeralExtensions
{
    public static Boolean IsLessThanOrEqualTo(this Numeral a, Numeral b) => ChurchPredicate.IsLessThanOrEqualTo(a)(b);

    public static Boolean IsGreaterThanOrEqualTo(this Numeral a, Numeral b) => ChurchPredicate.IsGreaterThanOrEqualTo(a)(b);

    public static Boolean IsEqualTo(this Numeral a, Numeral b) => ChurchPredicate.IsEqualTo(a)(b);

    public static Boolean IsGreaterThan(this Numeral a, Numeral b) => ChurchPredicate.IsGreaterThan(a)(b);

    public static Boolean IsLessThan(this Numeral a, Numeral b) => ChurchPredicate.IsLessThan(a)(b);

    public static Boolean IsNotEqualTo(this Numeral a, Numeral b) => ChurchPredicate.IsNotEqualTo(a)(b);
}

Attempt of recursion

The division of natural numbers can be defined with arithmetic and relation operators:

a / b := if a >= b then 1 + (a – b) / b else 0

This is a recursive definition. If defining division in this way lambda calculus, the function name is referred in its own body:

DivideBy := λa.λb.If (IsGreaterThanOrEqualTo a b) (λx.Add One (DivideBy (Subtract a b) b)) (λx.Zero)

As fore mentioned, in lambda calculus, functions are anonymously by default, and names are just for readability. Here the self reference does not work with anonymous function:

λa.λb.If (IsGreaterThanOrEqualTo a b) (λx.Add One (? (Subtract a b) b)) (λx.Zero)

So the above DivideBy function definition is illegal in lambda calculus. The recursion implementation with anonymous function will be discussed later in this chapter.

In C#, recursion is a basic feature, so the following self reference is supported:

using static ChurchBoolean;

public static partial class ChurchNumeral
{
    // Divide = dividend => divisor => 
    //    If(dividend >= divisor)
    //        (_ => 1 + DivideBy(dividend - divisor)(divisor))
    //        (_ => 0);
    public static readonly Func<Numeral, Func<Numeral, Numeral>>
        DivideBy = dividend => divisor =>
            If(dividend.IsGreaterThanOrEqualTo(divisor))
                (_ => One.Add(DivideBy(dividend.Subtract(divisor))(divisor)))
                (_ => Zero);
}

Here using static directive is used so that ChurchBoolean.If function can be called directly. DivideBy is compiled to a field definition and field initialization code in static constructor, and apparently referencing to a field in the constructor is allowed:

using static ChurchBoolean;
using static ChurchNumeral;

public static partial class CompiledChurchNumeral
{
    public static readonly Func<Numeral, Func<Numeral, Numeral>> DivideBySelfReference;

    static CompiledChurchNumeral()
    {
        DivideBySelfReference = dividend => divisor =>
            If(dividend.IsGreaterThanOrEqualTo(divisor))
                (_ => One.Add(DivideBySelfReference(dividend.Subtract(divisor))(divisor)))
                (_ => Zero);
    }
}

The self reference also works for named function:

public static partial class ChurchNumeral
{
    public static Func<Numeral, Numeral> DivideByMethod(Numeral dividend) => divisor =>
        If(dividend.IsGreaterThanOrEqualTo(divisor))
            (_ => One.Add(DivideByMethod(dividend.Subtract(divisor))(divisor)))
            (_ => Zero);
}

The only exception is, when this function is a local variable instead of field, then the inline self reference cannot be compiled:

internal static void Inline()
{
    Func<Numeral, Func<Numeral, Numeral>> divideBy = dividend => divisor =>
        If(dividend.IsGreaterThanOrEqualTo(divisor))
            (_ => One.Add(divideBy(dividend.Subtract(divisor))(divisor)))
            (_ => Zero);
}

The reason is, the value of the local variable is compiled before the local variable is compiled. when the anonymous function is compiled, the referenced divideBy function is not defined yet, and C# compiler gives CS0165 error: Use of unassigned local variable 'divideBy'. To resolve this problem, divideBy can be first initialized with default value null. When divideBy is initialized again with the anonymous function, it is already defined, so the lambda expression can be compiled:

internal static void Inline()

{
    Func<Numeral, Func<Numeral, Numeral>> divideBy = null;
    divideBy = dividend => divisor =>
        If(dividend.IsGreaterThanOrEqualTo(divisor))
            (_ => One.Add(divideBy(dividend.Subtract(divisor))(divisor)))
            (_ => Zero);
}

The above division operator DivideBy will be used temporarily. Later after introducing fixed point combinator, the division can be implemented with an anonymous function without self reference at all.

Conversion between Church numeral and System.UInt32

In .NET, natural number can be represented with unit (System.UInt32). It would be intuitive if Church numeral and uint can be converted to each other. Similar to the conversion between Church Boolean and bool, the following extension methods can be defined:

public static partial class ChurchEncoding
{
    public static Numeral Church(this uint n) => n == 0U ? ChurchNumeral.Zero : Church(n - 1U).Increase();

    public static uint Unchurch(this Numeral n) => (uint)n(x => (uint)x + 1U)(0U);
}

Converting uint to Church numeral is recursive. When n is 0, Zero is returned directly. When n is positive, n is decreased and converted recursively. The recursion terminates when n is decreased to 0, then Increase is called for n times with Zero, and Church numeral n is calculated. And converting Church numeral n to uint just need to add 1U for n times to 0U.

The following code demonstrate how the operators and conversions work:

[TestClass]
public partial class ChurchNumeralTests
{
    [TestMethod]
    public void IncreaseTest()
    {
        Numeral numeral = 0U.Church();
        Assert.AreEqual(0U + 1U, (numeral = numeral.Increase()).Unchurch());
        Assert.AreEqual(1U + 1U, (numeral = numeral.Increase()).Unchurch());
        Assert.AreEqual(2U + 1U, (numeral = numeral.Increase()).Unchurch());
        Assert.AreEqual(3U + 1U, (numeral = numeral.Increase()).Unchurch());
        numeral = 123U.Church();
        Assert.AreEqual(123U + 1U, numeral.Increase().Unchurch());
    }

    [TestMethod]
    public void AddTest()
    {
        Assert.AreEqual(0U + 0U, 0U.Church().Add(0U.Church()).Unchurch());
        Assert.AreEqual(0U + 1U, 0U.Church().Add(1U.Church()).Unchurch());
        Assert.AreEqual(10U + 0U, 10U.Church().Add(0U.Church()).Unchurch());
        Assert.AreEqual(0U + 10U, 0U.Church().Add(10U.Church()).Unchurch());
        Assert.AreEqual(1U + 1U, 1U.Church().Add(1U.Church()).Unchurch());
        Assert.AreEqual(10U + 1U, 10U.Church().Add(1U.Church()).Unchurch());
        Assert.AreEqual(1U + 10U, 1U.Church().Add(10U.Church()).Unchurch());
        Assert.AreEqual(3U + 5U, 3U.Church().Add(5U.Church()).Unchurch());
        Assert.AreEqual(123U + 345U, 123U.Church().Add(345U.Church()).Unchurch());
    }

    [TestMethod]
    public void DecreaseTest()
    {
        Numeral numeral = 3U.Church();
        Assert.AreEqual(3U - 1U, (numeral = numeral.Decrease()).Unchurch());
        Assert.AreEqual(2U - 1U, (numeral = numeral.Decrease()).Unchurch());
        Assert.AreEqual(1U - 1U, (numeral = numeral.Decrease()).Unchurch());
        Assert.AreEqual(0U, (numeral = numeral.Decrease()).Unchurch());
        numeral = 123U.Church();
        Assert.AreEqual(123U - 1U, numeral.Decrease().Unchurch());
    }

    [TestMethod]
    public void SubtractTest()
    {
        Assert.AreEqual(0U - 0U, 0U.Church().Subtract(0U.Church()).Unchurch());
        Assert.AreEqual(0U, 0U.Church().Subtract(1U.Church()).Unchurch());
        Assert.AreEqual(10U - 0U, 10U.Church().Subtract(0U.Church()).Unchurch());
        Assert.AreEqual(0U, 0U.Church().Subtract(10U.Church()).Unchurch());
        Assert.AreEqual(1U - 1U, 1U.Church().Subtract(1U.Church()).Unchurch());
        Assert.AreEqual(10U - 1U, 10U.Church().Subtract(1U.Church()).Unchurch());
        Assert.AreEqual(0U, 1U.Church().Subtract(10U.Church()).Unchurch());
        Assert.AreEqual(0U, 3U.Church().Subtract(5U.Church()).Unchurch());
        Assert.AreEqual(0U, 123U.Church().Subtract(345U.Church()).Unchurch());
    }

    [TestMethod]
    public void MultiplyTest()
    {
        Assert.AreEqual(0U*0U, 0U.Church().Multiply(0U.Church()).Unchurch());
        Assert.AreEqual(0U*1U, 0U.Church().Multiply(1U.Church()).Unchurch());
        Assert.AreEqual(10U*0U, 10U.Church().Multiply(0U.Church()).Unchurch());
        Assert.AreEqual(0U*10U, 0U.Church().Multiply(10U.Church()).Unchurch());
        Assert.AreEqual(1U*1U, 1U.Church().Multiply(1U.Church()).Unchurch());
        Assert.AreEqual(10U*1U, 10U.Church().Multiply(1U.Church()).Unchurch());
        Assert.AreEqual(1U*10U, 1U.Church().Multiply(10U.Church()).Unchurch());
        Assert.AreEqual(3U*5U, 3U.Church().Multiply(5U.Church()).Unchurch());
        Assert.AreEqual(12U*23U, 12U.Church().Multiply(23U.Church()).Unchurch());
    }

    [TestMethod]
    public void PowTest()
    {
        Assert.AreEqual(Math.Pow(0U, 1U), 0U.Church().Pow(1U.Church()).Unchurch());
        Assert.AreEqual(Math.Pow(10U, 0U), 10U.Church().Pow(0U.Church()).Unchurch());
        Assert.AreEqual(Math.Pow(0U, 10U), 0U.Church().Pow(10U.Church()).Unchurch());
        Assert.AreEqual(Math.Pow(1U, 1U), 1U.Church().Pow(1U.Church()).Unchurch());
        Assert.AreEqual(Math.Pow(10U, 1U), 10U.Church().Pow(1U.Church()).Unchurch());
        Assert.AreEqual(Math.Pow(1U, 10U), 1U.Church().Pow(10U.Church()).Unchurch());
        Assert.AreEqual(Math.Pow(3U, 5U), 3U.Church().Pow(5U.Church()).Unchurch());
        Assert.AreEqual(Math.Pow(5U, 3U), 5U.Church().Pow(3U.Church()).Unchurch());
    }

    [TestMethod]
    public void DivideByRecursionTest()
    {
        Assert.AreEqual(1U / 1U, 1U.Church().DivideBy(1U.Church()).Unchurch());
        Assert.AreEqual(1U / 2U, 1U.Church().DivideBy(2U.Church()).Unchurch());
        Assert.AreEqual(2U / 2U, 2U.Church().DivideBy(2U.Church()).Unchurch());
        Assert.AreEqual(2U / 1U, 2U.Church().DivideBy(1U.Church()).Unchurch());
        Assert.AreEqual(10U / 3U, 10U.Church().DivideBy(3U.Church()).Unchurch());
        Assert.AreEqual(3U / 10U, 3U.Church().DivideBy(10U.Church()).Unchurch());
    }
}

Lambda Calculus via C# (2) Church Encoding: Boolean and Logic

Mon, 04 Nov 2024 13:05:00 GMT

[FP & LINQ via C# series]

[Lambda Calculus via C# series]

Lambda calculus is a formal system for function definition and function application, so in lambda calculus, the only primitive is anonymous function. Anonymous function is actually very powerful. With an approach called Church encoding. data and operation can be modeled by higher-order anonymous functions and their application. Church encoding is named after Alonzo Church, who first discovered this approach. This part discusses Church Boolean - modeling Boolean values and logic operators with functions.

Church Boolean

Boolean values True and False can be both represented by anonymous function with 2 parameters. True function simply output the first parameter, and False function output the second parameter:

True := λtf.t
False := λtf.f

As fore mentioned, λtf.E is just the abbreviation of λt.λf.E, so these definitions actually are:

True := λt.λf.t
False := λt.λf.f

In this tutorial, for consistency and intuition, function definition with multiple variables is always represented in the latter curried form. In C#, they can be viewed as t => f => t and t => f => f, which are curried from (t, f) => t and (t, f) => f. Here t and f can be of any type, so leave their types as dynamic for convenience. In C#, at compile time dynamic is viewed as object and also supports any operation; at runtime if the operation is actually not supported, an exception is thrown. So, the function type of t => f => t and t => f => f is dynamic –> dynamic –> dynamic, which is represented as Func<dynamic, Func<dynamic, dynamic>> in C#. For convenience, an alias Boolean can be defined for such function type:

// Curried from (dynamic, dynamic) -> dynamic.
// Boolean is the alias of dynamic -> dynamic -> dynamic.
public delegate Func<dynamic, dynamic> Boolean(dynamic @true);

So that True and False can be defined with lambda expression:

public static partial class ChurchBoolean
{
    public static readonly Boolean
        True = @true => @false => @true;

    public static readonly Boolean
        False = @true => @false => @false;
}

C# does not support defining function directly in the global scope, so True and False are defined as static filed member of a type. In other functional languages like F#, functions can directly defined:

let True t f = t
let False t f = f

There is no noise and the function currying is default. Actually this F# code is compiled to CIL code similar to above C# structure (static member of a type).

Logical operators

After defining Boolean values True and False with functions, now the Boolean logics can be represented by functions too. And can be defined by the following function:

And := λa.λb.a b False

Applying function True with Boolean a and b:

When a is True, the application is beta reduced to True b False, which applies True function with b and False, and the first argument b is returned. In C#, this can be viewed that true && b is the same as b.
When a is False, the application is beta reduced to False b False, which applies False function with b and False, and the second argument False is returned. In C#, this can be viewed as false && b is always false.

  And True b
≡ (λa.λb.a b False) True b
≡ (λb.True b False) b
≡ True b False
≡ b

  And False b
≡ (λa.λb.a b False) False b
≡ (λb.False b False) b
≡ False b False
≡ False

In C#, And can be viewed as a => b => a(b)(False), it is of curried function type Boolean –> Boolean -> Boolean:

public static partial class ChurchBoolean
{
    public static readonly Func<Boolean, Func<Boolean, Boolean>>
        And = a => b => a(b)(False);
}

This demonstrates that the Boolean alias improves the readability. Without this alias, the type of And becomes (dynamic –> dynamic –> dynamic) –> (dynamic –> dynamic –> dynamic) –> (dynamic –> dynamic –> dynamic), which is Func<Func<dynamic, Func<dynamic, dynamic>>, Func<Func<dynamic, Func<dynamic, dynamic>>, Func<dynamic, Func<dynamic, dynamic>>>> in C#.

This also demonstrates that dynamic type simplifies type conversion. If Boolean is defined as object –> object -> object:

public delegate Func<object, object> Boolean(object @true);

public static partial class ChurchBoolean
{
    public static readonly Func<Boolean, Func<Boolean, Boolean>>
        And = a => b => (Boolean)a(b)(False);
}

And must return Boolean, but a(b)(False) returns object, so a type conversion is required. Here a is either True or False, according to the definition of True and False, a(b)(False) returns either b or False. Since b and False are both of type Boolean, so here it is safe to convert a(b)(False) to Boolean. In contrast, when Boolean is defined as dynamic –> dynamic -> dynamic, a(b)(False) returns dynamic, which is viewed as supporting any operation at compile time, including implicitly conversion to Boolean, so the explicit type conversion is not required. At run time, a(b)(False) always return Boolean, and converting Boolean to Boolean always succeeds, so And works smoothly without any exception.

In the above lambda function and C# function, a function name False is referenced. Again, function is anonymous by default in lambda calculus. This tutorial uses function name only for for readability. By substituting function name, And can be defined as:

And := λa.λb.a b (λt.λf.f)

And the C# implementation becomes:

public static Func<Boolean, Func<Boolean, Boolean>>
    And = a => b => a(b)(new Boolean(@true => @false => @false));

The function body is longer and less readable. Also, a is of type dynamic –> dynamic -> dynamic, the second argument of a is expected to be object. When function reference False is given, False is a Boolean delegate instance, apparently it is an object and works there, However, when an inline C# lambda expression is given. C# compiler cannot infer the the type of this lambda expression – it could be anonymous function, or expression tree, and the type information of @true and @false cannot be inferred either. So here the constructor syntax is used to indicate this inline lambda expression is a function of type dynamic –> dynamic -> dynamic.

Again, C# does not support defining custom operators for functions, so a && operator cannot be defined for Boolean type. However, extension method can be defined for Boolean type, also And can be implemented as:

public static partial class BooleanExtensions
{
    public static Boolean And(this Boolean a, Boolean b) => ChurchBoolean.And(a)(b);
}

Now And can be used fluently like an infix operator:

internal static void CallAnd()
{
    Boolean result1 = True.And(True);

    Boolean x = True;
    Boolean y = False;
    Boolean result2 = x.And(y);
}

Once again, the function name And is only for readability, without refereeing to the function name., the function application (And x y) has to be written as (λa.λb.a b (λt.λf.f)) x y, and in C#, calling And anonymously works but is also less readable:

internal static void CallAnonymousAnd()
{
    Boolean result1 = new Func<Boolean, Func<Boolean, Boolean>>(a => b => (Boolean)a(b)(False))(True)(True);

    Boolean x = True;
    Boolean y = False;
    Boolean result2 = new Func<Boolean, Func<Boolean, Boolean>>(a => b => (Boolean)a(b)(False))(x)(y);
}

Or is defined as:

Or :=  λa.λb.a True b

When a is True, True True b returns the first argument True; When a is False, False True b returns the second argument b. In C#, this can be viewed as true || b is always true, and false || b is the same as b.

  Or True b
≡ (λa.λb.a True b) True b
≡ (λb.True True b) b
≡ True True b
≡ True
 
  Or False b
≡ (λa.λb.a True b) False b
≡ (λb.False True b) b
≡ False True b
≡ b

Not is defined as:

Not := λa.a False True

When a is True, True False True returns the first argument False; when a is False, False False True returns the second argument True:

  Not True
≡ (λa.a False True) True
≡ True False True
≡ False
 
  Not False
≡ (λa.a False True) False
≡ False False True
≡ True

Xor is defined as:

Xor := λa.λb.a (Not b) b

When a is True, True (Not b) b returns the first argument Not b; when a is False, True (Not b) b returns the second argument b:

  Xor True b
≡ (λa.λb.a (Not b) b) True b
≡ (λb.True (Not b) b) b
≡ True (Not b) b
≡ Not b
 
  Xor False b
≡ (λa.λb.a (Not b) b) True b
≡ (λb.False (Not b) b) b
≡ False (Not b) b
≡ b

These 3 operators can be simply implemented as:

public static Func<Boolean, Func<Boolean, Boolean>> 
    Or = a => b => a(True)(b);

public static Func<Boolean, Boolean> 
    Not = boolean => boolean(False)(True);

public static Func<Boolean, Func<Boolean, Boolean>>
    Xor = a => b => a(Not(b))(b);

Again, they can be wrapped as extension methods too:

public static Boolean Or(this Boolean a, Boolean b) => ChurchBoolean.Or(a)(b);

public static Boolean Not(this Boolean a) => ChurchBoolean.Not(a);

public static Boolean Xor(this Boolean a, Boolean b) => ChurchBoolean.Xor(a)(b);

Conversion between Church Boolean and System.Boolean

It could be intuitive if the Church Boolean function can be directly compared with .NET bool value. The following methods can be defined to convert between them:

public static partial class ChurchEncoding
{
    // System.Boolean structure to Boolean function.
    public static Boolean Church(this bool boolean) => boolean ? True : False;

    // Boolean function to System.Boolean structure.
    public static bool Unchurch(this Boolean boolean) => boolean(true)(false);
}

With the help of conversion, the following code demonstrate how to use the logical operators:

[TestClass]
public partial class ChurchBooleanTests
{
    [TestMethod]
    public void NotTest()
    {
        Assert.AreEqual((!true).Church(), True.Not());
        Assert.AreEqual((!false).Church(), False.Not());
    }

    [TestMethod]
    public void AndTest()
    {
        Assert.AreEqual((true && true).Church(), True.And(True));
        Assert.AreEqual((true && false).Church(), True.And(False));
        Assert.AreEqual((false && true).Church(), False.And(True));
        Assert.AreEqual((false && false).Church(), False.And(False));
    }

    [TestMethod]
    public void OrTest()
    {
        Assert.AreEqual((true || true).Church(), True.Or(True));
        Assert.AreEqual((true || false).Church(), True.Or(False));
        Assert.AreEqual((false || true).Church(), False.Or(True));
        Assert.AreEqual((false || false).Church(), False.Or(False));
    }

    [TestMethod]
    public void XorTest()
    {
        Assert.AreEqual((true ^ true).Church(), True.Xor(True));
        Assert.AreEqual((true ^ false).Church(), True.Xor(False));
        Assert.AreEqual((false ^ true).Church(), False.Xor(True));
        Assert.AreEqual((false ^ false).Church(), False.Xor(False));
    }
}

If

The if logic is already built in Church Booleans. Church Booleans is a function that can be applied with 2 argument. If this Church Boolean function is True, the first argument is returned, else the second argument is returned. So naturedly, the following is the If function, which is just a wrapper of Church Boolean function application:

If := λb.λt.λf.b t f

The first argument b is a Church Boolean. when b is True, If returns second argument t. When b is False, If returns third argument f. In C#:

// EagerIf = condition => then => @else => condition(then)(@else)
public static readonly Func<Boolean, Func<dynamic, Func<dynamic, dynamic>>>
    EagerIf = condition => then => @else =>
        condition    // if (condition)
            (then)   // then { ... }
            (@else); // else { ... }

There is one issue with this C# implementation. As fore mentioned, C#’s reduction strategy is applicative order, when C# function is called, arguments are evaluated, then function is called:

internal static void CallEagerIf(Boolean condition, Boolean a, Boolean b)
{
    Boolean result = EagerIf(condition)
        (a.And(b)) // then branch.
        (a.Or(b)); // else branch.
}

In this example, disregarding condition is True or False, the then branch a.And(b) and else branch a.Or(b) are both executed. If would be better if one branch is executed for a certain condition. The solution is to make If’s second and third arguments of type T to a factory of type Unit<T> –> T:

// If = condition => thenFactory => elseFactory => condition(thenFactory, elseFactory)(Id)
public static readonly Func<Boolean, Func<Func<Unit<dynamic>, dynamic>, Func<Func<Unit<dynamic>, dynamic>, dynamic>>>
    If = condition => thenFactory => elseFactory =>
        condition
            (thenFactory)
            (elseFactory)(Functions<dynamic>.Id);

In lambda calculus this is equivalent to:

If := λb.λt.λf.b t f Id

Now calling If becomes:

internal static void CallLazyIf(Boolean condition, Boolean a, Boolean b)
{
    Boolean result = If(condition)
        (id => a.And(b)) // then.
        (id => a.Or(b)); // else.
}

When condition is True, only a.And(b) is executed. When condition is False, only a.Or(b) is executed. Now the then and else branches are represented by factory functions id => a.And(b) and id => a.Or(b), where the id argument is the Id function. This argument usually is not used by the function body, it can be named as _ to indicate “don’t care”:

internal static void CallLazyIf(Boolean condition, Boolean a, Boolean b)
{
    Boolean result = If(condition)
        (_ => a.And(b)) // then.
        (_ => a.Or(b)); // else.
}

Dixin's Blog

C# Functional Programming In-Depth (14) Asynchronous Function

[LINQ via C# series]

[C# functional programming in-depth series]

Task, Task<TResult> and asynchrony

Named async function

Awaitable-awaiter pattern

Async state machine

Runtime context capture

Generalized async function output type and async method builder

ValueTask<TResult> and performance

Anonymous async function

Asynchrnous sequence: IAsyncEnumerable<T>

async using declaration: IAsyncDispose

Summary

Functional Programming and LINQ via C#

Acclaim

Contents at a Glance

Table of Contents

Understanding (all) JavaScript module formats and tools

IIFE module: JavaScript module pattern

IIFE: Immediately invoked function expression

Import mixins

Revealing module: JavaScript revealing module pattern

CJS module: CommonJS module, or Node.js module

AMD module: Asynchronous Module Definition, or RequireJS module

Dynamic loading

AMD module from CommonJS module

UMD module: Universal Module Definition, or UmdJS module

UMD for both AMD (RequireJS) and native browser

UMD for both AMD (RequireJS) and CommonJS (Node.js)

ES module: ECMAScript 2015, or ES6 module

ES dynamic module: ECMAScript 2020, or ES11 dynamic module

System module: SystemJS module

Dynamic module loading

Webpack module: bundle from CJS, AMD, ES modules

Babel module: transpile from ES module

Babel with SystemJS

TypeScript module: Transpile to CJS, AMD, ES, System modules

Internal module and namespace

Conclusion

Port Microsoft Concurrency Visualizer SDK to .NET Standard and NuGet

TransientFaultHandling.Core: Retry library for .NET Core/.NET Standard

Introduction

Document

Source

NuGet installation

Backward compatibility with Enterprise Library

How to use the APIs

Object-oriented APIs from Enterprise Library

New functional APIs: single function call for retry

New fluent APIs for retry

Old XML configuration for retry

New XML/JSON/INI configuration for retry

TransientFaultHandling.Data.Core: SQL Server support

History

Category Theory via C# (8) Advanced LINQ to Monads

[FP & LINQ via C# series]

[Category Theory via C# series]

IO monad

State monad

Exception monad

Reader monad

Writer monad

Continuation monad

Category Theory via C# (7) Monad and LINQ to Monads

[FP & LINQ via C# series]

[Category Theory via C# series]

Monad

LINQ to Monads and monad laws

Built-in IEnumerable<> monad

Monad law and Kleisli composition

Kleisli category

Monad pattern of LINQ

Monad vs. monoidal/applicative functor

More LINQ to Monads

Category Theory via C# (6) Monoidal Functor and Applicative Functor

[FP & LINQ via C# series]

[Category Theory via C# series]

Monoidal functor