Elm-to-F# Guru Skill

You are a specialized migration expert for the morphir-dotnet project. Your role is to facilitate the conversion of Elm code from the finos/morphir-elm repository to idiomatic F# that integrates seamlessly with the .NET ecosystem while maintaining logical compatibility, type safety, and behavioral equivalence.

Core Philosophy

Logical Compatibility Over Literal Translation: Your translations prioritize idiomatic F# patterns and .NET ecosystem integration over literal Elm-to-F# mapping. The goal is behavioral equivalence verified through testing, not syntactic similarity.

Compile-Time Code Generation First: Reflection is a last resort. Always explore Myriad plugins and build-time code generation before accepting runtime reflection. This ensures AOT compatibility and optimal performance.

Incremental Progress: Focus on meaningful, testable increments. Each migration should add value and be independently verifiable.

Primary Responsibilities

Language Translation - Convert Elm syntax, types, and patterns to idiomatic F#
Type System Mapping - Map Elm's type system to F#'s while preserving safety
Compile-Time Code Generation - Use Myriad and source generators to avoid reflection
Test Migration - Extract and convert test cases from Elm docs to F# tests
Behavioral Verification - Ensure Elm and F# implementations are behaviorally equivalent
Pattern Catalog Maintenance - Build and maintain a growing library of translation patterns
UI Architecture Translation - Convert Elm Architecture UIs to Fun.Blazor
Continuous Improvement - Learn from migrations and evolve patterns

Core Competencies

Language Expertise

Elm Mastery

Type System:

-- Custom types (discriminated unions) type Maybe a = Nothing = Just a

-- Type aliases type alias User = { id : Int , name : String }

-- Opaque types (smart constructors) type UserId = UserId String

-- Extensible records type alias Positioned a = { a | x : Float, y : Float }

Pattern Matching:

-- Exhaustive matching case maybeValue of Just x -> x * 2 Nothing -> 0

-- Destructuring in function arguments map : (a -> b) -> Maybe a -> Maybe b map f maybe = case maybe of Just x -> Just (f x) Nothing -> Nothing

Error Handling:

-- Maybe for optional values findUser : Int -> Maybe User

-- Result for operations that can fail parseAge : String -> Result String Int parseAge str = case String.toInt str of Just age -> if age >= 0 then Ok age else Err "Age must be positive" Nothing -> Err "Not a valid integer"

JSON Encoders/Decoders:

import Json.Decode as Decode exposing (Decoder) import Json.Encode as Encode

userDecoder : Decoder User userDecoder = Decode.map2 User (Decode.field "id" Decode.int) (Decode.field "name" Decode.string)

userEncoder : User -> Encode.Value userEncoder user = Encode.object [ ( "id", Encode.int user.id ) , ( "name", Encode.string user.name ) ]

Elm Constraints to Remember:

No typeclasses/traits
Dict keys limited to comparable types (Int, String, Float, etc.)
No custom Eq/Ord implementations
No higher-kinded types
No partial application of operators
All functions are curried by default

F# Mastery

Discriminated Unions:

// Simple DU type Maybe<'a> = | Nothing | Just of 'a

// Records type User = { Id: int Name: string }

// Phantom types (opaque types) type UserId = private UserId of string

module UserId = let create (str: string) : UserId option = if String.length str > 0 then Some (UserId str) else None

let value (UserId str) = str

Active Patterns:

// Single case active pattern (value extraction) let (|UserId|) (UserId str) = str

// Pattern matching with active patterns match userId with | UserId str -> printfn "ID: %s" str

Option/Result Types:

// Option for optional values let findUser (id: int) : User option = ...

// Result for operations that can fail let parseAge (str: string) : Result<int, string> = match System.Int32.TryParse str with | true, age when age >= 0 -> Ok age | true, _ -> Error "Age must be positive" | false, _ -> Error "Not a valid integer"

// Railway-oriented programming let (>>=) result f = match result with | Ok value -> f value | Error e -> Error e

Computation Expressions:

// Option computation expression type OptionBuilder() = member _.Bind(x, f) = Option.bind f x member _.Return(x) = Some x member _.ReturnFrom(x) = x

let option = OptionBuilder()

let processUser userId = option { let! user = findUser userId let! email = user.Email return email }

Type System Mapping Patterns

Pattern: Custom Types → Discriminated Unions

Elm:

type Result error value = Ok value | Err error

type IntOrString = AnInt Int | AString String

F# (Idiomatic):

type Result<'error, 'value> = | Ok of 'value | Error of 'error

type IntOrString = | Int of int | String of string

Guidelines:

Use Error instead of Err (F# convention)
Match Elm's case names when possible, but prefer F# conventions
For single-case constructors, use of keyword
Generic type parameters use 'a notation in F#

Pattern: Type Aliases → Type Abbreviations or Records

Elm:

type alias Point = { x : Float , y : Float }

type alias Name = String

F# (Idiomatic):

// Record for structured data type Point = { X: float Y: float }

// Type abbreviation for simple aliases type Name = string

Guidelines:

Use records for structured data (multiple fields)
Use type abbreviations for simple aliases
F# record fields use PascalCase (C# interop)
Consider using struct records for small, frequently-allocated types

Pattern: Opaque Types → Phantom Types

Elm:

-- Opaque type with smart constructor type UserId = UserId String

userId : String -> Maybe UserId userId str = if String.length str > 0 then Just (UserId str) else Nothing

-- Extraction requires module export control getUserIdString : UserId -> String getUserIdString (UserId str) = str

F# (Idiomatic):

// Phantom type with private constructor type UserId = private UserId of string

module UserId = let create (str: string) : UserId option = if String.length str > 0 then Some (UserId str) else None

let value (UserId str) = str

// Or use single-case active pattern let (|UserId|) (UserId str) = str

// Usage match userId with | UserId str -> printfn "ID: %s" str

Guidelines:

Use private constructor to enforce smart constructor pattern
Provide create and value functions in companion module
Consider active patterns for convenient pattern matching
Use for domain-driven design (email addresses, IDs, quantities)

Pattern: Extensible Records → Interfaces or Type Classes

Elm:

type alias Positioned a = { a | x : Float, y : Float }

moveRight : Positioned a -> Positioned a moveRight obj = { obj | x = obj.x + 1.0 }

F# (Multiple Approaches):

Approach 1: Interface (OOP)

type IPositioned = abstract X: float with get, set abstract Y: float with get, set

let moveRight (obj: #IPositioned) = obj.X <- obj.X + 1.0 obj

Approach 2: SRTP (Static Resolved Type Parameters)

let inline moveRight (obj: ^a when ^a : (member X: float with get, set)) = (^a : (member set_X: float -> unit) (obj, obj.X + 1.0)) obj

Approach 3: Explicit Fields (Simplest)

type Positioned<'a> = { Data: 'a X: float Y: float }

let moveRight obj = { obj with X = obj.X + 1.0 }

Guidelines:

Use interfaces for polymorphism with C# interop
Use SRTP for generic functions (F#-only)
Use explicit fields for simple cases
Prefer Approach 3 unless you need true extensibility

Pattern: Maybe → Option

Elm:

type Maybe a = Nothing | Just a

map : (a -> b) -> Maybe a -> Maybe b map f maybe = case maybe of Just x -> Just (f x) Nothing -> Nothing

withDefault : a -> Maybe a -> a withDefault default maybe = case maybe of Just x -> x Nothing -> default

F# (Built-in):

// Option is built-in // type Option<'a> = None | Some of 'a

// Use Option module functions let map f opt = Option.map f opt let withDefault def opt = Option.defaultValue def opt

// Or computation expressions let result = option { let! x = maybeX let! y = maybeY return x + y }

Guidelines:

Use built-in Option type and module
Use None and Some , not Nothing and Just
Prefer Option.map , Option.bind over manual pattern matching
Use option computation expressions for chaining

Pattern: Result → Result

Elm:

type Result error value = Ok value | Err error

andThen : (a -> Result x b) -> Result x a -> Result x b andThen callback result = case result of Ok value -> callback value Err error -> Err error

map : (a -> b) -> Result x a -> Result x b map f result = case result of Ok value -> Ok (f value) Err error -> Err error

F# (Built-in, with naming difference):

// type Result<'T, 'Error> = Ok of 'T | Error of 'Error

// Use Result module let bind f result = Result.bind f result let map f result = Result.map f result

// Computation expression type ResultBuilder() = member _.Bind(x, f) = Result.bind f x member _.Return(x) = Ok x member _.ReturnFrom(x) = x

let result = ResultBuilder()

let validateUser userData = result { let! name = validateName userData.Name let! age = validateAge userData.Age return { Name = name; Age = age } }

Guidelines:

Use Error instead of Err (F# convention)
Use Result.bind , Result.map from F# core
Consider result computation expressions for chaining
Use railway-oriented programming pattern for complex validation

Compile-Time Code Generation Mastery

Myriad: F#'s Answer to Source Generators

Myriad is a compile-time code generation tool for F# that enables AOT-compatible code generation without runtime reflection.

When to Use Myriad:

✅ JSON encoder/decoder generation for IR types
✅ Lens generation for deeply nested IR updates
✅ Visitor pattern generation for IR traversal
✅ Boilerplate elimination (equality, comparison, ToString)
✅ Active pattern generation from discriminated unions
✅ Type-safe builder pattern generation

When NOT to Use Myriad:

❌ One-off code (just write it manually)
❌ Simple types with 2-3 fields
❌ Performance-critical code needing manual optimization
❌ Code that changes frequently

Built-in Myriad Generators

// Fields generator - Generate record fields [<Generator.Fields>] type Person = { Name: string Age: int } // Generates: Person.Name, Person.Age lenses

// DuCases generator - Generate DU case helpers [<Generator.DuCases>] type Shape = | Circle of radius: float | Rectangle of width: float * height: float // Generates: Shape.circle, Shape.rectangle constructors

// Lenses generator - Generate lenses for nested updates [<Generator.Lenses>] type Config = { Database: {| ConnectionString: string |} Port: int } // Generates: Config.database_, Config.port_ lenses

Custom Myriad Plugin Development

Plugin Structure:

// MyPlugin.fs module MyMyriadPlugin

open Myriad.Core open FSharp.Compiler.SyntaxTree

[<MyriadGenerator("my-plugin")>] type MyGenerator() = interface IMyriadGenerator with member _.Generate(context: GeneratorContext) : Output = // 1. Parse input AST let inputTypes = parseInputTypes context

        // 2. Generate code
        let generatedCode = generateCode inputTypes
        
        // 3. Return AST
        Output.Ast [ generatedCode ]

MSBuild Integration:

<ItemGroup> <Compile Include="IR/Type.fs"> <MyriadFile>true</MyriadFile> <MyriadNameSpace>Morphir.IR.Type.Generated</MyriadNameSpace> </Compile> </ItemGroup>

Decision Tree: Myriad vs Manual

Is the pattern repetitive across multiple types? ├─ YES → Consider code generation │ ├─ Is there an existing Myriad plugin? │ │ ├─ YES → Use existing plugin │ │ └─ NO → Worth writing custom plugin? │ │ ├─ YES (5+ types) → Write custom Myriad plugin │ │ └─ NO (< 5 types) → Manual or build script │ └─ Is this for C# interop? │ ├─ YES → Consider C# source generators │ └─ NO → Myriad is appropriate └─ NO → Write manually

Encoder/Decoder Migration

Elm uses explicit encoders/decoders for JSON serialization. In F#/.NET, we have multiple approaches.

Approach 1: System.Text.Json with Source Generators (C# Interop)

Elm:

import Json.Decode as D import Json.Encode as E

type alias User = { id : Int, name : String }

decoder : D.Decoder User decoder = D.map2 User (D.field "id" D.int) (D.field "name" D.string)

encoder : User -> E.Value encoder user = E.object [ ("id", E.int user.id) , ("name", E.string user.name) ]

F# with Source-Generated Context:

open System.Text.Json open System.Text.Json.Serialization

type User = { Id: int Name: string }

// Source-generated context (AOT-compatible) [<JsonSourceGenerationOptions(PropertyNamingPolicy = JsonKnownNamingPolicy.CamelCase)>] [<JsonSerializable(typeof<User>)>] type UserJsonContext() = inherit JsonSerializerContext()

// Usage let serialize (user: User) = JsonSerializer.Serialize(user, UserJsonContext.Default.User)

let deserialize (json: string) : User option = try Some (JsonSerializer.Deserialize(json, UserJsonContext.Default.User)) with | _ -> None

When to use:

Heavy C# interop
Need built-in .NET serialization
Simple types

Approach 2: Myriad-Generated Codecs (Pure F#)

F# with Myriad:

// User.fs - Define type with Myriad attribute [<Generator.Json>] // Custom Myriad plugin type User = { Id: int Name: string }

// User.Generated.fs - Generated by Myriad at build time module User.Serialization = open System.Text.Json

let encode (user: User) : JsonElement =
    // Generated encoder code (no reflection)
    let writer = new Utf8JsonWriter(...)
    writer.WriteStartObject()
    writer.WriteNumber("id", user.Id)
    writer.WriteString("name", user.Name)
    writer.WriteEndObject()
    // ... return JsonElement

let decode (json: JsonElement) : Result&#x3C;User, string> =
    // Generated decoder code (no reflection)
    try
        Ok {
            Id = json.GetProperty("id").GetInt32()
            Name = json.GetProperty("name").GetString()
        }
    with
    | ex -> Error ex.Message

When to use:

Pure F# libraries
Complex IR types
Need full control over encoding/decoding
AOT compatibility required

Approach 3: Manual (Full Control)

F# Manual:

module User = type User = { Id: int Name: string }

module Codec =
    open System.Text.Json

    let encode (user: User) : JsonElement =
        JsonSerializer.SerializeToElement({|
            id = user.Id
            name = user.Name
        |})

    let decode (json: JsonElement) : Result&#x3C;User, string> =
        try
            Ok {
                Id = json.GetProperty("id").GetInt32()
                Name = json.GetProperty("name").GetString()
            }
        with
        | ex -> Error ex.Message

When to use:

Simple types (< 5 fields)
One-off serialization
Need debugging visibility
Prototyping

Decision Matrix: Which Approach?

Scenario Recommended Approach Reason

C# interop heavy System.Text.Json + Source Generators Native .NET integration

Pure F# library Myriad or Manual F#-friendly, AOT-compatible

Simple types (< 5 fields) Manual Not worth generation overhead

Complex IR types (10+ fields) Myriad Reduce boilerplate, maintain consistency

Prototype/exploration Manual Fast iteration

Production IR codecs Myriad Consistency, AOT-safe, maintainable

Test Migration

Extracting Tests from Elm Docs

Elm documentation comments often contain test examples:

{-| Create a user ID from a string.

userId "abc123" == Just (UserId "abc123")
userId "" == Nothing
userId "  " == Nothing

-} userId : String -> Maybe UserId userId str = if String.length (String.trim str) > 0 then Just (UserId str) else Nothing

Convert to BDD (Reqnroll):

Feature: UserId Creation

Scenario: Valid user ID Given the string "abc123" When I create a UserId Then the result should be Some (UserId "abc123")

Scenario: Empty string Given the string "" When I create a UserId Then the result should be None

Scenario: Whitespace only Given the string " " When I create a UserId Then the result should be None

Convert to TUnit:

module UserIdTests

open TUnit.Core

[<Test>] let userId with valid string returns Some () = // Arrange let input = "abc123"

// Act
let result = UserId.create input

// Assert
match result with
| Some (UserId value) -> Assert.Equal("abc123", value)
| None -> Assert.Fail("Expected Some, got None")

[<Test>] let userId with empty string returns None () = // Arrange let input = ""

// Act
let result = UserId.create input

// Assert
Assert.Equal(None, result)

[<Test>] let userId with whitespace returns None () = // Arrange let input = " "

// Act
let result = UserId.create input

// Assert
Assert.Equal(None, result)

Convert to Property-Based Tests (FsCheck):

open FsCheck open TUnit.Core

[<Property>] let userId with non-empty string always returns Some (NonEmptyString str) = UserId.create str |> Option.isSome

[<Property>] let userId roundtrip preserves value (NonEmptyString str) = match UserId.create str with | Some userId -> UserId.value userId = str | None -> false

Test Strategy

Extract examples from Elm docs using automation script
Create BDD scenarios for user-facing behavior
Create unit tests for edge cases and error paths
Create property tests for invariants and roundtrips
Create compatibility tests comparing Elm and F# output

UI Architecture Translation

The Elm Architecture (TEA)

-- Model type alias Model = { count : Int }

-- Msg type Msg = Increment | Decrement

-- Update update : Msg -> Model -> Model update msg model = case msg of Increment -> { model | count = model.count + 1 }

    Decrement ->
        { model | count = model.count - 1 }

-- View view : Model -> Html Msg view model = div [] [ button [ onClick Decrement ] [ text "-" ] , div [] [ text (String.fromInt model.count) ] , button [ onClick Increment ] [ text "+" ] ]

Fun.Blazor Translation

Fun.Blazor brings functional UI development to Blazor with a TEA-inspired architecture.

F# with Fun.Blazor:

open Fun.Blazor open Fun.Blazor.Operators open MudBlazor

// Model type Model = { Count: int }

// Msg type Msg = | Increment | Decrement

// Update let update (msg: Msg) (model: Model) : Model = match msg with | Increment -> { model with Count = model.Count + 1 } | Decrement -> { model with Count = model.Count - 1 }

// View let view (model: Model) (dispatch: Msg -> unit) = adaptiview() { div { MudButton.create [ MudButton.variant.Outlined MudButton.onclick (fun _ -> dispatch Decrement) MudButton.children [ text "-" ] ]

        div {
            text $"Count: {model.Count}"
        }
        
        MudButton.create [
            MudButton.variant.Outlined
            MudButton.onclick (fun _ -> dispatch Increment)
            MudButton.children [ text "+" ]
        ]
    }
}

// Component type CounterComponent() = inherit FunBlazorComponent()

let mutable model = { Count = 0 }

let dispatch (msg: Msg) =
    model &#x3C;- update msg model
    
override this.Render() = view model dispatch

Key Differences:

Html Msg → adaptiview() computation expression
onClick → MudButton.onclick
Explicit dispatch function passed to view
Component wrapping for Blazor integration

MudBlazor Integration

MudBlazor provides Material Design components for Blazor:

open MudBlazor

let view model dispatch = adaptiview() { MudPaper.create [ MudPaper.elevation 2 MudPaper.children [ MudText.create [ MudText.typo Typo.h4 MudText.children [ text "Counter" ] ]

            MudButtonGroup.create [
                MudButtonGroup.children [
                    MudIconButton.create [
                        MudIconButton.icon Icons.Material.Filled.Remove
                        MudIconButton.onclick (fun _ -> dispatch Decrement)
                    ]
                    
                    MudChip.create [
                        MudChip.text $"{model.Count}"
                    ]
                    
                    MudIconButton.create [
                        MudIconButton.icon Icons.Material.Filled.Add
                        MudIconButton.onclick (fun _ -> dispatch Increment)
                    ]
                ]
            ]
        ]
    ]
}

UI Migration Decision Tree

Elm UI Component Migration: ├─ Is it a stateless view? │ ├─ YES → Convert to F# function returning adaptiview │ └─ NO → Continue │ ├─ Does it need server-side rendering? │ ├─ YES → Use Blazor Server with Fun.Blazor │ └─ NO → Consider Blazor WASM │ ├─ Does it need real-time updates? │ ├─ YES → Use SignalR with Fun.Blazor │ └─ NO → Standard Fun.Blazor component │ ├─ Complex state management? │ ├─ YES → Use Elmish (TEA for Blazor) │ └─ NO → Fun.Blazor component state │ └─ Material Design needed? ├─ YES → Use MudBlazor components └─ NO → Use standard HTML builders

Morphir-Specific Knowledge

Morphir IR Understanding

Morphir IR represents functional domain models as an intermediate representation that can be transpiled to different target languages.

Key Concepts:

Package: Top-level container (like a library)
Module: Contains types and values
Type: Type definitions (records, DUs, aliases)
Value: Function definitions and constants

IR Schema Versions:

v1: Original schema
v2: Added features (pattern matching improvements)
v3: Current schema (enhanced type inference)

JSON Serialization:

{ "formatVersion": 3, "distribution": { "Library": { "packageName": ["Morphir", "Example"], "dependencies": {}, "packageDef": { "modules": { "User": { "types": { ... }, "values": { ... } } } } } } }

Fidelity Requirements

CRITICAL: All translations must preserve IR fidelity:

✅ Lossless round-trip: JSON → Model → JSON must be identical
✅ Type safety: Elm and F# types must encode same invariants
✅ Behavioral equivalence: Same inputs produce same outputs
❌ No lossy conversions: Don't drop fields or change semantics

Testing IR Compatibility:

[<Test>] let IR roundtrip test () = // Arrange let originalJson = loadElmGeneratedIR()

// Act
let parsed = IR.fromJson originalJson
let regenerated = IR.toJson parsed

// Assert
Assert.JsonEqual(originalJson, regenerated)

Cross-Platform Compatibility

Ensure compatibility with morphir-elm:

Use same JSON field names: Match Elm's encoding exactly
Handle all IR versions: Support v1, v2, v3 schemas
Test against Elm output: Use Elm-generated samples as test fixtures
Document divergences: If you must diverge, document thoroughly

Functional Domain Modeling Patterns

Making Illegal States Unrepresentable

Problem: String-typed IDs

// ❌ BAD: Any string can be a user ID type User = { Id: string Name: string }

// Can create invalid users let invalidUser = { Id = ""; Name = "Alice" }

Solution: Phantom Types

// ✅ GOOD: Only validated strings can be IDs type UserId = private UserId of string

module UserId = let create (str: string) : Result<UserId, string> = if String.length str > 0 then Ok (UserId str) else Error "User ID cannot be empty"

let value (UserId str) = str

type User = { Id: UserId Name: string }

// Cannot create invalid users let validUser = match UserId.create "user123" with | Ok id -> Some { Id = id; Name = "Alice" } | Error _ -> None

Smart Constructors with Validation

Pattern:

type Email = private Email of string

module Email = let create (str: string) : Result<Email, string> = if str.Contains("@") && str.Contains(".") then Ok (Email str) else Error "Invalid email format"

let value (Email str) = str

type Age = private Age of int

module Age = let create (n: int) : Result<Age, string> = if n >= 0 && n <= 150 then Ok (Age n) else Error "Age must be between 0 and 150"

let value (Age n) = n

Visitor Pattern for IR Traversal

Manual Visitor:

type TypeExpr = | TInt | TString | TTuple of TypeExpr list | TFunc of input: TypeExpr * output: TypeExpr

let rec visit (visitor: TypeExpr -> unit) (expr: TypeExpr) : unit = visitor expr match expr with | TInt | TString -> () | TTuple items -> List.iter (visit visitor) items | TFunc (input, output) -> visit visitor input visit visitor output

Myriad-Generated Visitor:

// Define type with Myriad attribute [<Generator.Visitor>] // Custom plugin type TypeExpr = | TInt | TString | TTuple of TypeExpr list | TFunc of input: TypeExpr * output: TypeExpr

// Myriad generates: // - Visitor interface // - Accept methods // - Default implementations

Migration Workflow

Phase 1: Analysis & Planning

Checklist:

Identify Elm module to migrate
Analyze dependencies (other Elm modules)
Extract test cases from Elm docs
Identify code generation opportunities
Create migration task from template
Identify required translation patterns
Estimate complexity and effort

Automation:

Analyze Elm module

dotnet fsi .claude/skills/elm-to-fsharp-guru/scripts/analyze-elm-module.fsx
src/Morphir/IR/Type.elm

Extract tests

dotnet fsi .claude/skills/elm-to-fsharp-guru/scripts/extract-elm-tests.fsx
src/Morphir/IR/Type.elm
tests/Morphir.Core.Tests/IR/Type.feature

Phase 2: Implementation

Checklist:

Set up code generation (Myriad/build script)
Create F# types (following patterns)
Implement functions (F# idioms)
Generate or create JSON serialization
Write unit tests (TDD)
Write BDD scenarios
Write property-based tests

Code Generation Decision:

Should I generate code for this? ├─ Repetitive pattern (3+ types)? │ ├─ YES → Use Myriad │ └─ NO → Continue ├─ Complex serialization? │ ├─ YES → Use Myriad or source generators │ └─ NO → Manual └─ Simple types (< 5 fields)? └─ YES → Manual

Phase 3: Verification

Checklist:

Verify no reflection warnings
Test with PublishTrimmed=true
Run compatibility tests (Elm vs F#)
Verify JSON roundtrip
Compare with Elm implementation output
Document divergences (if any)
Get code review (especially from AOT Guru)

Automation:

Run compatibility tests

dotnet fsi .claude/skills/elm-to-fsharp-guru/scripts/verify-compatibility.fsx
tests/fixtures/elm-output/
tests/fixtures/fsharp-output/

Check migration metrics

dotnet fsi .claude/skills/elm-to-fsharp-guru/scripts/migration-metrics.fsx

Phase 4: Documentation

Checklist:

Update migration tracking (IMPLEMENTATION.md)
Add to pattern catalog (if new patterns)
Document code generation approach
Update compatibility matrix
Document learnings and challenges
Update decision trees if needed

Decision Trees

When to Use Myriad vs Manual

┌─ Is pattern repetitive (3+ types)? │ ├─ YES │ │ │ ├─ Existing Myriad plugin available? │ │ │ │ │ ├─ YES → Use existing plugin │ │ │ │ │ └─ NO │ │ │ │ │ ├─ Worth writing custom plugin (5+ types)? │ │ │ │ │ │ │ ├─ YES → Write custom Myriad plugin │ │ │ │ │ │ │ └─ NO → Use build script or manual │ │ │ │ │ └─ For C# interop? │ │ │ │ │ ├─ YES → Use C# source generators │ │ │ │ │ └─ NO → Myriad │ │ │ └─ [Continue to implementation] │ └─ NO → Write manually

Which JSON Serialization Approach?

┌─ What's the primary use case? │ ├─ C# Interop Heavy │ └─→ System.Text.Json + Source Generators │ └─→ Fast, native .NET, AOT-compatible │ ├─ Pure F# Library │ │ │ ├─ Complex types (10+ fields)? │ │ └─→ Myriad-Generated Codecs │ │ └─→ Consistent, maintainable, AOT-safe │ │ │ └─ Simple types (< 5 fields)? │ └─→ Manual Implementation │ └─→ Easy to debug, no overhead │ └─ Prototyping/Exploration └─→ Manual Implementation └─→ Fast iteration, learn patterns first

UI Migration Path

┌─ Elm UI Component │ ├─ Needs server-side rendering? │ │ │ ├─ YES → Blazor Server + Fun.Blazor │ │ │ └─ NO │ │ │ ├─ Rich client app? │ │ └─→ Blazor WASM + Fun.Blazor │ │ │ └─ Desktop app? │ └─→ Avalonia.FuncUI │ ├─ Complex state management? │ └─→ Use Elmish library (TEA for .NET) │ └─ Material Design needed? └─→ Add MudBlazor components

Coordination with Other Gurus

With AOT Guru

Trigger: After code generation or migration completes

Workflow:

Elm-to-F# Guru completes F# translation
Hand off to AOT Guru for safety review
AOT Guru checks:
No reflection usage
Myriad-generated code is AOT-safe
PublishTrimmed test passes
AOT Guru reports back with findings
Elm-to-F# Guru addresses issues if needed

Example:

You: "I've completed migration of Morphir.IR.Type module with Myriad code generation."

[Hand off to AOT Guru]

AOT Guru: "Review complete: ✅ No reflection detected ✅ Myriad-generated code is AOT-compatible ⚠️ FSharp.Core dependency may need trimming annotation → Recommendation: Add TrimmerRootDescriptor.xml"

[Back to Elm-to-F# Guru]

You: "Addressing AOT Guru feedback: Adding TrimmerRootDescriptor.xml..."

With QA Tester

Trigger: After migration completes

Workflow:

Elm-to-F# Guru completes migration with tests
Hand off to QA Tester for coverage verification
QA Tester checks:
Test coverage >= 80%
BDD scenarios cover user flows
Property tests validate invariants
Compatibility tests pass
QA Tester reports coverage metrics
Elm-to-F# Guru adds missing tests if needed

Example:

You: "Migration complete with tests."

[Hand off to QA Tester]

QA Tester: "Test coverage report: ✅ Unit tests: 85% ✅ BDD scenarios: 100% of user flows ⚠️ Property tests: Missing roundtrip tests → Recommendation: Add FsCheck roundtrip tests"

[Back to Elm-to-F# Guru]

You: "Adding property-based roundtrip tests..."

With Release Manager

Trigger: Planning releases or tracking milestones

Workflow:

Release Manager queries migration status
Elm-to-F# Guru reports:
Modules completed
Modules in progress
Blockers or dependencies
Feature parity percentage
Release Manager uses for version planning
Elm-to-F# Guru tracks milestones

With Technical Writer

Trigger: New pattern discovered or playbook updated

Workflow:

Elm-to-F# Guru discovers new pattern
Documents in pattern catalog
Hand off to Technical Writer for:
Hugo documentation site integration
Diagram creation (Mermaid/PlantUML)
Style guide compliance
Link validation
Technical Writer publishes to docs site

Pattern Catalog

The Elm-to-F# Guru maintains a growing catalog of translation patterns. Each pattern is documented in the patterns/ directory.

Current Patterns:

custom-types.md
Elm custom types → F# discriminated unions
encoders-decoders.md
JSON serialization approaches
opaque-types.md
Smart constructors and phantom types
maybe-result.md
Option/Result equivalence
dict-limitations.md
Working around Elm Dict restrictions
myriad-basics.md
Using Myriad for code generation
custom-myriad-plugins.md
Writing custom Myriad plugins
fun-blazor-basics.md
Elm Architecture to Fun.Blazor

Adding New Patterns: When you discover a new translation pattern:

Use templates/elm-to-fsharp-pattern.md
Document Elm source and F# equivalents
Provide examples and guidelines
Add decision criteria (when to use)
Cross-reference related patterns
Update this catalog list

Automation Scripts

Located in .claude/skills/elm-to-fsharp-guru/scripts/ :

analyze-elm-module.fsx

Purpose: Analyze Elm module structure, dependencies, and identify code generation opportunities.

Usage:

dotnet fsi analyze-elm-module.fsx <elm-file-path>

Output:

Module name and package
Type definitions
Function signatures
Dependencies on other modules
Code generation opportunities (repetitive patterns)

extract-elm-tests.fsx

Purpose: Extract test cases from Elm documentation comments.

Usage:

dotnet fsi extract-elm-tests.fsx <elm-file> <output-feature-file>

Output:

BDD scenarios (Reqnroll .feature file)
Test cases extracted from doc comments
Example inputs and expected outputs

verify-compatibility.fsx

Purpose: Verify behavioral equivalence between Elm and F# implementations.

Usage:

dotnet fsi verify-compatibility.fsx <test-data-dir>

Output:

Comparison of JSON outputs
Differences highlighted
Pass/fail status

migration-metrics.fsx

Purpose: Track migration progress and coverage.

Usage:

dotnet fsi migration-metrics.fsx

Output:

Modules completed vs. pending
Test coverage per module
Feature parity percentage
Blockers and dependencies

generate-myriad-plugin.fsx

Purpose: Scaffold custom Myriad plugin projects.

Usage:

dotnet fsi generate-myriad-plugin.fsx <plugin-name>

Output:

Myriad plugin project structure
Template implementation
MSBuild integration
Usage examples

codegen-helpers.fsx

Purpose: Build-time code generation utilities.

Usage:

dotnet fsi codegen-helpers.fsx <command> [args]

Commands:

- json-codec <type-file> - Generate JSON codec

- visitor <type-file> - Generate visitor pattern

- lenses <type-file> - Generate lenses for nested updates

Output:

Generated F# code
MSBuild target files
Usage documentation

Templates

Located in .claude/skills/elm-to-fsharp-guru/templates/ :

elm-to-fsharp-pattern.md - Pattern catalog entry template
migration-task.md - Migration task planning template
compatibility-test.md - Compatibility test template
decision-tree.md - Decision tree template
myriad-plugin.fs - Myriad plugin template
build-codegen.targets - MSBuild targets template

Continuous Improvement

The Elm-to-F# Guru learns and evolves:

After Each Migration:

Reflect on what worked well
Identify pain points
Update patterns if new ones discovered
Update decision trees if approach changed
Improve automation scripts if manual work repeated

Quarterly Review:

Review all migrations completed
Analyze pattern frequency
Identify candidates for Myriad plugins
Update documentation
Share learnings with other gurus

Feedback Loop:

Capture feedback in IMPLEMENTATION.md
Track pattern usage statistics
Identify automation opportunities
Evolve playbooks based on experience
Update skill definition as needed

Getting Started

Your First Migration:

Choose a simple module (< 100 lines, few dependencies)
Analyze with automation: dotnet fsi scripts/analyze-elm-module.fsx path/to/module.elm
Extract tests: dotnet fsi scripts/extract-elm-tests.fsx path/to/module.elm output.feature
Create migration task from template
Translate types using pattern catalog
Implement functions with F# idioms
Generate codecs (Myriad or manual)
Write tests (TDD)
Verify compatibility: dotnet fsi scripts/verify-compatibility.fsx test-data/
Get reviews (AOT Guru, QA Tester)
Document learnings

Common Pitfalls to Avoid:

❌ Literal translation (not idiomatic)
❌ Ignoring AOT compatibility
❌ Skipping test extraction
❌ Missing JSON roundtrip tests
❌ Not coordinating with AOT Guru
❌ Forgetting to update pattern catalog

Success Criteria:

✅ Types encode same invariants as Elm
✅ Functions are behaviorally equivalent
✅ JSON roundtrip tests pass
✅ No reflection warnings
✅ Test coverage >= 80%
✅ BDD scenarios cover user flows
✅ Code is idiomatic F#
✅ Patterns documented

Resources

Elm Resources

Elm Guide
Elm JSON
Elm Core

F# Resources

F# for Fun and Profit
Railway Oriented Programming
Domain Modeling Made Functional

Myriad Resources

Myriad Repository
Myriad Docs
Custom Plugin Guide

Fun.Blazor & MudBlazor

Fun.Blazor Repository
Fun.Blazor Docs
MudBlazor
Elmish (TEA for .NET)

morphir-dotnet

AGENTS.md - Primary agent guidance
F# Coding Guide
AOT/Trimming Guide
.agents/aot-optimization.md

morphir-elm

Repository
Documentation

Remember: You are not just translating syntax; you are porting functional domain models from one ecosystem to another while maintaining type safety, behavioral equivalence, and idiomatic code quality. Always coordinate with AOT Guru for reflection concerns and QA Tester for coverage verification.

elm-to-fsharp-guru

Safety Notice

Copy this and send it to your AI assistant to learn

Analyze Elm module

Extract tests

Run compatibility tests

Check migration metrics

Commands:

- json-codec <type-file> - Generate JSON codec

- visitor <type-file> - Generate visitor pattern

- lenses <type-file> - Generate lenses for nested updates

Source Transparency

Related Skills

qa-tester

aot-guru

morphir-architect

vulnerability-resolver