<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Partial Evaluation on Scattered Space</title><link>https://moleike.github.io/tags/partial-evaluation/</link><description>Recent content in Partial Evaluation on Scattered Space</description><generator>Hugo</generator><language>en-US</language><copyright>Copyright © 2025, Alex Moreno.</copyright><lastBuildDate>Mon, 02 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://moleike.github.io/tags/partial-evaluation/index.xml" rel="self" type="application/rss+xml"/><item><title>Staged Parser Combinators in Scala: Have Your Cake and Eat It (Too)</title><link>https://moleike.github.io/blog/staged-parser-combinators/</link><pubDate>Mon, 02 Mar 2026 00:00:00 +0000</pubDate><guid>https://moleike.github.io/blog/staged-parser-combinators/</guid><description>&lt;p>Parser combinators have a reputation of poor performance&amp;mdash;worst-case
exponential time&amp;mdash;and deemed good for prototyping but not for production. Or so
the story goes. While techniques like Packrat parsing or static analysis offer
linear-time guarantees by addressing naive backtracking, they come with their
own trade-offs.&lt;/p>
&lt;p>In this post, I want to explore an optimization route that complements the
others: avoiding the performance penalty of abstraction.&lt;/p>
&lt;p>By leaning into Scala 3&amp;rsquo;s metaprogramming capabilities, our combinators combine
&lt;em>code fragments&lt;/em>. By moving to a &lt;em>staged&lt;/em> continuation-passing style (CPS)
encoding, we make the control flow explicit and continuations are fully
evaluated at compile time. The result is a parser that runs over 10x faster than
a standard non-staged version. Interestingly, this approach is deeply rooted in
program optimization history, closely mirroring the &lt;a href="https://arxiv.org/abs/1611.09906">First Futamura
Projection&lt;/a>.&lt;/p></description></item></channel></rss>