<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Formal-Methods on Home</title>
    <link>https://blog.rafaelfernandez.dev/tags/formal-methods/</link>
    <description>Recent content in Formal-Methods on Home</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <copyright>© 2026 Rafael Fernandez</copyright>
    <lastBuildDate>Fri, 20 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.rafaelfernandez.dev/tags/formal-methods/index.xml" rel="self" type="application/rss+xml" />
    
    <item>
      <title>The Curry-Howard Correspondence: when types become proofs</title>
      <link>https://blog.rafaelfernandez.dev/posts/curry-howard-types-as-proofs/</link>
      <pubDate>Fri, 20 Mar 2026 00:00:00 +0000</pubDate>
      
      <guid>https://blog.rafaelfernandez.dev/posts/curry-howard-types-as-proofs/</guid>
      <description>Every well-typed program is a proof. Every type is a proposition. This is not a metaphor; it is a mathematical theorem discovered in the 1930s that explains why making invalid states unrepresentable actually works.</description>
      
    </item>
    
    <item>
      <title>Syntax and Semantics 3. The Expression Problem</title>
      <link>https://blog.rafaelfernandez.dev/posts/syntax-and-semantics-3-the-expression-problem/</link>
      <pubDate>Sat, 07 Feb 2026 00:00:00 +0000</pubDate>
      
      <guid>https://blog.rafaelfernandez.dev/posts/syntax-and-semantics-3-the-expression-problem/</guid>
      <description>Adding a new type is easy in OOP, hard in FP. Adding a new operation is easy in FP, hard in OOP. Philip Wadler named this the Expression Problem in 1998. We show how it manifests in Rust and Scala, and tease the resolution.</description>
      
    </item>
    
    <item>
      <title>Syntax and Semantics 2: Three ways to define what your code means</title>
      <link>https://blog.rafaelfernandez.dev/posts/syntax-and-semantics-2-three-ways-to-define-meaning/</link>
      <pubDate>Tue, 03 Feb 2026 00:00:00 +0000</pubDate>
      
      <guid>https://blog.rafaelfernandez.dev/posts/syntax-and-semantics-2-three-ways-to-define-meaning/</guid>
      <description>Your match expression is operational semantics. Your pure function is denotational semantics. Rust&amp;rsquo;s borrow checker is axiomatic semantics. Three formal frameworks, three ways to assign meaning to code, and you have been using all of them without knowing it.</description>
      
    </item>
    
    <item>
      <title>Syntax and Semantics 1: Your code has a grammar problem</title>
      <link>https://blog.rafaelfernandez.dev/posts/syntax-and-semantics-1-your-code-has-a-grammar-problem/</link>
      <pubDate>Fri, 30 Jan 2026 00:00:00 +0000</pubDate>
      
      <guid>https://blog.rafaelfernandez.dev/posts/syntax-and-semantics-1-your-code-has-a-grammar-problem/</guid>
      <description>Every enum you write is a formal grammar. Every sealed trait is a set of production rules. You have been doing formal methods all along; you just did not know the name. We trace the connection from Chomsky&amp;rsquo;s hierarchy to your domain types in Rust and Scala.</description>
      
    </item>
    
    <item>
      <title>Traits are grammars too: a small design lesson that kept nagging at me</title>
      <link>https://blog.rafaelfernandez.dev/posts/traits-are-grammars-too-from-contract-design-to-formal-syntax/</link>
      <pubDate>Wed, 28 Jan 2026 00:00:00 +0000</pubDate>
      
      <guid>https://blog.rafaelfernandez.dev/posts/traits-are-grammars-too-from-contract-design-to-formal-syntax/</guid>
      <description>While revisiting the TaskRepository trait from the Todo CLI series, I realized I was doing more than drawing an architectural boundary. I was also defining what could be said across that boundary, which is much closer to grammar than I first admitted.</description>
      
    </item>
    
  </channel>
</rss>
