DEV Community: Štefan Belopotočan

F# DSLs: what they are, why they matter, and how they improve Betfair BotTrigger strategies

Štefan Belopotočan — Fri, 16 Jan 2026 14:28:28 +0000

A domain‑specific language (DSL) is a small, focused language that expresses the concepts of a particular problem area directly. In F#, DSLs are often embedded inside the host language using computation expressions, records, and functions. This approach gives you the clarity of a custom language while keeping full access to the F# type system, tooling, and libraries.

Why use an F# DSL?

Express intent, not plumbing. A DSL lets you write code that reads like the strategy you want to execute, not the mechanics of how to execute it.
Better composability. Steps can be chained, reused, and combined safely, which helps avoid duplicated logic.
Stronger correctness. Types guide you toward valid combinations and make invalid states harder to represent.
Improved testability. Strategy steps can be evaluated separately, with deterministic inputs and outputs.

How this helps with Betfair BotTrigger strategies

In BotTrigger workflows, Execute() is called on every market update. That means you want the per‑tick work to be minimal and the strategy definition to be clear and reusable.

By introducing a computation expression DSL, the strategy becomes a pipeline of what to do rather than how to do it each time. The example below defines:

A TriggerContext that packages market and selection data once.
A Trigger<'a> type that describes a step in the strategy.
A computation expression builder (trigger) that sequences steps and short‑circuits when a step fails.

This leads to a clean separation between strategy definition and execution, and it allows you to reuse the same strategy pipeline across updates without rebuilding it each time.

Building the DSL

Let's start by defining our core types and the computation expression builder:

[<AutoOpen>]
module BotTriggerDSL =

    type TriggerContext =
        {
            Market : Market
            Selection : Selection
            BotName : string
            Parameters : BotTriggerParameters
            MyBfexplorer : IMyBfexplorer
        }

    type Trigger<'a> = TriggerContext -> option<'a>

    type TriggerBuilder () =
        member _.Return (value : 'a) : Trigger<'a> = fun _ -> Some value
        member _.ReturnFrom (step : Trigger<'a>) : Trigger<'a> = step
        member _.Bind (step : Trigger<'a>, next : 'a -> Trigger<'b>) : Trigger<'b> =
            fun ctx ->
                match step ctx with
                | Some value -> next value ctx
                | None -> None

        member _.Zero () : Trigger<unit> = fun _ -> Some ()
        member _.Combine (first : Trigger<unit>, second : Trigger<'a>) : Trigger<'a> =
            fun ctx ->
                match first ctx with
                | Some () -> second ctx
                | None -> None

        member _.Delay (f : unit -> Trigger<'a>) : Trigger<'a> =
            fun ctx -> f () ctx

    let trigger = TriggerBuilder ()

The key insight here is that Trigger<'a> is just a function from TriggerContext to option<'a>. This simple definition gives us:

Composability: Steps can be chained using let! in the computation expression.
Short‑circuiting: If any step returns None, the pipeline stops immediately.
Pure functions: Each step is deterministic and testable in isolation.

Helper functions for common operations

Now we add helper functions that work within our DSL:

    let param (name : string) (fallback : 'a) : Trigger<'a> =
        fun ctx ->
            ctx.Parameters.GetParameter<'a>(name)
            |> defaultArg <| fallback
            |> Some

    let favouriteSelectionInRange (fromPrice : float) (toPrice : float) : Trigger<Selection> =
        fun ctx ->
            getFavouriteSelections ctx.Market
            |> List.tryFind (fun mySelection ->
                let price = mySelection.LastPriceTraded
                price >= fromPrice && price <= toPrice
            )

    let toTriggerResult (step : Trigger<'a>) (onSome : 'a -> TriggerResult) (onNone : TriggerResult) : TriggerContext -> TriggerResult =
        fun ctx ->
            match step ctx with
            | Some value -> onSome value
            | None -> onNone

These helpers demonstrate how to:

Extract parameters safely (param)
Filter selections based on criteria (favouriteSelectionInRange)
Convert our DSL result to Betfair's TriggerResult type (toTriggerResult)

Putting it all together

Here's the complete BotTrigger implementation using our DSL:

module BotTrigger =

    type MyStrategyBotTrigger (market : Market, selection : Selection, botName : string, botTriggerParameters : BotTriggerParameters, myBfexplorer : IMyBfexplorer) =
        inherit BotTriggerBase (market, selection, botName, botTriggerParameters, myBfexplorer)

        let ctx =
            {
                TriggerContext.Market = market
                TriggerContext.Selection = selection
                TriggerContext.BotName = botName
                TriggerContext.Parameters = botTriggerParameters
                TriggerContext.MyBfexplorer = myBfexplorer
            }

        let strategy =
            trigger {
                let! fromPrice = param "FromPrice" 2.5
                let! toPrice = param "ToPrice" 3.0
                let! mySelection = favouriteSelectionInRange fromPrice toPrice

                return mySelection
            }

        let runStrategy =
            toTriggerResult                                
                strategy
                TriggerResult.ExecuteActionBotOnSelection
                (TriggerResult.EndExecutionWithMessage "No selection fulfills my criteria.")                

        interface IBotTrigger with

            member _this.Execute () =
                runStrategy ctx

            member _this.EndExecution () =
                ()

Notice how the strategy reads like a high‑level description:

Get the fromPrice parameter (default 2.5)
Get the toPrice parameter (default 3.0)
Find a favourite selection in that price range
Return that selection

The key performance benefit is that ctx, strategy, and runStrategy are all constructed once when the trigger instance is created. Each time Execute() is called (on every market update), we simply run the pre‑built pipeline. No allocations, no rebuilding—just execution.

Summary

An F# DSL lets you model Betfair strategies as small, composable building blocks. In the BotTrigger scenario, it improves readability, reduces repeated work per market update, and keeps the intent of the strategy front‑and‑center. The result is a more maintainable and performant strategy layer that scales as your trading logic grows.

Hello Betfair: The Same Strategy in F#, C#, VB.NET, and an AI Prompt (bfexplorer)

Štefan Belopotočan — Thu, 15 Jan 2026 22:55:22 +0000

bfexplorer lets you automate trading strategies in a few different “shapes”:

F# script (or DLL): run a BotTrigger directly from .fsx source (and yes, you can also compile F# to a DLL)
C# / VB.NET plugin: compile a DLL and load it into bfexplorer
AI prompt: describe the logic in natural language and let an LLM execute it via bfexplorer’s MCP integration

This post uses the same “Hello Betfair” strategy idea in all approaches with one main goal: help you see the code differences (syntax, interop, and packaging) while keeping the trading logic constant.

The strategy logic

From the repo’s HelloBetfair overview, the core rule is:

Place a back bet (or execute an action bot) if a selection price is within a given range.

In the code examples below the default range is 2.5 to 3.0 (inclusive). The trigger looks for a suitable selection (favourites in these examples) and either:

executes an action on that selection, or
ends with a message if nothing matches.

Where the examples live

Overview: ../../src/HelloBetfair/README.md
F# script: ../../src/HelloBetfair/FSharp/MyStrategyBotTrigger.fsx
C# trigger: ../../src/HelloBetfair/CSharp/MyStrategyBotTrigger/MyStrategyBotTrigger.cs
VB.NET trigger: ../../src/HelloBetfair/VisualBasic/MyStrategyBotTrigger/MyStrategyBotTrigger.vb
AI prompt: ../../src/HelloBetfair/AI/MyStrategy.md

1) F# — shortest code, runs from source

bfexplorer is built with F#, and it supports F# scripting. That means you can execute a BotTrigger directly from the .fsx file.

If you prefer a compiled workflow, you can also package an F# trigger as a DLL assembly (similar to the C#/VB.NET examples). The nice part is that you get to choose: script for iteration speed, DLL for deployment/versioning.

Here’s the HelloBetfair F# example:

module BotTrigger

#I @"C:\Program Files\BeloSoft\Bfexplorer\"

#r "BeloSoft.Data.dll"
#r "BeloSoft.Bfexplorer.Domain.dll"
#r "BeloSoft.Bfexplorer.Service.Core.dll"
#r "BeloSoft.Bfexplorer.Trading.dll"

open BeloSoft.Bfexplorer.Domain
open BeloSoft.Bfexplorer.Trading

type MyStrategyBotTrigger (market : Market, selection : Selection, botName : string, botTriggerParameters : BotTriggerParameters, myBfexplorer : IMyBfexplorer) =
    inherit BotTriggerBase (market, selection, botName, botTriggerParameters, myBfexplorer)

    let getMySelection () =
        let fromPrice = defaultArg (botTriggerParameters.GetParameter<float> ("fromPrice")) 2.5
        let toPrice = defaultArg (botTriggerParameters.GetParameter<float> ("toPrice")) 3.0

        getFavouriteSelections market
        |> List.tryFind (fun mySelection -> 
                let price = mySelection.LastPriceTraded

                price >= fromPrice && price <= toPrice
            )

    interface IBotTrigger with

        member _this.Execute () =
            match getMySelection () with
            | Some mySelection -> TriggerResult.ExecuteActionBotOnSelection mySelection
            | None -> TriggerResult.EndExecutionWithMessage "No selection fulfills my criteria."

        member _this.EndExecution () =
            ()

What I like about this one:

No DLL build: iterate fast
the selection filtering reads cleanly (tryFind + pattern matching)
parameter defaults are one-liners (defaultArg ... 2.5)

2) C# — same logic, packaged as a DLL

In C#, you implement the same IBotTrigger interface, but you compile the project to a DLL.

HelloBetfair C# trigger:

using BeloSoft.Bfexplorer.Domain;
using BeloSoft.Bfexplorer.Trading;
using Microsoft.FSharp.Core;

namespace MyStrategyBotTrigger
{
    public class MyStrategyBotTrigger(Market market, Selection selection, string botName, BotTriggerParameters botTriggerParameters, IMyBfexplorer myBfexplorer) 
        : IBotTrigger
    {
        private (double FromPrice, double ToPrice) GetParameters()
        {
            var fromPriceOption = botTriggerParameters.GetParameter<double>("FromPrice");
            var toPriceOption = botTriggerParameters.GetParameter<double>("ToPrice");

            var fromPrice = FSharpOption<double>.get_IsSome(fromPriceOption) ? fromPriceOption.Value : 2.5;
            var toPrice = FSharpOption<double>.get_IsSome(toPriceOption) ? toPriceOption.Value : 3.0;

            return (fromPrice, toPrice);
        }

        private Selection GetMySelection()
        {
            var (fromPrice, toPrice) = GetParameters();

            return MarketExtensionsModule.getFavouriteSelections(market)
                .FirstOrDefault(s => s.LastPriceTraded >= fromPrice && s.LastPriceTraded <= toPrice);
        }

        public TriggerResult Execute()
        {
            var mySelection = GetMySelection();

            if (mySelection != null)
            {
                return TriggerResult.NewExecuteActionBotOnSelection(mySelection);
            }
            else
            {
                return TriggerResult.NewEndExecutionWithMessage("No selection fulfills my criteria.");
            }
        }

        public void EndExecution()
        {
        }
    }
}

Two very “real-world” details show up here:

bfexplorer APIs expose F# option, so you’ll see FSharpOption<T> interop
the parameter names are FromPrice / ToPrice (PascalCase)

3) Visual Basic — same DLL workflow, different syntax

VB.NET is functionally the same as the C# approach: you build a DLL and load it.

HelloBetfair VB.NET trigger:

Imports BeloSoft.Bfexplorer.Domain
Imports BeloSoft.Bfexplorer.Trading
Imports Microsoft.FSharp.Core

Public Class MyStrategyBotTrigger
    Implements IBotTrigger

    Private ReadOnly _market As Market
    Private ReadOnly _selection As Selection
    Private ReadOnly _botName As String
    Private ReadOnly _botTriggerParameters As BotTriggerParameters
    Private ReadOnly _myBfexplorer As IMyBfexplorer

    Public Sub New(market As Market, selection As Selection, botName As String, botTriggerParameters As BotTriggerParameters, myBfexplorer As IMyBfexplorer)
        _market = market
        _selection = selection
        _botName = botName
        _botTriggerParameters = botTriggerParameters
        _myBfexplorer = myBfexplorer
    End Sub

    Private Function GetParameters() As (FromPrice As Double, ToPrice As Double)
        Dim fromPriceOption = _botTriggerParameters.GetParameter(Of Double)("FromPrice")
        Dim toPriceOption = _botTriggerParameters.GetParameter(Of Double)("ToPrice")

        Dim fromPrice = If(OptionModule.IsSome(fromPriceOption), fromPriceOption.Value, 2.5)
        Dim toPrice = If(OptionModule.IsSome(toPriceOption), toPriceOption.Value, 3.0)

        Return (fromPrice, toPrice)
    End Function

    Private Function GetMySelection() As Selection
        Dim parameters = GetParameters()

        Dim fromPrice = parameters.FromPrice
        Dim toPrice = parameters.ToPrice

        Return MarketExtensionsModule.getFavouriteSelections(_market) _
            .FirstOrDefault(Function(s) s.LastPriceTraded >= fromPrice AndAlso s.LastPriceTraded <= toPrice)
    End Function

    Public Function Execute() As TriggerResult Implements IBotTrigger.Execute
        Dim mySelection = GetMySelection()

        If mySelection IsNot Nothing Then
            Return TriggerResult.NewExecuteActionBotOnSelection(mySelection)
        Else
            Return TriggerResult.NewEndExecutionWithMessage("No selection fulfills my criteria.")
        End If
    End Function

    Public Sub EndExecution() Implements IBotTrigger.EndExecution
    End Sub
End Class

4) AI prompt — describe the intent, let bfexplorer/MCP execute

The AI example in the repo is a prompt file. It’s not trying to be a full programming language replacement; it’s a fast way to express intent and run it on the active market.

HelloBetfair AI prompt:

On the currently active Betfair market, sort the market selections by price in ascending order. 

Immediately execute the 'Bet 10 Euro' strategy on the first selection whose price is between 2.5 and 3.0 (inclusive). 

If there is no selection in this price range, do not execute any bet. 

Do not ask for further user confirmation—proceed automatically according to these criteria.

Notice this one intentionally differs from the code examples:

it sorts selections by price
it uses the same range ($[2.5, 3.0]$)
it executes a named strategy (“Bet 10 Euro”) on the first match

That’s actually a feature: prompts are great for quickly trying an idea, then “promoting” it into an F#/C#/VB trigger once it proves useful.

Practical notes (things that bite people)

Here are the real “interop” details you’ll notice when you compare the three codebases:

Parameters are just string keys: botTriggerParameters.GetParameter<T>(name) looks up a string in a dictionary. Pick names you like (for example FromPrice/ToPrice) and keep them consistent across languages.
F# discriminated unions (DU) show up as generated classes in C#/VB: TriggerResult is an F# DU. In F# you return DU cases directly (e.g. TriggerResult.ExecuteActionBotOnSelection mySelection). In C#/VB you construct the DU using generated helpers (e.g. TriggerResult.NewExecuteActionBotOnSelection(mySelection) / NewEndExecutionWithMessage(...)).
F# option types require interop: when you read optional values from F#, C#/VB will see FSharpOption<T> (or use OptionModule.IsSome(...) in VB). That’s why the C#/VB examples look a bit more “ceremonial” around parameters.
Trigger vs execution separation is intentional: these examples return ExecuteActionBotOnSelection rather than placing orders inline. In bfexplorer, that separation often makes strategies easier to reuse and test (selection logic in the trigger, execution rules in the action bot).

Wrap-up

The point of this “Hello Betfair” example is the side-by-side comparison.

When you scan the three implementations, focus on these differences:

Expression of the same rule: F# uses List.tryFind + pattern matching; C#/VB use LINQ-style FirstOrDefault + if.
F# DU / option interop: TriggerResult and option feel native in F#, but become generated classes/helpers in C#/VB.
Packaging and workflow: .fsx is great for iteration; DLLs are great when you want a compiled artifact (and you can choose either approach in F#).
AI prompt as a contrast: it’s not about syntax at all—it’s about describing intent and letting bfexplorer/MCP drive execution.

If you want, tell me how you build/load DLL triggers in your setup (or point me to the solution files), and I’ll add a short “Build & load” section with the exact steps.

Trading involves risk. Test in a safe environment first. This post is for educational purposes only.

FSI First: Why AI Should Query Types Directly When Vibe Coding

Štefan Belopotočan — Sat, 27 Dec 2025 17:44:15 +0000

Background: Discovering FSI MCP

My app uses F# scripting extensively, so I regularly read F# Advent articles organized by Sergey Tihon at the end of the year to check for new ideas. Since my app already uses MCP (Model Context Protocol), I was particularly inspired by jvaneyck's article: FSI MCP: Injecting AI Coding Agents into My F# REPL Workflow.

This article opened my eyes to the possibilities of FSI MCP in my use case, and I decided to explore how it could improve my AI-assisted workflow. What I discovered was both enlightening and concerning—AI assistants don't always use the best tools available to them.

The Incident

I asked my AI assistant a simple question while working on a football betting script:

"What properties can I use to create rules for the FootballMatch type?"

The AI responded with a comprehensive list of properties... but got the types wrong. It said HomeScore was int16 when it's actually Byte. It searched documentation and made assumptions instead of checking the actual source.

When I pushed back with "Really do check all types," the AI finally used FSI (F# Interactive) to inspect the actual assembly and gave me the correct answer.

What Went Wrong

The AI fell into a common trap when working with .NET types:

Searched documentation first - Found older/incomplete info
Made assumptions - Guessed at types based on similar code
Provided plausible but wrong answers - Looked correct but wasn't accurate

This is the opposite of what should happen when you have FSI MCP tools available.

What Should Have Happened

When I asked about FootballMatch properties, the AI should have immediately:

#I @"C:\Program Files\BeloSoft\Bfexplorer\";;
#r "BeloSoft.Bfexplorer.FootballScoreProvider.dll";;

open System.Reflection;;
open BeloSoft.Bfexplorer.FootballScoreProvider.Models;;

let footballMatchType = typeof<FootballMatch>;;
let properties = footballMatchType.GetProperties(
    BindingFlags.Public ||| BindingFlags.Instance);;

properties |> Array.iter (fun p -> 
    printfn "%s : %s" p.Name p.PropertyType.Name);;

This gives the authoritative, accurate, current answer directly from the loaded assembly.

The Correct Answer

Using FSI revealed the actual types:

// CORRECT (via FSI):
HomeScore : Byte          // Not int16!
AwayScore : Byte
ScoreDifference : SByte   // Signed byte, not int16
Goals : Byte
GoalBeingScored : Boolean // Bonus property I missed!
MatchTime : Int32
Status : String
// ... etc

Why FSI First Matters for "Vibe Coding"

"Vibe coding" with AI means working fluidly, asking questions, and letting the AI figure out implementation details. But accuracy matters:

❌ Documentation-First Approach

Documentation can be outdated
Assumptions lead to subtle bugs
Wrong types cause runtime errors
Wastes time fixing mistakes

✅ FSI-First Approach

Authoritative: Queries the actual loaded assembly
Current: Always reflects the real code
Complete: Shows all members, even undocumented ones
Fast: Instant feedback from REPL

The FSI-First Rule for AI Assistants

When a user asks about .NET types in a workspace with FSI MCP tools:

ALWAYS:

Use FSI to inspect the type first
Get the actual properties/methods/types
Then provide the answer with confidence

NEVER:

Search documentation first
Assume types based on similar code
Guess at property names or types

Lessons for Non-Developers

If you're working with an AI to explore F#/.NET code:

1. Demand FSI Verification

When asking about types, explicitly request:

"Use FSI to show me the actual properties of [TypeName]"

2. Question Assumptions

If the AI provides type information without showing FSI output, ask:

"Did you check this with FSI, or are you guessing?"

3. Trust But Verify

Even experienced AIs can fall into documentation traps. FSI is your ground truth.

The Broader Principle

This incident reveals a key insight about AI-assisted development:

Tools exist for a reason. When you have FSI MCP tools, they're not just for convenience—they're for accuracy. The AI should prioritize direct type inspection over documentation search, every time.

Think of it like this:

Documentation = "Someone told me about this"
FSI = "Let me look at the actual source code right now"

Which would you trust more?

Practical Example: Building Better Filters

With the correct FSI-verified types, I can write accurate filters:

// Now I know Goals is Byte, not int16
let isHighScoring (match: FootballMatch) =
    match.Goals >= 5uy  // uy suffix for Byte, not y for int16

// And I discovered GoalBeingScored exists!
let isLiveGoal (match: FootballMatch) =
    match.GoalBeingScored && match.MatchTime > 70

// Correct type for ScoreDifference (SByte)
let isCloseMatch (match: FootballMatch) =
    abs match.ScoreDifference <= 1y  // y suffix for SByte

Conclusion

When vibe coding with AI in F#/.NET environments:

FSI First - Always query types directly with FSI MCP tools
Trust the REPL - It's the authoritative source
Document Later - Use docs for concepts, FSI for implementation
Call Out Mistakes - When AI doesn't use FSI, push back

The FSI MCP tools exist to eliminate guesswork. Use them first, not as a fallback.

Related Resources:

TL;DR: When AI has FSI tools, it should use them FIRST for type inspection, not search docs and guess. FSI = truth. Docs = hints.