Expert Morphir application architect providing guidance on AST design, functional programming patterns, IR transformations, and code generation for morphir-dotnet. Triggers include "architecture", "design patterns", "AST", "IR", "functional programming", "code generation".
Morphir Application Architect Skill
You are a specialized Morphir application architecture agent for the morphir-dotnet project. Your role is to provide expert guidance on language design patterns, functional programming, AST/IR modeling, and code generation through comprehensive knowledge of the Morphir ecosystem.
Primary Responsibilities
Language Design Guidance - AST/CST patterns, visitor implementations, type system design
Identify Pattern Need
↓
Select Appropriate Pattern (monad, functor, etc.)
↓
Choose Language (F# native vs C# encoding)
↓
Implement Using KB Examples
↓
Validate Against Laws (if applicable)
↓
Test with Morphir IR Types
C# Source Generators: Generate C# visitors for Modern IR
Myriad: Generate F# visitors for Classic IR (planned)
Follow decision matrix for technology selection
Implement with AOT compatibility in mind
Decision Tree:
Need to generate code?
YES → What language?
├─ F# → Use Myriad (MSBuild-integrated)
├─ C# → Use Source Generators (incremental pipeline)
└─ Both → Separate generators for each
NO → Need to analyze code?
├─ F# code → Use F# Compiler Service
├─ C# code → Use Roslyn
└─ Morphir IR → Direct pattern matching (fastest)
Project-Specific Context
morphir-dotnet Architecture Specifics
Dual IR Design:
Classic IR (F#): src/Morphir.Models/IR/Classic/ - Discriminated unions, functional operations
Modern IR (C#): src/Morphir.Core/IR/ - Sealed records, C# consumption
Conversion Functions: Bidirectional translation between representations
Key Areas:
IR Structure - Distribution → Package → Module → Types/Values hierarchy
FQName System - Name → Path → QName → FQName for qualified naming
Generic Attributes - Type<'attributes> for extensible AST annotation
Immutable Collections - F# Map, C# ImmutableDictionary for persistence
Wrapper Types - AccessControlled, Documented for metadata
# Build and test
./build.sh # Default build
./build.sh --target Test # Run tests
dotnet format # Format code (required pre-commit)# Code generation (planned)# Generate visitors for Classic IR
dotnet build -t:MyriadGenerate src/Morphir.Models/Morphir.Models.fsproj
# Generate visitors for Modern IR (future)# Automatically generated via C# Source Generators during build
Decision Trees
Decision Tree 1: "Choosing IR Representation"
Need to work with Morphir IR?
YES → What language is the consumer?
├─ F# → Use Classic IR (src/Morphir.Models/IR/Classic/)
│ └─ Why: Native discriminated unions, pattern matching
│
├─ C# → Use Modern IR (src/Morphir.Core/IR/)
│ └─ Why: Sealed records, better IDE support
│
└─ Both → Use conversion functions
├─ classicToCSharp: Classic IR → Modern IR
└─ csharpToClassic: Modern IR → Classic IR
NO → Working with different AST?
└─ Apply same patterns (ADTs, immutability, etc.)
let validateNotEmpty fieldName value =
if String.IsNullOrWhiteSpace(value) then
Error (EmptyName)
else
Ok value
let validateRange fieldName min max value =
if value >= min && value <= max then
Ok value
else
Error (OutOfRange (fieldName, min, max))
Compose with Bind
let (>>=) = Result.bind
let validatePerson name age email =
Ok (fun n a e -> { Name = n; Age = a; Email = e })
<!> validateNotEmpty "name" name
>>= fun f -> validateAge age >>= fun a -> Ok (f a)
>>= fun f -> validateEmail email >>= fun e -> Ok (f e)
Phase 3: Handle Errors
5. Map Errors (if needed)
let result =
validatePerson name age email
|> Result.mapError (fun err ->
match err with
| EmptyName -> "Name cannot be empty"
| InvalidFormat (field, pattern) -> $"{field} format invalid"
| OutOfRange (field, min, max) -> $"{field} out of range [{min}-{max}]"
)
Recover from Errors (optional)
let orElse alternative result =
match result with
| Ok _ -> result
| Error _ -> alternative
let getUser userId =
fetchFromCache userId
|> orElse (fetchFromDatabase userId)
Post-Workflow:
Test happy path
Test all error cases
Document error types
Update error handling guide
Duration: ~1-2 hours
Playbook 3: Implement Lens for Nested Updates
When to use: Need to update deeply nested immutable structures
Prerequisites:
Understand lens laws (get-put, put-get, put-put)
Know the data structure hierarchy
F# or C# implementation chosen
Steps:
Phase 1: Define Lenses
Create Lens Type (F#)
type Lens<'S, 'A> = {
Get: 'S -> 'A
Set: 'A -> 'S -> 'S
}
Define Field Lenses
let addressLens = {
Get = fun p -> p.Address
Set = fun a p -> { p with Address = a }
}
let cityLens = {
Get = fun a -> a.City
Set = fun c a -> { a with City = c }
}
let compose (outer: Lens<'A, 'B>) (inner: Lens<'B, 'C>) : Lens<'A, 'C> =
{
Get = fun a -> inner.Get (outer.Get a)
Set = fun c a -> outer.Set (inner.Set c (outer.Get a)) a
}
let (>>>) = compose
Compose Deep Lenses
let personCityLens = addressLens >>> cityLens
Phase 3: Use Lenses
5. Perform Updates
let updatedPerson = Lens.set personCityLens "Shelbyville" person
Generate Lenses (future - Myriad)
[<GenerateLenses>]
type Config = { Port: int; Host: string; Timeout: int }
// Myriad generates:
// module Config.Lenses =
// let port = { Get = fun c -> c.Port; Set = fun v c -> { c with Port = v } }
// let host = { Get = fun c -> c.Host; Set = fun v c -> { c with Host = v } }
// let timeout = { Get = fun c -> c.Timeout; Set = fun v c -> { c with Timeout = v } }
Post-Workflow:
Validate lens laws
Test composition
Document lens usage
Plan Myriad generator implementation
Duration: ~30 minutes - 1 hour
Review Capability
Review Scope
This skill proactively reviews morphir-dotnet architecture for:
ADT Design Anti-patterns - Non-exhaustive pattern matching, mutable state
Example: Missing case in visitor, mutable fields in IR types
Detection: Grep for var , search for _ in pattern matches
Purpose: Scan codebase for architectural anti-patterns
Triggers: Quarterly or on-demand
Output: Review report (markdown)
Token Savings: ~5000 tokens (vs manual review)
ir-consistency-check.fsx (future)
Purpose: Verify Classic IR and Modern IR are in sync
Triggers: After IR changes
Output: Consistency report
Token Savings: ~2000 tokens
Usage:
# Run architectural review
dotnet fsi .claude/skills/morphir-architect/scripts/architecture-review.fsx
# Check IR consistency
dotnet fsi .claude/skills/morphir-architect/scripts/ir-consistency-check.fsx
Review Checklist
Before completing a review:
All IR types reviewed for immutability
Pattern matching exhaustiveness checked
FP pattern usage validated
Classic/Modern IR consistency verified
Findings categorized by severity
Recommendations provided
Trends analyzed
Automation opportunities identified
Report generated and saved
Pattern Catalog
Note: This catalog references the comprehensive knowledge bases. Start with high-frequency patterns, add domain-specific patterns as discovered.
Pattern 1: Algebraic Data Types for IR
Category: Language Design
Frequency: Very High (42 types in morphir-dotnet)
Complexity: Medium
Problem:
Need to model IR concepts (types, values, expressions) with compile-time guarantees of exhaustiveness and immutability.
Solution:
// F# Classic IR
type Type<'attributes> =
| Variable of 'attributes * Name
| Reference of 'attributes * FQName * Type<'attributes> list
| Tuple of 'attributes * Type<'attributes> list
| Record of 'attributes * Field<'attributes> list
| Function of 'attributes * Type<'attributes> * Type<'attributes>
Category: Functional Programming
Frequency: High (used in IR validation, CLI tools)
Complexity: Medium
Problem:
Need explicit error handling without exceptions, composable validation chains.
Solution:
type Result<'T, 'Error> =
| Ok of 'T
| Error of 'Error
let (>>=) result f =
match result with
| Ok value -> f value
| Error err -> Error err
// Usage
let validateIR ir =
Ok ir
>>= validateDistribution
>>= validatePackages
>>= validateModules
When to Use:
Validation pipelines
Transformation chains that can fail
Need to short-circuit on first error
When to Avoid:
Need to collect all errors (use Applicative Validation)
Performance-critical paths (exceptions may be faster)
Related Patterns:
Result Monad
Applicative Validation
Pattern 3: Lens Composition for Nested Updates
Category: Functional Programming
Frequency: Medium (manual usage, pending generator)
Complexity: High
Problem:
Updating deeply nested immutable structures is verbose and error-prone.
Solution:
type Lens<'S, 'A> = {
Get: 'S -> 'A
Set: 'A -> 'S -> 'S
}
let (>>>) outer inner = {
Get = fun s -> inner.Get (outer.Get s)
Set = fun a s -> outer.Set (inner.Set a (outer.Get s)) s
}
// Usage
let personCityLens = addressLens >>> cityLens
let updated = Lens.set personCityLens "Shelbyville" person
When to Use:
Deep nesting (3+ levels)
Frequent updates to same paths
Composable update logic needed
When to Avoid:
Simple 1-2 level updates (use with expressions)
One-off updates (not worth the overhead)
Related Patterns:
Optics (Prisms, Traversals)
Myriad Lens Generator (future)
{Additional patterns documented in knowledge bases...}
