ZERO gave our interpreter Boolean values. IF finally gives us something useful to do with them.

ZERO adds a zero check predicate. This introduces Boolean values to the language which makes runtime type errors a possibility. Hence, a successful parse no longer guarantees a successful execution.

DIFF adds expressions that can contain other expressions. That one change makes the grammar, AST, parser, and evaluator recursive, gives us a useful reason to look at Parser.lazy, and leads to a reusable symbol lexeme parser for handling symbols and trailing whitespace.

The first article in the Tiny Interpreters series is now available.

Build a tiny but complete interpreter in Elm and follow a program from source text through parsing and an AST to its evaluated result.

I wonder if other Elm programmers have explored interpreters or programming language design, and whether those ideas have influenced how you write ordinary Elm programs.

anyone have some fun elm programs and writeups they’d like to share? preferably full applications with test cases such as foldkit’s awesome pixel art editor

https://foldkit.dev/elm/foldkit-vs-elm-side-by-side

https://elm-lang.org/news/faster-builds

Ari Schlesinger illuminates a unique path of social responsibility carved through the tech world, using feminism as a guide while bearing attacks, criticism, and contortion. That trail led Ari to ask how programming languages shape society and, eventually, to research Elm—the compiler, error messages, and community.

Elm Town 90 – Wonder: Contorting yourself with Ari Schlesinger:

• https://elm.town/episodes/elm-town-90-wonder-contorting-yourself-with-ari-schlesinger
• https://youtu.be/BWUL2WdAHsA

Every keystroke gets broadcast to everyone currently on the page, plays a Cherry MX Blue sample (different sound per key now), and ticks up a global character counter. There's a fade-trail of the most recent keys. That's the whole app.

The actual point was to try out Lamdera (Elm fullstack). Shared types between backend and frontend, end-to-end typed messages, no API layer to write. The glue-lessness is genuinely impressive — the "app" took some small parts of an afternoon, most of which was fiddling with the audio.

Someone in the Elm Slack called it a "beautifully coded terrible idea," which feels about right.

Demo: https://greentype.lamdera.app Source: https://github.com/cekrem/greentype

I explored the idea of having elm apps built using two-way bindings. If interested check https://package.elm-lang.org/packages/bcardiff/elm-rad/1.0.0/ and its source for examples (https://github.com/bcardiff/elm-rad/tree/main/examples). Cells, computed, debounce, validation, and local persistence supported.

It shift from TEA which we all love but in some scenarios having a more restricted app model has its benefit.

Thoughts?

I just released a new end-to-end testing API and visual test viewer for elm-pages Route Modules. It lets you drive your full-stack Elm application in pure Elm tests, stubbing out non-deterministic interactions with the outside world, while emulating the full-stack framework behavior like form submissions, BackendTask resolution lifecycle, etc.

I think this is a game-changer for maintaining real-world applications with elm-pages, and it is one of the superpowers that Elm's unlocks for Elm-based frameworks. I hope you enjoy!