https://fallible.net Zola en Mon, 16 Dec 2024 00:00:00 +0000 Everyone's a Syndicate Mon, 16 Dec 2024 00:00:00 +0000 Unknown https://fallible.net/projects/syndicate/ https://fallible.net/projects/syndicate/ <p><a href="https://syndicate.fallible.net">"Everyone's a Syndicate"</a> is an RSS/Atom CORS proxy & HTML renderer. It provides the bridge for in-browser RSS/Atom feed readers, and has an HTML rendering endpoint if you want to do as little work as possible building an RSS reader.</p> <p>This is not a new way of doing things, people have done things like this before. Right now, I can't find ones that encourage "community".</p> <p>Here's a reader for a bunch of cohost users:</p> <div> <sub><a href="https://syndicate.fallible.net">Everyone's a Syndicate</a></sub> <script type="text/javascript"> function everyones_a_syndicate_update_cohost() { // Set the style let style = "\<style\>" + [...document.styleSheets].map((styleSheet) => { try { return [...styleSheet.cssRules].map((rule) => rule.cssText).join(""); } catch (e) {} }).filter(Boolean).join("\n") + "\</style\>"; document.getElementById('place-here-cohost').setAttribute("srcdoc", style); // Fetch the rendered HTML. return fetch("https://syndicate.fallible.net/poll_feeds_rendered", { method: "POST", headers: new Headers({'content-type': 'application/json'}), body: JSON.stringify({feeds: ["https://fallible.net/rss.xml", "https://nickyflowers.com/feed.xml", "https://shelraphen.com/rss/", "https://blog.dante.cool/feed/?type=rss", "https://blog.someplace-else.xyz/feed/?type=rss", "https://buttondown.com/HTHR/rss", "https://www.alexanderbjoy.com/feed?type=rss"], show_mode: 'EqualChronoShuffle'}), }) .then(result => result.text()) .then(body => { // pre-append the style to the value of the document.getElementById('place-here-cohost').setAttribute("srcdoc", style + body) }); } document.addEventListener("DOMContentLoaded", function(event){ everyones_a_syndicate_update_cohost(); }); </script> <iframe id="place-here-cohost" style="height: 20em"></iframe> </div> <p>And here's another for people involved in the Scottish gamedev scene:</p> <div> <sub><a href="https://syndicate.fallible.net">Everyone's a Syndicate</a></sub> <script type="text/javascript"> function everyones_a_syndicate_update_scotland_gamedev() { // Set the style let style = "\<style\>" + [...document.styleSheets].map((styleSheet) => { try { return [...styleSheet.cssRules].map((rule) => rule.cssText).join(""); } catch (e) {} }).filter(Boolean).join("\n") + "\</style\>"; document.getElementById('place-here-scotdev').setAttribute("srcdoc", style); // Fetch the rendered HTML. return fetch("https://syndicate.fallible.net/poll_feeds_rendered", { method: "POST", headers: new Headers({'content-type': 'application/json'}), body: JSON.stringify({feeds: ["https://www.collegefun.games/blog/rss", "https://raodaozao.net/feed/", "https://blog.someplace-else.xyz/feed/?type=rss", "https://sunny.garden/@clasticartistic.rss", "https://blog.fallible.net/feed?type=rss"], show_mode: 'EqualChronoShuffle'}), }) .then(result => result.text()) .then(body => { // pre-append the style to the value of the document.getElementById('place-here-scotdev').setAttribute("srcdoc", style + body) }); } document.addEventListener("DOMContentLoaded", function(event){ everyones_a_syndicate_update_scotland_gamedev(); }); </script> <iframe id="place-here-scotdev" style="height: 20em"></iframe> </div> <p>You'll notice some of these are not in <em>normal</em> reverse chronological order. One of the options for ordering posts is "Equal shuffle" which is "show everyone's most recent post first, shuffled together. Then everyone's second most recent post, shuffled. Then everyone's third most recent post, shuffled." and so on. This exists so that not posting frequently isn't a penalty.</p> <p>That is, if you post 50 times a day, your pal Ahmed posts 5 times a week, and your pal Belle posts 5 times a year, you won't drown out Belle and Ahmed with your posting.</p> <p>There's still an option for "Newest first"/Reverse chronological, so if you want to just have a Hosepipe.</p> <p>There's also a few options for CSS injection (or lack thereof) on the client-side. The default is "Copy all stylesheets from the main page and apply them to the iframe". This makes it look like it's in the right place in a lot of the places where you put it, like <a href="https://blog.fallible.net/everyones-a-syndicate/">Bear Blog</a>.</p> <p>In a time of AI scraping there might not be as many valid RSS feeds when picked up through a data centre hosted proxy, but this is a relatively simple way to enable more social websites, to make it feel like we're less alone on our little website islands.</p> Spaces are Moments, Not Abstract or Far Away Mon, 30 Sep 2024 00:00:00 +0000 Unknown https://fallible.net/projects/spaces-are-moments/ https://fallible.net/projects/spaces-are-moments/ <iframe frameborder="0" src="https://itch.io/embed/3008648" width="552" height="167"><a href="https://fallible.itch.io/spaces-are-moments">Spaces are moments, not abstract or far away. by Fallible Things</a></iframe> <p>"Spaces are moments" was my submission to my own game jam, <a href="https://itch.io/jam/pretentious">Pretentious jam</a>. I used godot, an aira S1, and the Lineal font. I massively regret participating in my own jam, and this game diverged quite a bit from my initial sketches, but I'm largely happy with where it ended up.</p> <p>This game is a poemware. Intentionally, you need to participate to be able to view the whole poem. At the end, there is a collection of some of the fragments that survive.</p> <p>Please play <a href="https://itch.io/jam/pretentious/entries">other peoples submissions to the jam.</a></p> Shortly Departing From Thu, 29 Feb 2024 00:00:00 +0000 Unknown https://fallible.net/projects/shortly-departing-from/ https://fallible.net/projects/shortly-departing-from/ <div class="iframe-center"><iframe frameborder="0" src="https://itch.io/embed/2551424" width="552" height="167"><a href="https://fallible.itch.io/shortly-departing-from">The Train Shortly Departing From Platform 33E3EE Is The 20:59 Service To Bristol-56 Temple 57-Meads-54 by Fallible Things</a></iframe></div> <p>"The Train Shortly Departing From Platform 33E3EE Is The 20:59 Service To Bristol-56 Temple 57-Meads-54" Was an entry to the <a href="https://itch.io/jam/lsdjam-2023">LSD Dream Emulator Anniversary Jam 2023</a>.</p> Outlining Typechecking for your Toy Language / Feeding the lambda calculus its own tail Fri, 01 Sep 2023 00:00:00 +0000 Unknown https://fallible.net/projects/types/ https://fallible.net/projects/types/ <script id="MathJax-script" async src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"></script> <script> MathJax = { tex: { inlineMath: [['$', '$'], ['\\(', '\\)']] } }; </script> <script type="module" src="/cohost-wc.js"></script> <link rel="stylesheet" href="/cohost-wc.css" /> <link rel="stylesheet", href="/atkinson.css" /> <p>This was originally a 2-part post on cohost.org, c'est la vie. I came to these methods from a lot of silent from-first-principles fiddling, but I expect others to have done them before too.</p> <p><strong><a href="https://fallible.net/projects/types/#pt2">Feeding the Lambda Calculus its own Tail</a></strong> is further down the page too.</p> <div id="pt1"> <cohost-post avatarsrc="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/4gIcSUNDX1BST0ZJTEUAAQEAAAIMbGNtcwIQAABtbnRyUkdCIFhZWiAH3AABABkAAwApADlhY3NwQVBQTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWxjbXMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApkZXNjAAAA/AAAAF5jcHJ0AAABXAAAAAt3dHB0AAABaAAAABRia3B0AAABfAAAABRyWFlaAAABkAAAABRnWFlaAAABpAAAABRiWFlaAAABuAAAABRyVFJDAAABzAAAAEBnVFJDAAABzAAAAEBiVFJDAAABzAAAAEBkZXNjAAAAAAAAAANjMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0ZXh0AAAAAEZCAABYWVogAAAAAAAA9tYAAQAAAADTLVhZWiAAAAAAAAADFgAAAzMAAAKkWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPY3VydgAAAAAAAAAaAAAAywHJA2MFkghrC/YQPxVRGzQh8SmQMhg7kkYFUXdd7WtwegWJsZp8rGm/fdPD6TD////bAEMA///////////////////////////////////////////////////////////////////////////////////////bAEMB///////////////////////////////////////////////////////////////////////////////////////AABEIAEAAQAMBIgACEQEDEQH/xAAWAAEBAQAAAAAAAAAAAAAAAAABAAL/xAAcEAEBAQEBAQADAAAAAAAAAAAAARESIWECMVH/xAAVAQEBAAAAAAAAAAAAAAAAAAAAAf/EABcRAQEBAQAAAAAAAAAAAAAAAAARASH/2gAMAwEAAhEDEQA/ADqrqsmBD18PXwYUpFvxagLMPU+rqBYqRmNifooqWIrE3WbMDd9jGBmpqBqIus6WWgXqQ06Q6NQUmEiQoM6dGX+LmqUhc1c0KjIp+NPolLOn1nKGP//Z" avatarshape="squircle" comments="2" displayname="Fallible Algebra" handle="fallible-algebra" originalurl="https://cohost.org/fallible-algebra/post/2660945-outlining-type-check" publishedat="2023-08-31T19:22:27.097Z" standaloneheadline="Outlining type checking for your toy language (and many others)" tags="programming language theory,type theory,programming languages,haskell,programming language development,rust,rust-lang,mathematics,I apologise for the recipe blog post style intro,computer science,maths,math,effortpost,The Cohost Global Feed,functional programming,lambda calculus,tutorial,compilers,PLT"><noscript>Post by Fallible Algebra (@fallible-algebra): Outlining type checking for your toy language (and many others)</noscript><div><div class="flex w-full flex-nowrap content-start justify-between"><button class="group relative w-full flex-initial" tabindex="0"><img src="/TypesHeader.jpg" class="h-full w-full object-cover" data-attachment-id="f75da206-7e5f-466d-a1b4-dce9ef055748" alt="A handwritten design document for a non-existent programming language called "MyLang". A dismissal of a type system for the language is in red pen." title="A handwritten design document for a non-existent programming language called "MyLang". A dismissal of a type system for the language is in red pen."></button></div></div><div class="co-prose prose my-4 overflow-hidden break-words px-3"><p>Like many who fall into building programming languages as personal projects or research rabbit holes, there was a period where I became obsessed with type systems, formal languages, the specifics of what the lambda calculus is and what other computational calculi are.</p> <p>One of my favourite things to do in programming languages with a strong type system is to find or otherwise design a type signature that leaves little room for "misuse". I am not unique in enjoying this, it's the premise of type-driven development and it's arguably one of the most interesting itches to scratch when you have a complex type system to play with.</p> <p>It is not unexpected to want to, once you understand a set of tools, turn those tools in on themselves. It feels smart, it feels satisfying, it feels like you're coming up against the limits of a concept. Sometimes this is a quagmire, where you just get lost trying to define things from their surroundings in a way which becomes circular or muddied or distressing, but with formal systems there's the clarity of playing in a sandbox.</p> <p>This post serves as an illustration of my favourite way of leveraging powerful type systems to make the path for adding type theories — specifically type checking and type inference — to toy formal language projects as clear as possible. To be clear: I am talking about <strong>outlining</strong> type checking, not <strong>implementing</strong> type checking. That's what you go on wikipedia and then google scholar and then JSTOR and other rabbit holes of research for. Or you follow your heart and decide to mess with these things from first-principles, as long as it's not in your heart purely to feel The Smartest Of All.</p></div><div class="co-prose prose my-4 overflow-hidden break-words px-3"><hr> <p>First things first, as we're talking about a typed language developed in a typed language, I'll be referring to them this way:</p> <ol> <li>Host language: The language we're writing things in, not the language we're designing. <ul> <li>Host type system: the type system of the host language, not the type system we're designing.</li> </ul> </li> <li>Toy<sup>1</sup> language: The language we're designing, not the language we're writing things in. <ul> <li>Toy type system: The type system we're designing, not the type system we're using while designing the type system.</li> </ul> </li> </ol> <p>The host language I'm using is haskell, which definitely isn't the most practical but I can leverage the host type system really well. I will also show how to do this in Rust, but that's more as an afterthought. What your host language will need is 1. <strong>Algebraic Data Types</strong> aka <strong>Enums but Fancy ✨</strong> and 2. <strong>Type Parameters</strong> aka <strong>Generics</strong> aka <strong>Parametric Polymorphism</strong>. These are the two features that tend to make a programming language theorist's heart swell three times its size anyway. Appropriate host languages might then be:</p> <ol> <li>Java 20 <a href="https://openjdk.org/jeps/409" target="_blank" rel="nofollow noopener" tabindex="0">(yes, really)</a></li> <li>Rust <ul> <li>Many ancestors of Rust, like OCaml</li> </ul> </li> <li>Haskell <ul> <li>Any number of haskell derivatives, i.e. Idris, Purescript</li> </ul> </li> </ol> <p>Again, I will be using Haskell but please don't let that scare you off. It's just the language that this can be done the easiest and taken to the furthest length in.</p> <h2>Your toy language</h2> <p>Where does your toy type system "live" in your toy language? This is a question you'll need to answer. I'll be illustrating with a lambda calculus, but this is not necessarily the foundation you'll go with. Here are some questions to ask yourself, if you haven't already:</p> <ol> <li>Do you have a point in the toy language where variables are explicitly introduced? Not all formal languages do.</li> <li>Are there constants in your toy language whose type can be manually defined by you?</li> <li>Are there constants in your toy type system that can be defined by you?</li> <li>Are there rules you want types to follow in your toy type system?</li> </ol> <p>This isn't an exhaustive list, I am not a type theorist and this is a blog post. Point is for this exercise, a language has a type system when its terms have types and those types have rules you follow. It's up to you to figure out how to do that, and it's up to you to see how the rules can be constructed and bent <sup>2</sup>.</p> <p>To illustrate asking these questions, I'll be using a lambda calculus (something we definitely know how to add a type system to), and asking these questions as I go through.</p> <h3>An example: a typed lambda calculus</h3> <p> $$\Lambda := var(v) | apply(\Lambda, \Lambda) | \lambda v:t. \Lambda $$ </p> <p>Fig: a half-remembered definition of a typed lambda calculus. Please don't get lost here, I promise it's not too spooky.</p> <p>The lambda calculus is... fine, fun, alright, good enough. And mathematical notation can be hard to decipher, so instead of the above alone here's a definition of it in the host language I'll be using:</p> <pre style="background-color: rgb(254, 254, 254); color: rgb(84, 84, 84); position: relative; padding: 0px; line-height: 1.2rem; margin-bottom: 0px;"><code style="padding: 0px 16px; display: block; margin-bottom: 9px; margin-top: 9px;"><span><span><span style="color: rgb(121, 40, 161);">data</span> <span style="color: rgb(170, 93, 0);">ToyType</span></span> <span style="color: dimgray;">-- When I refer to toy type expressions in the form `A -> B` I mean</span> <span style="color: dimgray;">-- effectively `Function "A" "B"`.`</span> = <span style="color: rgb(170, 93, 0);">Function</span> <span style="color: rgb(170, 93, 0);">ToyType</span> <span style="color: rgb(170, 93, 0);">ToyType</span> | ... <span style="color: dimgray;">-- Not defining all other parts of the type, there can be many.</span> <p><span><span style="color: rgb(121, 40, 161);">data</span> <span style="color: rgb(170, 93, 0);">LambdaCalc</span></span> = <span style="color: rgb(170, 93, 0);">Var</span> <span style="color: rgb(170, 93, 0);">String</span> | <span style="color: rgb(170, 93, 0);">Apply</span> <span style="color: rgb(170, 93, 0);">LambdaCalc</span> <span style="color: rgb(170, 93, 0);">LambdaCalc</span> | <span style="color: rgb(170, 93, 0);">Abstract</span> (<span style="color: rgb(170, 93, 0);">String</span>, <span style="color: rgb(170, 93, 0);">ToyType</span>) <span style="color: rgb(170, 93, 0);">LambdaCalc</span></span></code></pre><div style="text-align: right; font-size: min(1.87vw, 70%); opacity: 0.7; margin-bottom: 1.71429em;">made with <a data-testid="mention" href="https://cohost.org/nex3" class="!font-bold !no-underline hover:!underline" tabindex="0">@nex3</a>'s <a href="https://nex3.github.io/cohost-highlight" target="_blank" rel="nofollow noopener" tabindex="0">syntax highlighter</a></div></p> <p>This is pretty kosher, though using strings for variables is a bit too specific and perhaps gaudy. But before getting distracted by the taunt of perfection, let's ask those questions from before:</p> <ol> <li>Do you have a point in the toy language where variables are explicitly introduced? <ul> <li>Yes! <code>Abstract</code> plays the part of the lambda operator, introducing a new variable to an expression body.</li> </ul> </li> <li>Are there constants in your toy language whose type can be manually defined by you? <ul> <li>Hmm, no. This lambda calculus doesn't have constants. But, we could add them. We'd want a stronger way of differentiating between variables and constants if we did, mind.</li> </ul> </li> <li>Are there constants in your toy type system that can be defined by you? <ul> <li>Yes! At the very least, we've defined <code>Function</code> as a type that describes function types. The rest of the type system is left up to the imagination, but it could include explicit primitives like integers, etc.</li> </ul> </li> <li>Are there rules you want types to follow in your toy type system? <ul> <li>Yes! We want the following, in plain terms: <ul> <li>Variables have types, and those types are introduced at the same point as those variables: in the <code>Abstract</code> part of the syntax tree.</li> <li><code>Apply</code> reduces the type of its left expression if it's a function type, and its right expression should match the argument type of its left. In other words: <ul> <li>In our toy language we have two expressions <code>a</code> and <code>b</code>. <code>a</code> has type <code>X</code> and <code>b</code> has type <code>X -> Y</code>.</li> <li><code>Apply b a</code> should type check as having type <code>Y</code>, because we applied an expression of type <code>X</code> to a function of type <code>X -> Y</code>.</li> <li><code>Apply a b</code> should fail to type check, as we're trying to apply the expression <code>b</code> to the non-function expression <code>a</code></li> <li><code>Apply b b</code> should fail to type check, as we're trying to apply an expression of type <code>X -> Y</code> to a function of type <code>X -> Y</code>, which only takes arguments of type <code>X</code>.</li> </ul> </li> <li><code>Abstract</code> Introduces a variable as a parameter to an expression, making it a function. So if it introduces a variable <code>v</code> of type <code>X</code> into an expression whose type is <code>Z</code>, then the expression it forms has the type <code>X -> Z</code></li> </ul> </li> </ul> </li> </ol> <h2>Abstracting the toy type system</h2> <p>Another thing is that we don't want all types to always have to be annotated in every circumstance, as we can probably design a nice type inference algorithm.</p> <p>So what, do we then extend the <code>ToyType</code> type so there's a lack of a type as one of its possibilities? That sounds horrible, an introduction of <code>null</code> to our toy type system also removes the certainty that when a variable has a type it has a <em>type</em> and not just a hole for a type to be derived into.</p> <p>So do we then duplicate <code>LambdaCalc</code> into <code>PartiallyTypedLambdaCalc</code>? Where we replace <code>ToyType</code> with <code>Maybe ToyType</code>? That's also bizarre as a data structure design choice. In haskell, in typed functional programming languages, in well-typed languages overall we get trained into viewing things like this as things we can solve with the host type system. And yeah, there's a fairly obvious choice:</p> <pre style="background-color: rgb(254, 254, 254); color: rgb(84, 84, 84); position: relative; padding: 0px; line-height: 1.2rem;"><code style="padding: 0px 16px; display: block; margin-bottom: 9px; margin-top: 9px;"><span><span style="color: dimgray;">-- The toy type system is now a type parameter over our lambda calculus</span> <span style="color: dimgray;">-- in our host language implementation.</span> <span><span style="color: rgb(121, 40, 161);">data</span> <span style="color: rgb(170, 93, 0);">LambdaCalc</span> t =</span> <span style="color: rgb(170, 93, 0);">Var</span> <span style="color: rgb(170, 93, 0);">String</span> <span style="color: rgb(170, 93, 0);">Apply</span> (<span style="color: rgb(170, 93, 0);">LambdaCalc</span> t) (<span style="color: rgb(170, 93, 0);">LambdaCalc</span> t) <span style="color: rgb(170, 93, 0);">Abstract</span> (<span style="color: rgb(170, 93, 0);">String</span>, t) (<span style="color: rgb(170, 93, 0);">LambdaCalc</span> t) <span style="color: rgb(121, 40, 161);">deriving</span> (<span style="color: rgb(170, 93, 0);">Functor</span>, ...) <span style="color: dimgray;">-- oh we could derive so many things!</span></span></code></pre> <p>We even get to do things such as define an untyped lambda calculus as <code>LambdaCalc ()</code> using the Unit type. We get to define type erasure as just mapping <code>\a -> ()</code> over <code>LambdaCalc</code> because we can derive <code>Functor</code> (or implement it manually, pick your poison) for it in the host language.</p> <p>This is the point of typing things this way, we get more operations for free. We have to do less work overall and there are more rules that the compiler of the host language takes care of, instead of us making unchecked assumptions.</p> <p>This is also an small example of an instance where <code>Functor</code> does not mean "Container". It's an easy misstep, but this works as a dweeby illustration of <code>Functor</code>'s more nuanced semantics. Just because a data structure has a parameter does not mean it is supposed to be an alternative to an array, a set, a tree.</p> <h3>Aside: Context, $\Gamma$, Monads</h3> <p>If you go through papers and web pages on type theories, you'll come across $\Gamma$ in the definitions. This is the representation for "Context" aka <em>known and ongoing information</em> or perhaps the most loathed term of all: <em>state</em>. Thinking through how we might do type checking operations we can imagine that when doing type checking on some toy languages we want an ongoing collection of named known expressions and their known types.</p> <p>If we say that $(add\_one : Int \rightarrow Int) \in \Gamma$ we mean that in our context $\Gamma$ we know of a symbol <code>add_one</code> with the type <code>Int -> Int</code>.</p> <p>If we have a messy prototype complete with a helper function to parse basic type expressions then we could say that <code>typecheck_context.get("add_one") == parse_type("Int -> Int")</code> is true.</p> <p>In practice, $\Gamma$ is implemented in any number of ways. It could be that you're passing around a key-value map that you're passing to every function, or there's a global variable everything is referring to, or a database, or a server, or a web crawler that finds anything that looks like typed symbol, or anything your heart desires.</p> <p>Or, you could do what I'm doing in Haskell. In Haskell we have a very obvious tool for representing context aka ongoing information aka <em>state</em> that lets us dismiss all the explicit notation away: The monad. If you're not familiar with monads, just read this as "the way I'm accessing and modifying context". Or, watch <a href="https://www.youtube.com/watch?v=LekhueQ4zVU" target="_blank" rel="nofollow noopener" tabindex="0">this video</a>. Or, read <a href="https://web.archive.org/web/20210927150910/http://dev.stephendiehl.com/hask/index.html#monads" target="_blank" rel="nofollow noopener" tabindex="0">this blog post</a>. Or, try using promises and callbacks in javascript with the <code>then</code> method.</p> <p>The assumption from here on is that you know that when I talk about using monads in the host language of my choice, I'm talking about the structure that manages information that we know.</p> <pre style="background-color: rgb(254, 254, 254); color: rgb(84, 84, 84); position: relative; padding: 0px; line-height: 1.2rem;"><code style="padding: 0px 16px; display: block; margin-bottom: 9px; margin-top: 9px;"><span><span style="color: dimgray;">-- from the haskell package "mtl"</span> <span style="color: rgb(121, 40, 161);">import</span> Control.Monad.State.Lazy (<span style="color: rgb(170, 93, 0);">State</span>) <p><span style="color: dimgray;">-- Typechecking could plausibly involve reading/writing from disk, network. </span> <span style="color: dimgray;">-- But that's getting into the weeds. </span> <span style="color: dimgray;">-- As an example here, I'm using a state monad whose state is a key-value </span> <span style="color: dimgray;">-- map between symbol names and their types. This is not a prescription of </span> <span style="color: dimgray;">-- what your type checking context should be, only an example.</span> <span style="color: dimgray;">-- And really, this example is flawed as it also needs to support</span> <span style="color: dimgray;">-- erroring and returning without having found a type for the </span> <span style="color: dimgray;">-- expression as well.</span> <span><span style="color: rgb(121, 40, 161);">type</span> <span style="color: rgb(170, 93, 0);">ToyContextM</span> = <span style="color: rgb(170, 93, 0);">State</span> (<span style="color: rgb(170, 93, 0);">Map</span> <span style="color: rgb(170, 93, 0);">String</span> <span style="color: rgb(170, 93, 0);">ToyType</span>)</span></span></code></pre></p> <h2>Typing Type Checking</h2> <p>For me, the most important operation is <em>finding the type of a fully-typed expression</em>. If the type can be found, I know the following:</p> <ol> <li>The type of the expression overall (clearly).</li> <li>The type checking operation was successful.</li> <li>The types of any subexpressions, which may be added to the ongoing context.</li> </ol> <p>This gives us more information than some <code>isCorrectlyTyped :: Context -> LambdaCalc ToyType -> Bool</code> function might give us.</p> <p>So, we want an host language function that takes a toy language expression in its fully typed form and returns its type, plus any modifications to the context.</p> <pre style="background-color: rgb(254, 254, 254); color: rgb(84, 84, 84); position: relative; padding: 0px; line-height: 1.2rem;"><code style="padding: 0px 16px; display: block; margin-bottom: 9px; margin-top: 9px;"><span><span style="color: rgb(0, 127, 170);">typecheck</span> :: <span style="color: rgb(170, 93, 0);">LambdaCalc</span> <span style="color: rgb(170, 93, 0);">ToyType</span> -> <span style="color: rgb(170, 93, 0);">ToyContextM</span> <span style="color: rgb(170, 93, 0);">ToyType</span> <span style="color: rgb(0, 127, 170);">typecheck</span> expr = <span style="color: dimgray;">-- It'd take a lot of space here to write this all out. </span> <span style="color: dimgray;">-- But, I believe in you. You can do it!</span></span></code></pre> <h2>Typing Type Inference</h2> <p>We also can do something similar for type inference, which is an operation that takes a partially-typed expression and derives the types of the rest of the expression:</p> <pre style="background-color: rgb(254, 254, 254); color: rgb(84, 84, 84); position: relative; padding: 0px; line-height: 1.2rem;"><code style="padding: 0px 16px; display: block; margin-bottom: 9px; margin-top: 9px;"><span><span style="color: rgb(0, 127, 170);">infer</span> :: <span style="color: rgb(170, 93, 0);">LambdaCalc</span> (<span style="color: rgb(170, 93, 0);">Maybe</span> <span style="color: rgb(170, 93, 0);">ToyType</span>) -> <span style="color: rgb(170, 93, 0);">ToyContextM</span> (<span style="color: rgb(170, 93, 0);">LambdaCalc</span> <span style="color: rgb(170, 93, 0);">ToyType</span>) <span style="color: rgb(0, 127, 170);">infer</span> expr = <span style="color: dimgray;">-- It's true! Google hindley-milner type inference to find out more. </span></span></code></pre> <p>Which we can express really nicely in the type system because we made the type system a parameter to <code>LambdaCalc</code></p> <h2>Making a Typeclass/Trait/Interface</h2> <p>We have a structure, so let's be brash and make an assumption. Let's assume that all typed languages will work kind of the same way, or can be modified a little to work the same way. Let's assume we can make typeclasses that can encompass both inference and type checking analogously to how I've already presented them.</p> <p>This will depend on host language features, but in Haskell<sup>3</sup> it will look a bit like this:</p> <pre style="background-color: rgb(254, 254, 254); color: rgb(84, 84, 84); position: relative; padding: 0px; line-height: 1.2rem;"><code style="padding: 0px 16px; display: block; margin-bottom: 9px; margin-top: 9px;"><span><span style="color: rgb(170, 93, 0);">{-# LANGUAGE FunctionalDependencies #-}</span> <span> <span style="color: rgb(121, 40, 161);">class</span> <span style="color: rgb(170, 93, 0);">Monad</span> m => <span style="color: rgb(170, 93, 0);">Typecheck</span> m l t | l t -> m <span style="color: rgb(121, 40, 161);">where</span></span> <span style="color: dimgray;">-- Here we define a typechecking operation by asking for a </span> <span style="color: dimgray;">-- function which, when given a typed expression, returns </span> <span style="color: dimgray;">-- its type within some monadic context `m`. </span> typecheck :: l t -> m t <span> <span style="color: rgb(121, 40, 161);">class</span> (<span style="color: rgb(170, 93, 0);">Typecheck</span> <span style="color: rgb(0, 127, 170);">m</span> <span style="color: rgb(0, 127, 170);">l</span> <span style="color: rgb(0, 127, 170);">t</span>) => <span style="color: rgb(170, 93, 0);">Infer</span> m l t | l t -> m <span style="color: rgb(121, 40, 161);">where</span></span> <span style="color: dimgray;">-- Something that is inferrable must also be typecheckable,</span> <span style="color: dimgray;">-- as we have defined the type checking operation as being</span> <span style="color: dimgray;">-- able to determine a fully-typed expression's type and</span> <span style="color: dimgray;">-- we can imagine that inference would need that anyway.</span> infer :: l (<span style="color: rgb(170, 93, 0);">Maybe</span> t) -> m (l t)</span></code></pre> <p>Note that <code>Infer</code> requires a <code>Typecheck</code> implementation to be implemented. This is because I'm making an assumption that while doing type inference we'll want to type check subexpressions to know their types so that we can infer the correct type of the overall expression.</p> <p>What does this give us, though? It puts two operations in a neat little box, it gives us <em>direction</em>. It is not the be-all end-all of what types or static analysis in general has to be. It's efficient communication to someone who wants to make their data structures behave a certain way. It formalises a data transformation in a way that asks the user to think about how they'd implement these functions for the data structures that matter to them.</p> <p>It's also <em>satisfying</em> if you've been through bending your brain around type theories, typed languages. It's a way of presenting a general form in a way that makes you feel like something more true has been uncovered, even though all that's been done is the removal of specificities. We can now look at other abstract syntax trees for other languages and see how we might apply this way of doing things.</p> <h2>The most joyful/painful thing of all: Actually making your type system</h2> <p>This is where the scope of this blog post abruptly ends, as I am not instructing in type theory construction here. What I can do is once again offer a short list of what might be generously called insights:</p> <ol> <li>It's perfectly okay to do something that's already been done before.</li> <li>A language can have a type system and also be interpreted instead of compiled.</li> <li>Values don't have to only exist at "runtime".</li> <li>If you want to find some basic inspiration for toy type system features, look up the "lambda cube".</li> <li>Resolving free type variables honestly sucks and I'm really sorry. Terms you'll be looking for include: alpha equivalence, term unification, occurs check. Don't decide that you need to figure it out all by your self like I did when I was deep into this, reach out to others for help or to explain how to do things.</li> <li>Chase ambition sure, but we are a social lot. If you isolate yourself to solve all the problems you come up against, you'll find yourself lonely and perhaps without community to confidently share your work with or have appreciate your work. And don't work yourself into sickness.</li> <li>You don't need to have a runtime to have fun working on a language.</li> <li>What I laid out here won't necessarily work for everything.</li> <li>A language doesn't necessarily have only one type system.</li> </ol> <p>Designing a type system for your language is largely about decision making and lining up what you want with what you can do. We are privileged as people who write software in this world to have access to a very tight feedback loop in the form of compilers and automated tests which can give us confidence in what we're doing very rapidly. Leverage your tools and keep an open mind.</p> <h2>Conclusion and postscripts</h2> <p>I hope this exercise in type-driven development as applied to building toy languages (domain-specific, programming, general, or otherwise) has been helpful and not too esoteric. This way of doing things lets us separate different stages of type checking from each other without having to repeat definitions of data structures, and without being able to plug wrong stages into each other, all while being able to tell some basics of what is known about the types during which processes.</p> <p>Adding types to your languages can seem like an unnecessary and academic wander too far into the weeds. It doesn't have to be. The first step can be just looking at your toy language's AST and seeing if you can add a type parameter for extra data for your variables where they're introduced, and if that extra data can be types or thought of as types.</p> <p><strong>Next time:</strong> <a href="https://cohost.org/fallible-algebra/post/2696543-dependent-types-fee" target="_blank" rel="nofollow noopener" tabindex="0">This, but for dependent types.</a></p> <details> <summary tabindex="0">Postscript: Doing most of this in Rust</summary> <span> I do like Rust, and you can still do most of the cool stuff here in Rust. Rust doesn't have Higher-Kinded Types (or it does, but... I don't want to scare you off) so we can't get functors for free, or use monads, or easily state a trait that defines type checking and type inference. <p>But we can do the important things, so Rust is perfectly better-than-okay for this way of doing things:</p> <pre style="background-color: rgb(254, 254, 254); color: rgb(84, 84, 84); position: relative; padding: 0px; line-height: 1.2rem;"><code style="padding: 0px 16px; display: block; margin-bottom: 9px; margin-top: 9px;"><span><span><span style="color: rgb(121, 40, 161);">struct</span> <span style="color: rgb(0, 127, 170);">ToyContext</span></span> { <span style="color: dimgray;">// ...</span> } <p><span><span style="color: rgb(121, 40, 161);">enum</span> <span style="color: rgb(0, 127, 170);">ToyType</span></span> { <span style="color: dimgray;">// ...</span> }</p> <p><span><span style="color: rgb(121, 40, 161);">enum</span> <span style="color: rgb(0, 127, 170);">LambdaCalc</span></span><T> { Var(<span style="color: rgb(170, 93, 0);">String</span>), Apply(<span style="color: rgb(170, 93, 0);">Box</span><<span style="color: rgb(121, 40, 161);">Self</span>>, <span style="color: rgb(170, 93, 0);">Box</span><<span style="color: rgb(121, 40, 161);">Self</span>>), Abstract(<span style="color: rgb(170, 93, 0);">String</span>, T, <span style="color: rgb(170, 93, 0);">Box</span><<span style="color: rgb(121, 40, 161);">Self</span>>) }</p> <p><span><span style="color: rgb(121, 40, 161);">type</span> <span style="color: rgb(0, 127, 170);">UntypedLC</span></span> = LambdaCalc<()></p> <p><span style="color: dimgray;">// Altneratively, ctx could be <code>&amp;mut ToyContext</code> and </span> <span style="color: dimgray;">// you wouldn't need to return the <code>ToyContext</code>, but</span> <span style="color: dimgray;">// that's not the only way you could do things and would</span> <span style="color: dimgray;">// get in the way of parallelisation efforts. I'm just</span> <span style="color: dimgray;">// doing it this way here to line up with the haskell examples.</span> <span><span style="color: rgb(121, 40, 161);">fn</span> <span style="color: rgb(0, 127, 170);">typecheck</span></span>( ctx: ToyContext, expr: LambdaCalc<Type>, ) -> <span style="color: rgb(170, 93, 0);">Result</span><(Ctx, Type), <span style="color: rgb(170, 93, 0);">Err</span>> { <span style="color: dimgray;">// ...</span> }</p> <p><span><span style="color: rgb(121, 40, 161);">fn</span> <span style="color: rgb(0, 127, 170);">infer</span></span>( ctx: ToyContext, expr: LambdaCalc<<span style="color: rgb(170, 93, 0);">Option</span><Type>>, ) -> <span style="color: rgb(170, 93, 0);">Result</span><(ToyContext, LambdaCalc<Type>), <span style="color: rgb(170, 93, 0);">Err</span>> { <span style="color: dimgray;">// ...</span> }</span></code></pre></p> <p>Note that we need to specify context as a variable, but that's fine. It's easier to understand from the point of view of someone not entrenched in Haskell. Crates such as <code>nom</code> do this same thing, and it works out fine for them.</p> <p>If Haskell is too esoteric these days I might do a Rust Version of this post. Should get with the times, after all.<br> </p> </span></details> <details> <summary tabindex="0">Postscript: Meta</summary> I really wanted to call this "typing the type checker" but 1. not everyone has read <a href="https://aphyr.com/posts/342-typing-the-technical-interview" target="_blank" rel="nofollow noopener" tabindex="-1">Typing The Technical Interview</a> and 2. what I'm doing here isn't nearly as complicated, I do not think it could live up to the reference. </details> <hr aria-label="Footnotes" style="margin-bottom: -0.5rem;"> <ol> <li id="user-content-user-content-fn-1"> <p>Toy here not meant to demean the language being developed, but instead because this is more about having fun with language design than getting serious about the guts and bureaucracy of things. </p> </li> <li id="user-content-user-content-fn-2"> <p>I mean this in an informal sense, not as a sweeping ontological statement of linguistics, type theory, mathematics. </p> </li> <li id="user-content-user-content-fn-3"> <p>While I'm enabling the <code>FunctionalDependencies</code> feature here, isn't a necessary addition. It does let us specify that the language and type system are what determine the type of the monadic context. </p> </li> </ol> </div><button class="co-link-button co-opaque inline-block pb-3 pl-3 text-left text-sm font-bold hover:underline" tabindex="0">read less</button></cohost-post> </div> <h1 id="follow-up-post">Follow-up post</h1> <div id="pt2"> <cohost-post avatarsrc="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/4gIcSUNDX1BST0ZJTEUAAQEAAAIMbGNtcwIQAABtbnRyUkdCIFhZWiAH3AABABkAAwApADlhY3NwQVBQTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWxjbXMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApkZXNjAAAA/AAAAF5jcHJ0AAABXAAAAAt3dHB0AAABaAAAABRia3B0AAABfAAAABRyWFlaAAABkAAAABRnWFlaAAABpAAAABRiWFlaAAABuAAAABRyVFJDAAABzAAAAEBnVFJDAAABzAAAAEBiVFJDAAABzAAAAEBkZXNjAAAAAAAAAANjMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0ZXh0AAAAAEZCAABYWVogAAAAAAAA9tYAAQAAAADTLVhZWiAAAAAAAAADFgAAAzMAAAKkWFlaIAAAAAAAAG+iAAA49QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPY3VydgAAAAAAAAAaAAAAywHJA2MFkghrC/YQPxVRGzQh8SmQMhg7kkYFUXdd7WtwegWJsZp8rGm/fdPD6TD////bAEMA///////////////////////////////////////////////////////////////////////////////////////bAEMB///////////////////////////////////////////////////////////////////////////////////////AABEIAEAAQAMBIgACEQEDEQH/xAAWAAEBAQAAAAAAAAAAAAAAAAABAAL/xAAcEAEBAQEBAQADAAAAAAAAAAAAARESIWECMVH/xAAVAQEBAAAAAAAAAAAAAAAAAAAAAf/EABcRAQEBAQAAAAAAAAAAAAAAAAARASH/2gAMAwEAAhEDEQA/ADqrqsmBD18PXwYUpFvxagLMPU+rqBYqRmNifooqWIrE3WbMDd9jGBmpqBqIus6WWgXqQ06Q6NQUmEiQoM6dGX+LmqUhc1c0KjIp+NPolLOn1nKGP//Z" avatarshape="squircle" comments="0" displayname="Fallible Algebra" handle="fallible-algebra" originalurl="https://cohost.org/fallible-algebra/post/2696543-dependent-types-fee" publishedat="2023-09-01T10:49:32.698Z" standaloneheadline="Dependent Types: Feeding the lambda calculus its own tail" tags="programming language theory,dependent types,mathematics,math,maths,type theory,haskell,lambda calculus,programming languages,tutorial,functional programming,PLT"><noscript>Post by Fallible Algebra (@fallible-algebra): Dependent Types: Feeding the lambda calculus its own tail</noscript><div class="co-prose prose my-4 overflow-hidden break-words px-3"><p>This is a short continuation of <a href="https://cohost.org/fallible-algebra/post/2660945-outlining-type-check" target="_blank" rel="nofollow noopener" tabindex="0">Outlining type checking for your toy language (and many others)</a>. In my previous post, I introduced a way of classifying type checking and type inference as a transformation on an abstract syntax tree whose type system was a type parameter:</p> <pre style="background-color: rgb(254, 254, 254); color: rgb(84, 84, 84); position: relative; padding: 0px; line-height: 1.2rem; margin-bottom: 0px;"><code style="padding: 0px 16px; display: block; margin-bottom: 9px; margin-top: 9px;"><span><span style="color: rgb(170, 93, 0);">{-# LANGUAGE FunctionalDependencies #-}</span> <span> <span style="color: rgb(121, 40, 161);">class</span> <span style="color: rgb(170, 93, 0);">Monad</span> m => <span style="color: rgb(170, 93, 0);">Typecheck</span> m l t | l t -> m <span style="color: rgb(121, 40, 161);">where</span></span> typecheck :: l t -> m t <span> <span style="color: rgb(121, 40, 161);">class</span> (<span style="color: rgb(170, 93, 0);">Typecheck</span> <span style="color: rgb(0, 127, 170);">m</span> <span style="color: rgb(0, 127, 170);">l</span> <span style="color: rgb(0, 127, 170);">t</span>) => <span style="color: rgb(170, 93, 0);">Infer</span> m l t | l t -> m <span style="color: rgb(121, 40, 161);">where</span></span> infer :: l (<span style="color: rgb(170, 93, 0);">Maybe</span> t) -> m (l t)</span></code></pre><div style="text-align: right; font-size: min(1.87vw, 70%); opacity: 0.7; margin-bottom: 1.71429em;">made with <a data-testid="mention" href="https://cohost.org/nex3" class="!font-bold !no-underline hover:!underline" tabindex="0">@nex3</a>'s <a href="https://nex3.github.io/cohost-highlight" target="_blank" rel="nofollow noopener" tabindex="0">syntax highlighter</a></div> <p>I was using a lambda calculus whose type system I had made into a type parameter:</p> <pre style="background-color: rgb(254, 254, 254); color: rgb(84, 84, 84); position: relative; padding: 0px; line-height: 1.2rem;"><code style="padding: 0px 16px; display: block; margin-bottom: 9px; margin-top: 9px;"><span><span><span style="color: rgb(121, 40, 161);">data</span> <span style="color: rgb(170, 93, 0);">LambdaCalc</span> t</span> = <span style="color: rgb(170, 93, 0);">Var</span> <span style="color: rgb(170, 93, 0);">String</span> | <span style="color: rgb(170, 93, 0);">Apply</span> (<span style="color: rgb(170, 93, 0);">LambdaCalc</span> t) (<span style="color: rgb(170, 93, 0);">LambdaCalc</span> t) | <span style="color: rgb(170, 93, 0);">Abstract</span> (<span style="color: rgb(170, 93, 0);">String</span>, t) (<span style="color: rgb(170, 93, 0);">LambdaCalc</span> t) <span style="color: rgb(121, 40, 161);">deriving</span> (<span style="color: rgb(170, 93, 0);">Functor</span>, ...)</span></code></pre> <p>What I was walking through was the reasoning for doing things this way, especially how it means we can separate the stages of analysis really cleanly.</p> <p>But hang on, what if we start treating the toy language's type system as the toy language?</p></div><div class="co-prose prose my-4 overflow-hidden break-words px-3"><hr> <p>If we bring the complexity of the type system up to something like System F Omega, we can ask the questions previously asked for the lambda calculus itself but about our type system:</p> <ol> <li><code>forall</code> introduces type variables to type expressions.</li> <li><code>Function</code> is a constant with kind <code>Type -> Type</code>.</li> <li>We have a notion of kindedness, as in (2), where <code>Function</code> has a kind instead of a type.</li> <li>There are various reduction rules we can pull from for how to evaluate types during type checking.</li> </ol> <p>We can follow through on this with something along these lines:</p> <pre style="background-color: rgb(254, 254, 254); color: rgb(84, 84, 84); position: relative; padding: 0px; line-height: 1.2rem;"><code style="padding: 0px 16px; display: block; margin-bottom: 9px; margin-top: 9px;"><span><span><span style="color: rgb(121, 40, 161);">type</span> <span style="color: rgb(170, 93, 0);">KindcheckM</span> = ...</span> <p><span><span style="color: rgb(121, 40, 161);">data</span> <span style="color: rgb(170, 93, 0);">Kind</span></span> <span style="color: dimgray;">-- AKA <code>*</code>, or <code>Type</code>. The type of types.</span> = <span style="color: rgb(170, 93, 0);">MyType</span> | <span style="color: rgb(170, 93, 0);">Arrow</span> <span style="color: rgb(170, 93, 0);">Kind</span> <span style="color: rgb(170, 93, 0);">Kind</span></p> <p><span><span style="color: rgb(121, 40, 161);">data</span> <span style="color: rgb(170, 93, 0);">MyTypeSystem</span> k </span> = <span style="color: rgb(170, 93, 0);">Forall</span> (<span style="color: rgb(170, 93, 0);">String</span>, k) <span style="color: rgb(170, 93, 0);">MyTypeSystem</span> | <span style="color: rgb(170, 93, 0);">Function</span> (<span style="color: rgb(170, 93, 0);">MyTypeSystem</span> k) (<span style="color: rgb(170, 93, 0);">MyTypeSystem</span> k) | <span style="color: rgb(170, 93, 0);">TypeVar</span> <span style="color: rgb(170, 93, 0);">String</span> | <span style="color: rgb(170, 93, 0);">TypeCon</span> <span style="color: rgb(170, 93, 0);">String</span> <span> <span style="color: rgb(121, 40, 161);">instance</span> <span style="color: rgb(170, 93, 0);">Typecheck</span> <span style="color: rgb(170, 93, 0);">KindcheckM</span> <span style="color: rgb(170, 93, 0);">MyTypeSystem</span> <span style="color: rgb(170, 93, 0);">Kind</span> <span style="color: rgb(121, 40, 161);">where</span></span> typecheck :: <span style="color: rgb(170, 93, 0);">MyTypeSystem</span> <span style="color: rgb(170, 93, 0);">Kind</span> -> <span style="color: rgb(170, 93, 0);">KindcheckM</span> <span style="color: rgb(170, 93, 0);">Kind</span> typecheck expr = ... <span> <span style="color: rgb(121, 40, 161);">instance</span> <span style="color: rgb(170, 93, 0);">Infer</span> <span style="color: rgb(170, 93, 0);">KindcheckM</span> <span style="color: rgb(170, 93, 0);">MyTypeSystem</span> <span style="color: rgb(170, 93, 0);">Kind</span> <span style="color: rgb(121, 40, 161);">where</span></span> infer :: <span style="color: rgb(170, 93, 0);">MyTypeSystem</span> (<span style="color: rgb(170, 93, 0);">Maybe</span> <span style="color: rgb(170, 93, 0);">Kind</span>) -> <span style="color: rgb(170, 93, 0);">KindcheckM</span> (<span style="color: rgb(170, 93, 0);">MyTypeSystem</span> <span style="color: rgb(170, 93, 0);">Kind</span>) infer = ...</span></code></pre></p> <p>Can we take it a step further? Well, not like this. Kindedness does not at this point have the complexity we would want to be able to apply those same questions to it and get satisfying answers.</p> <p>But if we were to step up the type system to a Dependent one, one where general expressions can live in type land we can tie this up in a way that fits the style I've been going for here. We will need one <a href="https://hackage.haskell.org/package/data-fix-0.3.2/docs/Data-Fix.html" target="_blank" rel="nofollow noopener" tabindex="0">fancy tool</a> so that we can feed host types to themselves:</p> <pre style="background-color: rgb(254, 254, 254); color: rgb(84, 84, 84); position: relative; padding: 0px; line-height: 1.2rem;"><code style="padding: 0px 16px; display: block; margin-bottom: 9px; margin-top: 9px;"><span><span><span style="color: rgb(121, 40, 161);">newtype</span> <span style="color: rgb(170, 93, 0);">Fix</span> (<span style="color: rgb(0, 127, 170);">f</span> :: * -> *) = <span style="color: rgb(170, 93, 0);">Fix</span> {<span style="color: rgb(0, 127, 170);">unfix</span> :: <span style="color: rgb(0, 127, 170);">f</span> (<span style="color: rgb(170, 93, 0);">Fix</span> <span style="color: rgb(0, 127, 170);">f</span>)}</span> </span></code></pre> <p><code>Fix</code> feels a bit like a form of dark magic, but it can be thought of doing the same thing we do when we build a recursive function. Once again this is a simplification, but one to smooth past complexity and maintain focus.</p> <p>When we have <code>Fix</code>, it might tempt to just declare <code>LambdaCalc (Fix LambdaCalc)</code> as a dependently typed calculus. However there's a few modifications to the original I would like to do to:</p> <pre style="background-color: rgb(254, 254, 254); color: rgb(84, 84, 84); position: relative; padding: 0px; line-height: 1.2rem;"><code style="padding: 0px 16px; display: block; margin-bottom: 9px; margin-top: 9px;"><span><span style="color: dimgray;">-- A bit of housekeeping: I've made variables and constants distinct</span> <span style="color: dimgray;">-- types and added constants to the lambda calculus because now, they</span> <span style="color: dimgray;">-- not only represent "runtime" values but can also represent compile</span> <span style="color: dimgray;">-- time ones. `Function` now occupies a similar space in the language</span> <span style="color: dimgray;">-- as any user-defined constants. And some variable `a` could mean a</span> <span style="color: dimgray;">-- type variable or a variable that .</span> <span><span style="color: rgb(121, 40, 161);">data</span> <span style="color: rgb(170, 93, 0);">Variable</span> = ...</span> <span><span style="color: rgb(121, 40, 161);">data</span> <span style="color: rgb(170, 93, 0);">Constant</span> = ...</span> <p><span style="color: dimgray;">-- A lambda calculus with variables, constants, and the type system </span> <span style="color: dimgray;">-- made into parameters so we can focus on the important things in </span> <span style="color: dimgray;">-- life like good tea and time with friends and loved ones.</span> <span><span style="color: rgb(121, 40, 161);">data</span> <span style="color: rgb(170, 93, 0);">DepLambdaCalc</span> t</span> = <span style="color: rgb(170, 93, 0);">Var</span> <span style="color: rgb(170, 93, 0);">Variable</span> | <span style="color: rgb(170, 93, 0);">Const</span> <span style="color: rgb(170, 93, 0);">Constant</span> | <span style="color: rgb(170, 93, 0);">Apply</span> (<span style="color: rgb(170, 93, 0);">DepLambdaCalc</span> t) (<span style="color: rgb(170, 93, 0);">DepLambdaCalc</span> t) | <span style="color: rgb(170, 93, 0);">Abstract</span> (<span style="color: rgb(170, 93, 0);">Variable</span>, t) (<span style="color: rgb(170, 93, 0);">DepLambdaCalc</span> t) <span style="color: dimgray;">-- Okay, everything is looking fine so far. </span> <span style="color: dimgray;">-- But with dependent typing we can lift up a variable into the</span> <span style="color: dimgray;">-- type system. So we need to add one more thing:</span> | <span style="color: rgb(170, 93, 0);">Lift</span> (<span style="color: rgb(170, 93, 0);">Variable</span>, t) t</span></code></pre></p> <p>I've introduced <code>Lift</code> which can be thought of as: abstract but it lifts the variable up into the type system. This is not necessarily the correct way of doing things, or the best explanation, but it's how I'm doing it here. As with how I renamed $\lambda$ abstraction to simply <code>Abstract</code>, in type theory this is represented with $\Pi$ (capital letter pi).</p> <p>With this, we can now make it fit the forms of the typeclasses and have enough space to do at least some dependent type system shenanigans smoothly:</p> <pre style="background-color: rgb(254, 254, 254); color: rgb(84, 84, 84); position: relative; padding: 0px; line-height: 1.2rem;"><code style="padding: 0px 16px; display: block; margin-bottom: 9px; margin-top: 9px;"><span><span><span style="color: rgb(121, 40, 161);">type</span> <span style="color: rgb(170, 93, 0);">DepTypecheckM</span> = ...</span> <span> <span style="color: rgb(121, 40, 161);">instance</span> <span style="color: rgb(170, 93, 0);">Typecheck</span> <span style="color: rgb(170, 93, 0);">DepTypecheckM</span> <span style="color: rgb(170, 93, 0);">DepLambdaCalc</span> (<span style="color: rgb(170, 93, 0);">Fix</span> <span style="color: rgb(170, 93, 0);">DepLambdaCalc</span>) <span style="color: rgb(121, 40, 161);">where</span></span> typecheck :: <span style="color: rgb(170, 93, 0);">DepLambdaCalc</span> (<span style="color: rgb(170, 93, 0);">Fix</span> <span style="color: rgb(170, 93, 0);">DepLambdaCalc</span>) -> <span style="color: rgb(170, 93, 0);">DepTypecheckM</span> (<span style="color: rgb(170, 93, 0);">Fix</span> <span style="color: rgb(170, 93, 0);">DepLambdaCalc</span>) typecheck expr = ... <p><span style="color: dimgray;">-- Not all dependent terms can have their types inferred,</span> <span style="color: dimgray;">-- that's just the showbiz of complex type theories.</span> <span><span style="color: rgb(121, 40, 161);">instance</span> <span style="color: rgb(170, 93, 0);">Infer</span> <span style="color: rgb(170, 93, 0);">DepTypecheckM</span> <span style="color: rgb(170, 93, 0);">DepLambdaCalc</span> (<span style="color: rgb(170, 93, 0);">Fix</span> <span style="color: rgb(170, 93, 0);">DepLambdaCalc</span>) <span style="color: rgb(121, 40, 161);">where</span></span> infer :: <span style="color: rgb(170, 93, 0);">DepLambdaCalc</span> (<span style="color: rgb(170, 93, 0);">Maybe</span> (<span style="color: rgb(170, 93, 0);">Fix</span> <span style="color: rgb(170, 93, 0);">DepLambdaCalc</span>)) -> <span style="color: rgb(170, 93, 0);">DepTypecheckM</span> (<span style="color: rgb(170, 93, 0);">DepLambdaCalc</span> (<span style="color: rgb(170, 93, 0);">Fix</span> <span style="color: rgb(170, 93, 0);">DepLambdaCalc</span>)) infer expr = ... </span></code></pre></p> <p>We have now fed the lambda calculus to itself as its own type system. At least, I've shown a way we could do that. I have not written type checker code in a long time, it takes a lot of effort. But, the framework has been successfully turned onto itself.</p></div><button class="co-link-button co-opaque inline-block pb-3 pl-3 text-left text-sm font-bold hover:underline" tabindex="0">read less</button></cohost-post> </div>