Understanding how state machines, cancellation, and concurrency control work together is key to writing efficient, safe, and scalable asynchronous F# code.

1. State Machines: The Foundation of Async Execution

A state machine is a compiler-generated structure that allows an asynchronous function to pause and resume execution. Every time you use do! or let!, the function may suspend, freeing the current thread, and later resume from the same point.

Conceptually, an async download function progresses through states such as:

• Waiting for a semaphore
• Sending an HTTP request
• Receiving data
• Writing to disk
• Cleaning up resources

The F# compiler automatically tracks:

• The current execution state
• Local variables
• The next instruction after an await

Without this mechanism, developers would need to manually write callbacks or continuation chains. The state machine provides correctness, readability, and scalability with minimal effort.

task {
    do! semaphore.WaitAsync()
    let! bytes = client.GetByteArrayAsync(url)
    File.WriteAllBytes(path, bytes)
}

Although this looks linear, it is actually resumable and non-blocking.

You can think of the state machine as a bookmark in a book:

The compiler remembers exactly where to resume execution after each awaited operation.

2. CancellationToken: Cooperative Cancellation

A CancellationToken provides a controlled stop mechanism for asynchronous operations. Instead of forcibly terminating tasks, cancellation in .NET and F# is cooperative.

Each async API periodically checks the token and throws OperationCanceledException when cancellation is requested.

let cts = new CancellationTokenSource()
downloadPdf cts.Token url
cts.Cancel()

This approach ensures:

• Resources are released safely
• finally blocks still execute
• Partial work does not corrupt state

Cancellation tokens are essential for:

• User-initiated aborts
• Application shutdown
• Timeouts
• Cancelling queued or waiting operations

Think of a CancellationToken as a stop button that you pass into your async operations. When pressed, all observing tasks are notified and exit cleanly.

3. SemaphoreSlim: Controlling Parallelism

SemaphoreSlim limits the number of concurrent operations. This is critical when performing network- or disk-heavy tasks to avoid overwhelming the system or remote services.

let semaphore = new SemaphoreSlim(3)

do! semaphore.WaitAsync()
try
    // critical section
finally
    semaphore.Release() |> ignore

With a semaphore:

• Only maxParallel tasks run simultaneously
• Excess tasks wait without consuming threads
• Throughput becomes predictable and stable

Example with maxParallel = 3:

Slots: [X] [X] [X]

Tasks queued:
A | B | C | D | E | F

Step 1: A, B, C acquire slots → start HTTP
Step 2: D, E, F wait
Step 3: A finishes → slot released → D starts
Step 4: B finishes → slot released → E starts
Step 5: Cancellation requested → remaining tasks stop

The semaphore limits active states, while the state machine remembers where each task is paused.

4. How These Concepts Work Together

Each asynchronous task has its own internal state machine:

[Task: downloadPdf url1]
State 0: Waiting for semaphore
State 1: Semaphore acquired
State 2: HTTP request started
State 3: File written
State 4: Semaphore released → Done

If a cancellation token is triggered:

• Waiting tasks observe cancellation immediately
• Running tasks throw OperationCanceledException at their next check
• finally blocks still run, releasing the semaphore

This cooperation between mechanisms is what makes F# async code both powerful and safe.

5. The Role of |> ignore

You may often see code like this:

semaphore.Release() |> ignore

The forward pipe operator |> passes the value on the left into the function on the right.

ignore is defined as:

val ignore : 'a -> unit

It simply discards a value. Since Release() returns an integer that is not needed, piping it into ignore makes the intent explicit.

Why This Matters

Together, these concepts enable:

• Efficient use of threads
• Safe, cooperative cancellation
• Controlled concurrency
• Clean, maintainable asynchronous code

Without compiler-generated state machines, you would be forced to manually split logic into callbacks and continuations. F# hides that complexity while still giving you precise control over cancellation and parallelism.

Mastering these tools lets you write async code that scales gracefully and behaves predictably—even under heavy load. ```

When learning F#, one of the first confusions beginners face is the difference between .fsx files (F# scripts) and .fs files (source files part of a project). Understanding this distinction is essential for writing efficient scripts, experimenting, or developing full-fledged applications.

1️⃣ .fsx — F# Script Files

.fsx files are interactive scripts, designed for quick prototyping, automation, or teaching. They are executed directly by F# Interactive (FSI) and do not require compilation.

Key Features:

• Execution: Interpreted top-to-bottom via dotnet fsi script.fsx

• EntryPoint: Optional

• References: Can include packages or DLLs inline using #r "..."

• Order Matters: Code runs sequentially as written

Use Case: Quick experiments, file processing scripts, teaching examples.

Example: stat.fsx — Show File/Directory Metadata

This script demonstrates how to get size, last modified time, and permissions for files and directories:

open System
open System.IO

/// Show metadata for a file or directory
let showStat path =
    if File.Exists path then
        let f = FileInfo path
        printfn "File: %s" f.FullName

    elif Directory.Exists path then
        let d = DirectoryInfo path

        printfn "Last modified: %s" (d.LastWriteTime.ToString())
    else
        printfn "stat: cannot stat '%s': No such file or directory" path

/// Get command-line argument from FSI
let args =
    if fsi.CommandLineArgs.Length > 1 then fsi.CommandLineArgs.[1..] else [||]

match args with
| [| path |] -> showStat path
| _ -> printfn "Usage: dotnet fsi stat.fsx <file-or-directory>"

Run the script:

dotnet fsi stat.fsx /path/to/file

This is perfect for learning file I/O in F# and demonstrates a practical use of .fsx scripts.

2️⃣ .fs — F# Source Files

.fs files are part of a formal F# project. They are compiled using the project file (.fsproj) and produce a DLL or EXE.

Key Features:

• Execution: Compiled → run via dotnet run or referenced as a library

• EntryPoint: [<EntryPoint>] required for console apps

• References: Managed via .fsproj or NuGet

• Use Case: Multi-file applications, production software, libraries

Example: A console application, library, or large F# service.

3️⃣ .fsx vs .fs — Quick Comparison

4️⃣ When to Use Which

• Use .fsx for learning, scripting, automation, or experiments.

• Use .fs when building production applications, libraries, or multi-file projects.

The stat.fsx example is a perfect demonstration of .fsx usage: a self-contained script that interacts with the filesystem, useful for both learning F# I/O and practical scripting.

💡 Pro Tip: Start small with .fsx scripts to prototype functionality quickly. Once your logic stabilizes and your code grows, migrate it into a .fsproj project with .fs files for a more maintainable and production-ready structure.

A Theory-Driven Explanation from the F# Type System

When building a shell-like system in F#, it’s natural to think in terms of concepts.

You see a directory listing command and instinctively reach for a name like:

handleDir args

Then the compiler responds with something like:

FS0039: The value 'handleDir' is not defined. Maybe you want: handleLs, handleTree

At first glance, this feels like a trivial naming issue. Just rename the function, right?

But this error has nothing to do with directories.

It’s about symbol resolution, function contracts, and how F# encodes meaning through types.

No Name, No Existence

F# is a statically typed, symbol-driven language.

A function exists only if it is explicitly defined and in scope. There is:

• no implicit meaning

• no semantic guessing

• no late binding

If a symbol is not defined, it does not exist — full stop.

So when the compiler says “Maybe you want: handleLs, handleTree”, it’s not being helpful about spelling. It’s telling you something more important:

The abstraction you tried to invent does not exist — but more precise ones already do.

That’s where the real lesson begins.

In F#, Identity Comes from the Type Signature

In F#, the identity of a function is not its name. It is its type signature.

The compiler does not reason about intent (“this is a directory command”). It reasons about contracts:

1. How many arguments does the function take?

2. What are the types of those arguments?

3. What is the result type?

This is why the difference between the following is semantic, not stylistic:

handleDiskInfo () handleLs args

unit vs Arguments Is a Design Statement

The empty parentheses () represent the unit type.

A function that accepts unit is declaring something very specific:

This operation takes no information from the caller.

Its behavior is invariant. The caller cannot influence it.

That maps cleanly to commands like:

• df

• uptime

These commands are conceptually invoke-and-report operations.

By contrast, a function that accepts string[] is explicitly stating:

My behavior depends on externally supplied input.

That maps to commands like:

• ls

• du

• tree

These commands represent a family of behaviors, parameterized by paths, flags, or options.

Unix Philosophy, Enforced at the Type Level

This distinction isn’t accidental — it’s Unix philosophy encoded into the type system.

Trying to collapse everything into a generic:

handleDir args

erases this distinction.

It pushes meaning out of the type system and into runtime logic — where it becomes harder to reason about, easier to misuse, and impossible for the compiler to enforce.

F# resists this by design.

The Compiler Is Not Complaining — It’s Reviewing Your Design

When the compiler suggests handleLs or handleTree, it’s not saying:

“You misspelled something.”

It’s saying:

“You already modeled this more precisely than what you’re attempting now.”

This leads to the correct mental model:

F# function signature == command interface contract

• If a command conceptually varies with input, its function must accept parameters.

• If it does not, its function must accept unit.

This is not ceremonial verbosity. It is how correctness is enforced early, mechanically, and without ambiguity.

The Real Takeaway

Static typing is often framed as a way to prevent mistakes.

That’s underselling it.

Static typing prevents bad abstractions.

It forces you to commit to a model of behavior — and makes imprecise models impossible to express.

Once you see this, the compiler stops feeling strict and starts feeling honest.

The syntax difference is just the surface. The rule underneath is the point.

$ sudo apt install wget ca-certificates

Add it to apt-key management utility and create a new configuration file with an official PostgreSQL repository address

$ wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

$ sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ $(lsb_release -cs)-pgdg main" >> /etc/apt/sources.list.d/pgdg.list'

Install PostgreSQL

$ sudo apt update

$ apt install postgresql postgresql-contrib

Check PostgreSQL status

$ service postgresql status

Command Line Tool

A default admin user “postgres” is created by the default. A “psql” command-line client tool is used to interact with the database engine.

$ sudo -u postgres psql

PostgreSQL installation also creates a default database named “postgres” and connects you to it automatically when you first launch psql.

Check the connection

$ \conninfo

If you want to see a list of all the databases that are available on a server, use \l command.

$ \l

list of all the users with their privileges use

$ \du

Since the default “postgres” user does not have a password, you should set it yourself.

$ \password postgres

$ mkdir fsharpapplication

$ cd fsharpapplication

$ dotnet new console --language F#

Run the app:-

$ dotnet run