{"article":{"slug":"unrolled-code","title":"Unrolled Code","subtitle":null,"summary":"Starting from grubby, a minimal Ruby static site generator written in a plain unrolled style, this Noteflakes post compares it to how ERB and Papercraft compile templates, then proposes a quote/unquote mechanism for Ruby code generation and discusses walking the line between Rails-style abstraction and machine performance.","content_type":"blog_post","language":"en","canonical_url":"https://noteflakes.com/articles/2026-10-07-unrolled-code","author":{"name":null,"url":null,"person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"Noteflakes","url":"https://noteflakes.com/","listing_slug":null,"listing":null},"topics":[{"name":"Ruby","slug":"ruby","url":"https://listedarticles.com/topics/ruby"},{"name":"Programming","slug":"programming","url":"https://listedarticles.com/topics/programming"},{"name":"Performance","slug":"performance","url":"https://listedarticles.com/topics/performance"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":3875,"reading_minutes":17,"published_at":"2026-10-07T00:00:00.000Z","added_at":"2026-10-07T14:28:03.979Z","updated_at":"2026-10-07T14:28:03.979Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":true},"profile_url":"https://listedarticles.com/articles/unrolled-code","markdown_url":"https://listedarticles.com/articles/unrolled-code.md","example":false,"citation":"Noteflakes. \"Unrolled Code.\" 7 Oct 2026. https://noteflakes.com/articles/2026-10-07-unrolled-code (all-rights-reserved)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://noteflakes.com/articles/2026-10-07-unrolled-code"},"body_markdown":"# Unrolled Code\n\n### 07·10·2026\n\nThe other day I was looking at a little project called\n[grubby](https://git.btxx.org/grubby/), a minimal static site generator for git\nrepos, written in Ruby. The style is quite interesting. It feels solid and unapologetic:\n\n```\ndef fill_template(template, page_title, root_prefix)\n template\n .gsub(\"{{title}}\", escape_html(page_title))\n .gsub(\"{{root}}\", root_prefix)\n .gsub(\"{{stylesheet}}\") { STYLESHEET }\n .gsub(\"{{build_date}}\", BUILD_DATE)\nend\n```\nNothing is particularly optimized, it just uses available tools to do its work:\n\n```\ndef write_page(page_path, page_title, root_prefix = \"\")\n FileUtils.mkdir_p(File.dirname(page_path))\n header = fill_template(HEADER_TEMPLATE, page_title, root_prefix)\n footer = fill_template(FOOTER_TEMPLATE, page_title, root_prefix)\n File.write(page_path, header + yield + footer)\nend\n```\nAfter running `git ls-tree` and collecting the filenames in the repository, it\ngenerates an HTML page for each file. Looking at the code examples above we can\ndiscern a primitive templating system: there’s `#fill_template` for\nreplacing place-holders in the template with values, there’s a\n`#render_markdown` helper function, there’s the composition of the inner HTML\nwith the header and footer HTML in `#write_page`.\n\nThe header and footer are stored in separate files, but where are the templates for the actual page content? A bit further down, we find them. Here’s an excerpt from the index page template:\n\n```\n...\nwrite_page(File.join(output_dir, \"index.html\"), repo_name) do\n ...\n page_html = \"
\\n

#{escape_html(repo_name)}

\\n\"\n page_html += \"

#{escape_html(repo_description)}

\\n\"\n page_html += \"

#{escape_html(clone_command)}

\\n
\\n\"\n ...\n page_html\nend\n...\n```\nThis code has a very specific shape: it’s a series of operations that stuff\nstrings into a buffer. In fact, this code looks very similar to the kind of code\nthat will actually run when you use\n[Papercraft](https://github.com/digital-fabric/papercraft) or\n[ERB](https://github.com/ruby/erb) for generating HTML from templates. Both ERB\nand Papercraft compile the templates into optimized Ruby code that emits\nsnippets of HTML into a buffer.\n\nI find it interesting that the code remains very readable, even though it’s very low level. There are of course many different ways to write this kind of code. We could use a heredoc with string interpolation:\n\n```\npage_html = <<~HTML\n
\\n

#{escape_html(repo_name)}

\n

#{escape_html(repo_description)}

\n

#{escape_html(clone_command)}

\\n
\nHTML\n```\nThere’s also the *optimized* way that avoids interpolation and therefore double\ncopying of strings:\n\n```\npage_html <<\n \"
\\n

\" << escape_html(repo_name) <<\n \"

\\n

\" << escape_html(repo_description) <<\n \"

\\n

\" << escape_html(clone_command) <<\n \"

\\n
\\n\"\n```\nA bit less readable, but somewhat faster. Both ERB and Papercraft compile code into this form. Just for kicks, how would a corresponding ERB template look?\n\n```\n
\n

<%= escape_html(repo_name) %>

\n

<%= escape_html(repo_description) %>

\n

<%= escape_html(clone_command) %>

\n
\n```\nThis looks pretty nice! It’s just HTML with some interpolated strings in it. And how about Papercraft?\n\n```\nheader {\n p { strong(repo_name) }\n p(repo_description)\n p { code(clone_command) }\n}\n```\nEverything is compressed down to a minimal syntax. But in the end, when you\nrender this template, Papercraft will actually compile it into code that looks a\nlot like [grubby](https://git.btxx.org/grubby/):\n\n```\n__buffer__\n .<<(\"

\").<<(ERB::Escape.html_escape((repo_name)))\n .<<(\"

\").<<(ERB::Escape.html_escape((repo_description)))\n .<<(\"

\").<<(ERB::Escape.html_escape((clone_command)))\n .<<(\"

\")\n```\nSo going back to the grubby code, it was interesting to see this style of\ncoding, which basically “unrolls” the code that would have been generated if a\ntemplating tool like ERB or Papercraft was used. But it also reminded me of\nanother code base I was looking at recently, that of\n[Herb](https://github.com/marcoroth/herb), which is a gem with a set of tools\nfor working with ERB templates. Here’s an excerpt:\n\n```\n# from Herb::Engine#initialize:\n...\n@context = Visitor::Context.new(\n file_path: properties[:filename],\n project_path: properties[:project_path],\n options: context_options(properties),\n resolver: properties[:resolver],\n **(properties[:context] || {})\n)\n \n@bufvar = properties[:bufvar] || properties[:outvar] || \"_buf\"\n@escape = properties.fetch(:escape) { properties.fetch(:escape_html, false) }\n@escapefunc = properties.fetch(:escapefunc, @escape ? \"__herb.h\" : \"::Herb::Engine.h\")\n@attrfunc = properties.fetch(:attrfunc, @escape ? \"__herb.attr\" : \"::Herb::Engine.attr\")\n@jsfunc = properties.fetch(:jsfunc, @escape ? \"__herb.js\" : \"::Herb::Engine.js\")\n@cssfunc = properties.fetch(:cssfunc, @escape ? \"__herb.css\" : \"::Herb::Engine.css\")\n@src = properties[:src] || +\"\"\n@chain_appends = properties[:chain_appends]\n@buffer_on_stack = false\n@parser_options = properties.fetch(:parser_options, default_parser_options).transform_keys(&:to_sym)\n...\n```\nThe entire `Herb::Engine#initialize` method is about 65 LOC! And the individual\nlines themselves tend to stretch to the right edge of your editor window. I ran `cloc`\non the code and was really taken aback:\n\n```\n~/playground/herb $ cloc --exclude-dir test --include-ext rb,rs,c,ts .\n...\ngithub.com/AlDanial/cloc v 2.06 T=2.55 s (359.5 files/s, 66052.1 lines/s)\n-------------------------------------------------------------------------------\nLanguage files blank comment code\n-------------------------------------------------------------------------------\nTypeScript 549 19777 4641 65383\nRuby 161 6838 3255 20728\nRust 141 5531 338 20397\nC 66 4649 148 16809\n-------------------------------------------------------------------------------\nSUM: 917 36795 8382 123317\n-------------------------------------------------------------------------------\n...\n```\nOK, so the Typescript stuff is probably not relevant to the present discussion, but still, 20KLOC of Ruby, and another 37KLOC of C/Rust extensions. For comparison’s sake, ActiveRecord is about 46KLOC (not including tests). The entire Rails codebase is about 120KLOC of Ruby (again, not including tests). Herb just became the default template renderer in Rails 8.2.\n\nHerb’s template compiler code looks beautiful:\n\n```\ndef generate_output\n optimized_tokens.each do |type, value, context, escaped|\n case type\n when :text\n @engine.send(:add_text, value)\n when :code\n @engine.send(:add_code, value)\n when :expr, :expr_escaped\n indicator = indicator_for(type)\n if context_aware_context?(context)\n @engine.send(:add_context_aware_expression, indicator, value, context)\n else\n @engine.send(:add_expression, indicator, value)\n end\n when :expr_block, :expr_block_escaped\n @engine.send(:add_expression_block, indicator_for(type), value)\n when :expr_block_end\n @engine.send(:add_expression_block_end, value, escaped: escaped)\n when :chain\n @engine.send(:add_expression_result, value)\n end\n end\nend\n```\nThis method is basically a router inside of a loop. it converts data into method calls. Again, this kind of functionality could have been hidden behind a DSL, but here we have the entire logic for this algorithm laid out very explicitly in front of our eyes. Another example:\n\n```\ndef self.js(value)\n value.to_s.gsub(/[\\\\'\"<>&\\n\\r\\t\\f\\b]/) do |char|\n case char\n when \"\\n\" then \"\\\\n\"\n when \"\\r\" then \"\\\\r\"\n when \"\\t\" then \"\\\\t\"\n when \"\\f\" then \"\\\\f\"\n when \"\\b\" then \"\\\\b\"\n else\n \"\\\\x#{char.ord.to_s(16).rjust(2, \"0\")}\"\n end\n end\nend\n```\nAnd another:\n\n```\ndef add_code(code)\n terminate_expression\n if code.include?(\"=begin\") || code.include?(\"=end\")\n @src << \"\\n\" << code\n @src << \"\\n\" unless code.end_with?(\"\\n\")\n else\n @src << \" \" unless code.match?(/\\A\\n+\\z/)\n @src << code\n if Helpers.comment?(code) || Helpers.heredoc?(code)\n @src << \"\\n\" unless code[-1] == \"\\n\"\n else\n @src << \";\" unless code[-1] == \"\\n\"\n end\n @buffer_on_stack = false\nend\n```\nIt’s just logic expressed in the purest way possible. The code that we’re looking into here is charged with transforming an ERB template into a piece of Ruby source code containing an optimized renderer for the given template. The optimized source code is painstakingly put together from little bits and pieces, according to the structure of the template. If we take the same HTML template from the grubby example above, ERB/Herb would have emitted the following code:\n\n```\n# edited for formatting\n_erbout = +''\n_erbout.<< \"
\\n

\".freeze\n_erbout.<<(( escape_html(repo_name) ).to_s); _erbout.<< \"

\\n

\".freeze\n_erbout.<<(( escape_html(repo_description) ).to_s); _erbout.<< \"

\\n

\".freeze\n_erbout.<<(( escape_html(clone_command) ).to_s); _erbout.<< \"

\\n
\\n\".freeze\n_erbout\n```\nNote the similarities: we’re dealing with constructing a string, we’re mostly doing just one type of action, and the action is repeated. This is what unrolled code is about: clarity, discipline, optimization, and grouping like actions together. Let’s take a look at a different project:\n\n```\ndef emit_wildcard_childless_root_code(buffer, root_path)\n emit_code_line(buffer, '->(path, params) {')\n if root_path != '/'\n re = /^#{Regexp.escape(root_path)}(\\/.*)?$/\n emit_code_line(buffer, \" return if path !~ #{re.inspect}\")\n end\n emit_code_line(buffer, \" @dynamic_map[#{root_path.inspect}]\")\n emit_code_line(buffer, '}')\nend\n```\nThis is from [Syntropy](https://github.com/digital-fabric/syntropy), which is\nthe web framework that’s driving this website, and the code excerpt is part of\nits routing tree compiler. The idea is to take a tree-like data structure\ndescribing the apps’s directory structure and files, and compile it into an\noptimized router lambda that can deal with parametric and wildcard routes.\n\nThe resulting router code would look something like the following:\n\n```\n->(path, params) {\n entry = @static_map[path]; return entry if entry\n segments = path.split(\"/\")\n return nil if (segments[1] != \"syntropy\")\n case (s = segments[2])\n when \"api\"\n return @dynamic_map[\"/syntropy/api+\"]\n when \"mod\"\n case (s = segments[3])\n when \"bar\"\n return @dynamic_map[\"/syntropy/mod/bar\"]\n end\n when \"params\"\n case (s = segments[3])\n when s\n params[\"foo\"] = s\n case (s = segments[4])\n when nil\n return @dynamic_map[\"/syntropy/params/[foo]\"]\n end\n end\n end\n return nil\n}\n```\nLike with ERB/Herb, the Syntropy code generates a complex piece of code by putting together strings containing little bits of Ruby source code. The above method could also have been written as follows:\n\n```\ndef emit_wildcard_childless_root_code(buffer, root_path)\n re = /^#{Regexp.escape(root_path)}(\\/.*)?$/\n emit_code_block <<~EOF\n ->(path, params) {\n #{ 'return if path !~ #{re.inspect}' if root_path != '/' }\n @dynamic_map[#{root_path.inspect}]\n }\n EOF\nend\n```\nThis is much clearer, but still, the code for generating the conditional return\nin the middle there is a bit hairy. What if we had a DSL for generating Ruby\ncode? In Elixir you can define macros that expand into code with a pair of tools\ncalled quote/unquote. In fact, a lot of Elixir’s language features (even basic\nstuff like `if` and `case`) are implemented using macros. When a macro is used,\nthe macro definition is expanded in place, it’s like *parametric code*. This\nidea, like all good ideas, comes from Lisp, where there’s no distinction between\ndata and code. What if we had that in Ruby?\n\n```\ndef wildcard_childless_root_code(root_path)\n quote { \n ->(req) {\n unquote {\n if root_path != '/'\n re = /^#{unquote(Regexp.escape(root_path))}(\\/.*)?$/\n quote { return if path !~ unquote(re) }\n else\n :__nop__\n end\n }\n @dynamic_map[unquote(root_path)]\n }\n }\nend\n```\nThe `#quote` method returns the AST of the given block. The `#unquote` method is\nused to inject arbitrary values, or nested ASTs into the quoted code. In this\nexample, we conditionally inject a piece of Ruby code expressed with a nested\n`#quote` block, that interpolates a regular expression. The final call to\n`#unquote` injects the value of `root_path` as a literal into the generated code.\n\nNotice the mechanics of quote/unquote: with `#quote` we’re putting code inside\nquotes (obviously), and with `#unquote` we’re temporarily escaping out of the\nquotes in order to perform some computation and inject the result back into the\nquoted code, it’s very much like string interpolation. The expression passed to\n`#unquote` is evaluated at *compile-time*. This allows us to conditionally\ninclude pieces of code in the template. And since `#unquote` always returns an\nAST (or `:__nop__` for nothing), we can use it to compose ASTs together:\n\n```\ndef compile_html(ast)\n html_parts = []\n flusher = -> {\n return :__nop__ if html_parts.empty?\n \n html = html_parts.join; html_parts.clear\n quote { __buffer__ << unquote(html) }\n }\n quote {\n unquote(transform_template_ast(ast))\n unquote(flusher.())\n __buffer__\n }\nend\ndef transform_template_ast(ast)\n mutate(ast) { |node, transform|\n if html_tag?(node)\n emit_html(node, transform, html_parts, flusher)\n else\n [flusher.(), *transform.(node)]\n end\n }\nend\n```\nHere’s an attempt to apply the idea of quote/unquote to compiling Papercraft\ntemplates. This method takes the template AST, and returns a mutated AST, where\ntag method calls are translated to strings being emitted to a buffer. But since\nwe want to have the same optimized form of bunching together static strings and\nseparating out the dynamic strings, we introduce some compile-time state (the\n`html_parts` buffer), and a `flusher` closure that generates the actual code\nthat emits static strings to the buffer. This design lets us support recursion\nin `#emit_html`, so we can do stuff like `div { p { a 'Home' } }`, since the\nstate is passed as arguments.\n\n## Some complementary tools\n\nSuppose we have this quote/unquote functionality ready to let us generate code programmatically. We still need a few more tools to be able to create code. Consider the following:\n\n```\ndef memoize(*methods)\n methods.each do |m|\n ast = Sirop.to_ast(method(m))\n memoized = mutate(ast, ast.body => quote {\n (@memo ||= {})[unquote(m)] = begin; unqoute(ast.body); end\n })\n eval(Sirop.to_source(memoized))\n end\nend\n```\n([Sirop](https://github.com/digital-fabric/sirop) is a little gem I wrote to\nhelp work with Prism ASTs.)\n\n`#mutate` works by creating a copy of the AST, letting you replace any node on\nthe tree with another. In this case, we’re implementing a momoized version of a\nmethod by replacing the method body with a conditional assignment, into which\nwe inject the memo key and the original method body. I think this example\ndemonstrates the strength of this approach, it feels magical!\n\nAnother way to work with `#mutate` is by passing it a block that returns either\nthe original node, or a different node in case of a mutation:\n\n```\nl1 = ->(x) { 42 }\nmutated = mutate(Sirop.to_ast(l1)) { |n|\n n.is_a?(Prism::IntegerNode) ? quote { 43 } : n\n}))\nl2 = eval(Sirop.to_source(mutated))\nl2.() #=> 43\n```\nWhat about keywords? What if, for example, we wanted to programmatically add a\n`when` clause inside of a `case` statement?\n\n```\nquote {\n case foo\n unquote(\n bar ? quote { when :bar; p 'baz' }\n )\n end\n}\n```\nThis is invalid syntax, and while Prism will parse this, the AST would contain a\n`MissingNode`, and will otherwise be deformed. Here’s a solution that doesn’t\nfeel too inelegant:\n\n```\ndef make_case_expr(entry)\n quote {\n __.case(unquote(entry[:name])) {\n quote {\n unquote entry[:options].map { |o|\n quote { __.when(unquote(o)) { add_option(unquote(o)) } }\n }\n __.else { raise 'Invalid option' }\n }\n }\n }\nend\n```\nThis lets us construct `case` statements programmtically, and we can extend this\nidea to basically any keyword, like `rescue`:\n\n```\ndef make_fatal_lambda(body, *fatal_errors)\n quote {\n -> {\n __.begin {\n unquote(body)\n unquote(fatal_errors.map { |t|\n quote { __.rescue(unquote(t) => e) { puts 'BOOM!'; exit!(42) } }\n })\n })\n }\n }\nend\nmake_fatal_lambda(quote { 1 / 0 }, ZeroDivisionError).() #=> BOOM!\n```\nI find that a functional approach to coding goes very well when working with\nASTs. We treat ASTs as immutable objects, and if we need to change a node\nanywhere on the AST, we can use `#mutate` which creates a copy with the\nrequisite changes. If we’re generating more complex code, as we do in\nPapercraft, Syntropy, or ERB, we can split the code generation logic into\nmultiple methods, each of which prepares a distinct part of the code, and\nreturns an AST. This allows us to create arbitrarily complex pieces of code by\ncomposing ASTs together. Let’s take a real use case. Here’s the template for an\nActiveRecord migration, used by a Rails generator. Yes, Rails uses ERB to generate\ncode:\n\n```\nclass <%= migration_class_name %> < ActiveRecord::Migration[<%= ActiveRecord::Migration.current_version %>]\n def change\n create_table :<%= table_name %><%= render_table_with_dom_id %> do |t|\n<% attributes.each do |attribute| -%>\n<% if attribute.password_digest? -%>\n t.string :password_digest<%= attribute.inject_options %>\n<% elsif attribute.token? -%>\n t.string :<%= attribute.name %><%= attribute.inject_options %>\n<% else -%>\n t.<%= attribute.type %> :<%= attribute.name %><%= attribute.inject_options %>\n<% end -%>\n<% end -%>\n<% if options[:timestamps] -%>\n t.timestamps\n<% end -%>\n end\n end\nend\n```\nHow would it look with quote/unquote? Let’s find out:\n\n```\nversion = ActiveRecord::Migration.current_version\nquote do\n __.class(unquote(migration_class_name) < ActiveRecord::Migration[unquote(version)]) {\n def change\n create_table unquote(table_name) do |t|\n unquote attributes.map do |attribute|\n opts = attribute.inject_options\n if attribute.password_digest?\n quote { t.string unquote(:\"password_digest#{opts}\") }\n elsif attribute.token?\n quote { t.string unquote(:\"#{attribute.name}#{opts}\") }\n else\n # note use of unquote as method name\n quote { t.send(unquote(attribute.type), unquote(:\"#{opts}\") }\n end\n end\n unquote(\n options[:timestamps] ? quote { t.timestamps } : :__nop__\n )\n end\n end\n }\nend\n```\nNot very pretty, I admit, but maybe a little refactoring, splitting the code into distinct parts, would make it better:\n\n```\ndef attribute_ast(attribute)\n opts = attribute.inject_options\n if attribute.password_digest?\n quote { t.string unquote(:\"password_digest#{opts}\") }\n elsif attribute.token?\n quote { t.string unquote(:\"#{attribute.name}#{opts}\") }\n else\n quote { __.call(t, unquote(attribute.type), unquote(:\"#{opts}\") }\n end\nend\ndef timestamps_ast(options)\n options[:timestamps] ? quote { t.timestamps } : :__nop__\nend\nversion = ActiveRecord::Migration.current_version\nquote do\n __.class(unquote(migration_class_name) < ActiveRecord::Migration[unquote(version)]) {\n def change\n create_table unquote(table_name) do |t|\n unquote attributes.map { attribute_ast(it) }\n unquote(timestamps_ast(options))\n end\n end\n }\nend\n```\nOh yes this is *much* better, as we can now see the shape of the generated code!\nOne more example, fitting for the title of this article:\n\n```\ndef rewrite_block_param(ast, v) {\n block_param_name = ast.parameters.parameters.requireds[0].name\n mutate(ast) { |n, t|\n if n in Prism::LocalVariableReadNode(name: block_param_name)\n unquote(v)\n else\n n\n end\n }\n}\ndef unroll(o, &block)\n block_ast = Sirop.to_ast(block)\n o.map { |v| rewrite_block_param(block_ast, v) }\nend\nast = quote {\n -> {\n unquote unroll(%w{foo bar baz}) { |v| p v }\n }\n}\nunrolled_printer = eval(Sirop.to_source(ast))\n```\nHere we use `#mutate` to change the body of a given block such that all\nreferences to the block argument will be replaced with an arbitrary value, such\nthat the actual source code of `unrolled_printer` would be:\n\n```\n-> {\n p 'foo'\n p 'bar'\n p 'baz'\n}\n```\n## Walking the Fine Line of Abstraction\n\nThis morning I was looking at a vibe-coded [port of\nCampfire](https://github.com/tobi/campfire-once-ruby-ractor) from Rails to plain\nRuby (with ractors). This is an interesting project, and I think it demonstrates\npretty well the [performance costs of\nRails](https://static.lutke.dev/KTK6Vb/campfire-ruby-explainer/)’ abstractions.\nWith Rails, we choose developer happiness at the expense of machine happiness.\nBut the results show that Ruby is actually pretty fast. OK, not as fast as Rust,\nbut in some cases faster than Go!\n\nAnd the code itself is interesting - a lot of unrolled code for sure, but generated by an LLM:\n\n```\ndef dispatch(request)\n ...\n if (verb == \"GET\" || verb == \"HEAD\") && (file = Assets.file(path))\n return static(file, request)\n end\n return health(request) if path == \"/up\"\n if path.start_with?(STORAGE_PREFIX)\n # ActiveStorage controllers; the proxy ones stream (ActionController::Live).\n return Front.finish_response(request, Storage.call(request, path, query), live: path.include?(\"/proxy/\"))\n end\n body = nil\n if verb == \"POST\" && request.headers[\"content-type\"]&.to_s&.start_with?(FORM)\n body = (request.body&.join || +\"\").force_encoding(Encoding::UTF_8)\n if (i = body.index(\"_method=\"))\n m = body[i + 8, 6].to_s[/\\A[a-z]+/i]\n verb = m.upcase if m && %w[PATCH PUT DELETE].include?(m.upcase)\n end\n elsif verb == \"POST\" && request.headers[\"content-type\"]&.to_s&.start_with?(MULTIPART)\n # Rails forms with file inputs carry _method as a multipart part.\n body = (request.body&.join || +\"\").force_encoding(Encoding::BINARY)\n if (i = body.byteindex(METHOD_PART)) && (j = body.byteindex(\"\\r\\n\\r\\n\", i))\n m = body.byteslice(j + 4, 6).to_s[/\\A[a-z]+/i]\n verb = m.upcase if m && %w[PATCH PUT DELETE].include?(m.upcase)\n end\n body.force_encoding(Encoding::UTF_8)\n end\n ...\nend\n```\nLook at the style. The lines stretch to the right, and the code itself is\ndealing with tiny details, no abstractions here, just pure algorithms (and lots\nof branching!) The `#dispatch` method is about 45 lines long, and could have been\neasily refactored into a few separate methods that each does a single thing.\n\nAn experienced programmer would probably have a blast refactoring this code, there are lots of opportunities in there to make it more readable, more maintainable, even snappier than it already is. This is obviously unrolled code, but other parts of the code base do use metaprogramming. For example, let’s look at the router config code, which may look familiar to a Rails developer:\n\n```\nCampfire::ROUTES = Campfire::Router.new do\n get \"/\", to: \"WelcomeController#show\", format: false\n get \"/first_run\", to: \"FirstRunsController#show\"\n post \"/first_run\", to: \"FirstRunsController#create\"\n get \"/session/new\", to: \"SessionsController#new\"\n post \"/session\", to: \"SessionsController#create\"\n delete \"/session\", to: \"SessionsController#destroy\"\n get \"/session/transfers/:id\", to: \"Sessions::TransfersController#show\"\n patch \"/session/transfers/:id\", to: \"Sessions::TransfersController#update\"\n put \"/session/transfers/:id\", to: \"Sessions::TransfersController#update\"\n ...\nend\n```\nSo there’s a DSL here, using the builder pattern:\n\n```\nclass Router\n ...\n \n def initialize(&block)\n @groups = Hash.new { |h, k| h[k] = [] }\n instance_eval(&block)\n end\n %w[GET POST PATCH PUT DELETE].each do |verb|\n define_method(verb.downcase) do |pattern, to:, defaults: nil, format: true|\n add(verb, pattern, to, defaults, format)\n end\n end\n ...\nend\n```\nThis is just the syntactic sugar, but it’s the `#add` method that does the work\nof computing and storing the route information:\n\n```\ndef add(verb, pattern, to, defaults, format)\n controller, action = to.split(\"#\")\n names = []\n src = pattern.gsub(%r{:(\\w+)|\\*(\\w+)|\\.|@}) do\n if $1\n names << $1\n \"([^/.]+)\"\n elsif $2\n names << $2\n \"(.+)\"\n else\n Regexp.escape($&)\n end\n end\n src << \"(?:\\\\.([a-z0-9]+))?\" if format\n first = pattern.split(\"/\")[1] || \"\"\n first = \"\" if first.start_with?(\":\")\n @groups[first] << Route.new(verb, Regexp.new(\"\\\\A#{src}\\\\z\"), names.freeze,\n controller, action.to_sym, defaults&.freeze)\nend\n```\nThe actual routing of incoming requests is done in `#recognize`:\n\n```\ndef recognize(verb, path)\n verb = \"GET\" if verb == \"HEAD\"\n slash = path.index(\"/\", 1)\n first = slash ? path[1, slash - 1] : path[1..]\n dot = first.index(\".\")\n first = first[0, dot] if dot\n route_in(@groups[first], verb, path) || route_in(@fallback, verb, path)\nend\n```\nHere we can see that what this routing DSL does (as in many cases) is to convert\ncode into data. All routing configuration is stored in `@groups`, and the work\nof actually routing requests (done in `#recognize`) is all about consulting the\nrouting data. But with quote/unquote we can convert data into code, as we saw\nabove in the Syntropy router example. Here’s the original `#route_in` method:\n\n```\ndef route_in(routes, verb, path)\n return nil unless routes\n routes.each do |r|\n next unless r.verb == verb\n m = r.regex.match(path) or next\n params = r.defaults ? r.defaults.dup : {}\n r.names.each_with_index { |n, i| params[n] = m[i + 1]&.force_encoding(Encoding::UTF_8) }\n return [r, params, m[r.names.size + 1]]\n end\n nil\nend\n```\nSee that loop in there? We can unroll it using quote/unquote:\n\n```\ndef compile_groups\n @groups = @groups.transform_values { make_route_in_proc(it) }\nend\ndef make_route_in_proc(routes)\n eval Sirop.to_source quote {\n ->(verb, path) {\n unquote routes.map { |r|\n quote {\n if (unquote(r.verb) == verb && (m = unquote(r.regex.match(path))))\n params = unquote(r.defaults ? r.defaults.dup : {})\n unquote(r.names).each_with_index { |n, i| params[n] = m[i + 1]&.force_encoding(Encoding::UTF_8) }\n return [routes[unquote(routes.index(r))], params, m[unquote(r.names.size + 1)]]\n end\n }\n }\n }\n }\nend\n```\nWith this, we’ve converted each route group to a custom-made piece of code.\nNotice the frequent use of `#unquote` - this allows us to change all references\nto the `r` iterator variable into literal values! And we can do this safely\nbecause the routing configuration is immutable. The only place where we need to\ndo a bit more work is in the `return` statement, where we need to also return a\nreference to the specific route. We do this by calling `routes[]` where the\nsubscript is hard-coded using `#unquote`.\n\n## Taking Ruby Metaprogramming to the Next Level\n\nRuby is famous for its productivity and simplicity, and Ruby programmers have\nwholeheartedly embraced its metaprogramming facilities in the quest for\n*developer happiness*. Tools such as `#eval`, `#instance_eval`, and\n`#define_method` let us create beautiful abstractions that make our code more\nreadable and arguably easier to maintain. All those Rails idioms, they’re\ncatchy, they make the intent clear, it’s almost as if they’ve become part of the\nRuby syntax!\n\nThe quote/unquote mechanism I’m proposing here doesn’t exist yet in Ruby, but if it ever materializes, I think it would open a whole new world of possibilities for Ruby. Such tools will allow us to create better abstractions without paying the associated performance overhead. They might make it possible to express new ideas, new idioms, and new techniques for manipulating Ruby code.\n","body_html":"

Unrolled Code

\n

07·10·2026

\n

The other day I was looking at a little project called\ngrubby, a minimal static site generator for git\nrepos, written in Ruby. The style is quite interesting. It feels solid and unapologetic:

\n
def fill_template(template, page_title, root_prefix)\n  template\n    .gsub("{{title}}", escape_html(page_title))\n    .gsub("{{root}}", root_prefix)\n    .gsub("{{stylesheet}}") { STYLESHEET }\n    .gsub("{{build_date}}", BUILD_DATE)\nend
\n

Nothing is particularly optimized, it just uses available tools to do its work:

\n
def write_page(page_path, page_title, root_prefix = "")\n  FileUtils.mkdir_p(File.dirname(page_path))\n  header = fill_template(HEADER_TEMPLATE, page_title, root_prefix)\n  footer = fill_template(FOOTER_TEMPLATE, page_title, root_prefix)\n  File.write(page_path, header + yield + footer)\nend
\n

After running git ls-tree and collecting the filenames in the repository, it\ngenerates an HTML page for each file. Looking at the code examples above we can\ndiscern a primitive templating system: there’s #fill_template for\nreplacing place-holders in the template with values, there’s a\n#render_markdown helper function, there’s the composition of the inner HTML\nwith the header and footer HTML in #write_page.

\n

The header and footer are stored in separate files, but where are the templates for the actual page content? A bit further down, we find them. Here’s an excerpt from the index page template:

\n
...\nwrite_page(File.join(output_dir, "index.html"), repo_name) do\n  ...\n  page_html = "<header>\\n<p><strong>#{escape_html(repo_name)}</strong></p>\\n"\n  page_html += "<p>#{escape_html(repo_description)}</p>\\n"\n  page_html += "<p><code>#{escape_html(clone_command)}</code></p>\\n</header>\\n"\n  ...\n  page_html\nend\n...
\n

This code has a very specific shape: it’s a series of operations that stuff\nstrings into a buffer. In fact, this code looks very similar to the kind of code\nthat will actually run when you use\nPapercraft or\nERB for generating HTML from templates. Both ERB\nand Papercraft compile the templates into optimized Ruby code that emits\nsnippets of HTML into a buffer.

\n

I find it interesting that the code remains very readable, even though it’s very low level. There are of course many different ways to write this kind of code. We could use a heredoc with string interpolation:

\n
page_html = <<~HTML\n  <header>\\n<p><strong>#{escape_html(repo_name)}</strong></p>\n  <p>#{escape_html(repo_description)}</p>\n  <p><code>#{escape_html(clone_command)}</code></p>\\n</header>\nHTML
\n

There’s also the optimized way that avoids interpolation and therefore double\ncopying of strings:

\n
page_html <<\n  "<header>\\n<p><strong>" << escape_html(repo_name) <<\n  "</strong></p>\\n<p>" << escape_html(repo_description) <<\n  "</p>\\n<p><code>" << escape_html(clone_command) <<\n  "</code></p>\\n</header>\\n"
\n

A bit less readable, but somewhat faster. Both ERB and Papercraft compile code into this form. Just for kicks, how would a corresponding ERB template look?

\n
<header>\n  <p><strong><%= escape_html(repo_name) %></strong></p>\n  <p><%= escape_html(repo_description) %></p>\n  <p><code><%= escape_html(clone_command) %></code></p>\n</header>
\n

This looks pretty nice! It’s just HTML with some interpolated strings in it. And how about Papercraft?

\n
header {\n  p { strong(repo_name) }\n  p(repo_description)\n  p { code(clone_command) }\n}
\n

Everything is compressed down to a minimal syntax. But in the end, when you\nrender this template, Papercraft will actually compile it into code that looks a\nlot like grubby:

\n
__buffer__\n  .<<("<header><p><strong>").<<(ERB::Escape.html_escape((repo_name)))\n  .<<("</strong></p><p>").<<(ERB::Escape.html_escape((repo_description)))\n  .<<("</p><p><code>").<<(ERB::Escape.html_escape((clone_command)))\n  .<<("</code></p></header>")
\n

So going back to the grubby code, it was interesting to see this style of\ncoding, which basically “unrolls” the code that would have been generated if a\ntemplating tool like ERB or Papercraft was used. But it also reminded me of\nanother code base I was looking at recently, that of\nHerb, which is a gem with a set of tools\nfor working with ERB templates. Here’s an excerpt:

\n
# from Herb::Engine#initialize:\n...\n@context = Visitor::Context.new(\n  file_path: properties[:filename],\n  project_path: properties[:project_path],\n  options: context_options(properties),\n  resolver: properties[:resolver],\n  **(properties[:context] || {})\n)\n    \n@bufvar = properties[:bufvar] || properties[:outvar] || "_buf"\n@escape = properties.fetch(:escape) { properties.fetch(:escape_html, false) }\n@escapefunc = properties.fetch(:escapefunc, @escape ? "__herb.h" : "::Herb::Engine.h")\n@attrfunc = properties.fetch(:attrfunc, @escape ? "__herb.attr" : "::Herb::Engine.attr")\n@jsfunc = properties.fetch(:jsfunc, @escape ? "__herb.js" : "::Herb::Engine.js")\n@cssfunc = properties.fetch(:cssfunc, @escape ? "__herb.css" : "::Herb::Engine.css")\n@src = properties[:src] || +""\n@chain_appends = properties[:chain_appends]\n@buffer_on_stack = false\n@parser_options = properties.fetch(:parser_options, default_parser_options).transform_keys(&:to_sym)\n...
\n

The entire Herb::Engine#initialize method is about 65 LOC! And the individual\nlines themselves tend to stretch to the right edge of your editor window. I ran cloc\non the code and was really taken aback:

\n
~/playground/herb $ cloc --exclude-dir test --include-ext rb,rs,c,ts .\n...\ngithub.com/AlDanial/cloc v 2.06  T=2.55 s (359.5 files/s, 66052.1 lines/s)\n-------------------------------------------------------------------------------\nLanguage                     files          blank        comment           code\n-------------------------------------------------------------------------------\nTypeScript                     549          19777           4641          65383\nRuby                           161           6838           3255          20728\nRust                           141           5531            338          20397\nC                               66           4649            148          16809\n-------------------------------------------------------------------------------\nSUM:                           917          36795           8382         123317\n-------------------------------------------------------------------------------\n...
\n

OK, so the Typescript stuff is probably not relevant to the present discussion, but still, 20KLOC of Ruby, and another 37KLOC of C/Rust extensions. For comparison’s sake, ActiveRecord is about 46KLOC (not including tests). The entire Rails codebase is about 120KLOC of Ruby (again, not including tests). Herb just became the default template renderer in Rails 8.2.

\n

Herb’s template compiler code looks beautiful:

\n
def generate_output\n  optimized_tokens.each do |type, value, context, escaped|\n    case type\n    when :text\n      @engine.send(:add_text, value)\n    when :code\n      @engine.send(:add_code, value)\n    when :expr, :expr_escaped\n      indicator = indicator_for(type)\n      if context_aware_context?(context)\n        @engine.send(:add_context_aware_expression, indicator, value, context)\n      else\n        @engine.send(:add_expression, indicator, value)\n      end\n    when :expr_block, :expr_block_escaped\n      @engine.send(:add_expression_block, indicator_for(type), value)\n    when :expr_block_end\n      @engine.send(:add_expression_block_end, value, escaped: escaped)\n    when :chain\n      @engine.send(:add_expression_result, value)\n    end\n  end\nend
\n

This method is basically a router inside of a loop. it converts data into method calls. Again, this kind of functionality could have been hidden behind a DSL, but here we have the entire logic for this algorithm laid out very explicitly in front of our eyes. Another example:

\n
def self.js(value)\n  value.to_s.gsub(/[\\\\'"<>&\\n\\r\\t\\f\\b]/) do |char|\n    case char\n    when "\\n" then "\\\\n"\n    when "\\r" then "\\\\r"\n    when "\\t" then "\\\\t"\n    when "\\f" then "\\\\f"\n    when "\\b" then "\\\\b"\n    else\n      "\\\\x#{char.ord.to_s(16).rjust(2, "0")}"\n    end\n  end\nend
\n

And another:

\n
def add_code(code)\n  terminate_expression\n  if code.include?("=begin") || code.include?("=end")\n    @src << "\\n" << code\n    @src << "\\n" unless code.end_with?("\\n")\n  else\n    @src << " " unless code.match?(/\\A\\n+\\z/)\n    @src << code\n  if Helpers.comment?(code) || Helpers.heredoc?(code)\n    @src << "\\n" unless code[-1] == "\\n"\n  else\n    @src << ";" unless code[-1] == "\\n"\n  end\n  @buffer_on_stack = false\nend
\n

It’s just logic expressed in the purest way possible. The code that we’re looking into here is charged with transforming an ERB template into a piece of Ruby source code containing an optimized renderer for the given template. The optimized source code is painstakingly put together from little bits and pieces, according to the structure of the template. If we take the same HTML template from the grubby example above, ERB/Herb would have emitted the following code:

\n
# edited for formatting\n_erbout = +''\n_erbout.<< "  <header>\\n  <p><strong>".freeze\n_erbout.<<(( escape_html(repo_name) ).to_s); _erbout.<< "</strong></p>\\n  <p>".freeze\n_erbout.<<(( escape_html(repo_description) ).to_s); _erbout.<< "</p>\\n  <p><code>".freeze\n_erbout.<<(( escape_html(clone_command) ).to_s); _erbout.<< "</code></p>\\n</header>\\n".freeze\n_erbout
\n

Note the similarities: we’re dealing with constructing a string, we’re mostly doing just one type of action, and the action is repeated. This is what unrolled code is about: clarity, discipline, optimization, and grouping like actions together. Let’s take a look at a different project:

\n
def emit_wildcard_childless_root_code(buffer, root_path)\n  emit_code_line(buffer, '->(path, params) {')\n  if root_path != '/'\n    re = /^#{Regexp.escape(root_path)}(\\/.*)?$/\n    emit_code_line(buffer, "  return if path !~ #{re.inspect}")\n  end\n  emit_code_line(buffer, "  @dynamic_map[#{root_path.inspect}]")\n  emit_code_line(buffer, '}')\nend
\n

This is from Syntropy, which is\nthe web framework that’s driving this website, and the code excerpt is part of\nits routing tree compiler. The idea is to take a tree-like data structure\ndescribing the apps’s directory structure and files, and compile it into an\noptimized router lambda that can deal with parametric and wildcard routes.

\n

The resulting router code would look something like the following:

\n
->(path, params) {\n  entry = @static_map[path]; return entry if entry\n  segments = path.split("/")\n  return nil if (segments[1] != "syntropy")\n  case (s = segments[2])\n  when "api"\n    return @dynamic_map["/syntropy/api+"]\n  when "mod"\n    case (s = segments[3])\n    when "bar"\n      return @dynamic_map["/syntropy/mod/bar"]\n    end\n  when "params"\n    case (s = segments[3])\n    when s\n      params["foo"] = s\n      case (s = segments[4])\n      when nil\n        return @dynamic_map["/syntropy/params/[foo]"]\n      end\n    end\n  end\n  return nil\n}
\n

Like with ERB/Herb, the Syntropy code generates a complex piece of code by putting together strings containing little bits of Ruby source code. The above method could also have been written as follows:

\n
def emit_wildcard_childless_root_code(buffer, root_path)\n  re = /^#{Regexp.escape(root_path)}(\\/.*)?$/\n  emit_code_block <<~EOF\n    ->(path, params) {\n      #{ 'return if path !~ #{re.inspect}' if root_path != '/' }\n      @dynamic_map[#{root_path.inspect}]\n    }\n  EOF\nend
\n

This is much clearer, but still, the code for generating the conditional return\nin the middle there is a bit hairy. What if we had a DSL for generating Ruby\ncode? In Elixir you can define macros that expand into code with a pair of tools\ncalled quote/unquote. In fact, a lot of Elixir’s language features (even basic\nstuff like if and case) are implemented using macros. When a macro is used,\nthe macro definition is expanded in place, it’s like parametric code. This\nidea, like all good ideas, comes from Lisp, where there’s no distinction between\ndata and code. What if we had that in Ruby?

\n
def wildcard_childless_root_code(root_path)\n  quote { \n    ->(req) {\n      unquote {\n        if root_path != '/'\n          re = /^#{unquote(Regexp.escape(root_path))}(\\/.*)?$/\n          quote { return if path !~ unquote(re) }\n        else\n          :__nop__\n        end\n      }\n      @dynamic_map[unquote(root_path)]\n    }\n  }\nend
\n

The #quote method returns the AST of the given block. The #unquote method is\nused to inject arbitrary values, or nested ASTs into the quoted code. In this\nexample, we conditionally inject a piece of Ruby code expressed with a nested\n#quote block, that interpolates a regular expression. The final call to\n#unquote injects the value of root_path as a literal into the generated code.

\n

Notice the mechanics of quote/unquote: with #quote we’re putting code inside\nquotes (obviously), and with #unquote we’re temporarily escaping out of the\nquotes in order to perform some computation and inject the result back into the\nquoted code, it’s very much like string interpolation. The expression passed to\n#unquote is evaluated at compile-time. This allows us to conditionally\ninclude pieces of code in the template. And since #unquote always returns an\nAST (or :__nop__ for nothing), we can use it to compose ASTs together:

\n
def compile_html(ast)\n  html_parts = []\n  flusher = -> {\n    return :__nop__ if html_parts.empty?\n    \n    html = html_parts.join; html_parts.clear\n    quote { __buffer__ << unquote(html) }\n  }\n  quote {\n    unquote(transform_template_ast(ast))\n    unquote(flusher.())\n    __buffer__\n  }\nend\ndef transform_template_ast(ast)\n  mutate(ast) { |node, transform|\n    if html_tag?(node)\n      emit_html(node, transform, html_parts, flusher)\n    else\n      [flusher.(), *transform.(node)]\n    end\n  }\nend
\n

Here’s an attempt to apply the idea of quote/unquote to compiling Papercraft\ntemplates. This method takes the template AST, and returns a mutated AST, where\ntag method calls are translated to strings being emitted to a buffer. But since\nwe want to have the same optimized form of bunching together static strings and\nseparating out the dynamic strings, we introduce some compile-time state (the\nhtml_parts buffer), and a flusher closure that generates the actual code\nthat emits static strings to the buffer. This design lets us support recursion\nin #emit_html, so we can do stuff like div { p { a 'Home' } }, since the\nstate is passed as arguments.

\n

Some complementary tools

\n

Suppose we have this quote/unquote functionality ready to let us generate code programmatically. We still need a few more tools to be able to create code. Consider the following:

\n
def memoize(*methods)\n  methods.each do |m|\n    ast = Sirop.to_ast(method(m))\n    memoized = mutate(ast, ast.body => quote {\n      (@memo ||= {})[unquote(m)] = begin; unqoute(ast.body); end\n    })\n    eval(Sirop.to_source(memoized))\n  end\nend
\n

(Sirop is a little gem I wrote to\nhelp work with Prism ASTs.)

\n

#mutate works by creating a copy of the AST, letting you replace any node on\nthe tree with another. In this case, we’re implementing a momoized version of a\nmethod by replacing the method body with a conditional assignment, into which\nwe inject the memo key and the original method body. I think this example\ndemonstrates the strength of this approach, it feels magical!

\n

Another way to work with #mutate is by passing it a block that returns either\nthe original node, or a different node in case of a mutation:

\n
l1 = ->(x) { 42 }\nmutated = mutate(Sirop.to_ast(l1)) { |n|\n  n.is_a?(Prism::IntegerNode) ? quote { 43 } : n\n}))\nl2 = eval(Sirop.to_source(mutated))\nl2.() #=> 43
\n

What about keywords? What if, for example, we wanted to programmatically add a\nwhen clause inside of a case statement?

\n
quote {\n  case foo\n    unquote(\n      bar ? quote { when :bar; p 'baz' }\n    )\n  end\n}
\n

This is invalid syntax, and while Prism will parse this, the AST would contain a\nMissingNode, and will otherwise be deformed. Here’s a solution that doesn’t\nfeel too inelegant:

\n
def make_case_expr(entry)\n  quote {\n    __.case(unquote(entry[:name])) {\n      quote {\n        unquote entry[:options].map { |o|\n          quote { __.when(unquote(o)) { add_option(unquote(o)) } }\n        }\n        __.else { raise 'Invalid option' }\n      }\n    }\n  }\nend
\n

This lets us construct case statements programmtically, and we can extend this\nidea to basically any keyword, like rescue:

\n
def make_fatal_lambda(body, *fatal_errors)\n  quote {\n    -> {\n      __.begin {\n        unquote(body)\n        unquote(fatal_errors.map { |t|\n          quote { __.rescue(unquote(t) => e) { puts 'BOOM!'; exit!(42) } }\n        })\n      })\n    }\n  }\nend\nmake_fatal_lambda(quote { 1 / 0 }, ZeroDivisionError).() #=> BOOM!
\n

I find that a functional approach to coding goes very well when working with\nASTs. We treat ASTs as immutable objects, and if we need to change a node\nanywhere on the AST, we can use #mutate which creates a copy with the\nrequisite changes. If we’re generating more complex code, as we do in\nPapercraft, Syntropy, or ERB, we can split the code generation logic into\nmultiple methods, each of which prepares a distinct part of the code, and\nreturns an AST. This allows us to create arbitrarily complex pieces of code by\ncomposing ASTs together. Let’s take a real use case. Here’s the template for an\nActiveRecord migration, used by a Rails generator. Yes, Rails uses ERB to generate\ncode:

\n
class <%= migration_class_name %> < ActiveRecord::Migration[<%= ActiveRecord::Migration.current_version %>]\n  def change\n    create_table :<%= table_name %><%= render_table_with_dom_id %> do |t|\n<% attributes.each do |attribute| -%>\n<% if attribute.password_digest? -%>\n      t.string :password_digest<%= attribute.inject_options %>\n<% elsif attribute.token? -%>\n      t.string :<%= attribute.name %><%= attribute.inject_options %>\n<% else -%>\n      t.<%= attribute.type %> :<%= attribute.name %><%= attribute.inject_options %>\n<% end -%>\n<% end -%>\n<% if options[:timestamps] -%>\n      t.timestamps\n<% end -%>\n    end\n  end\nend
\n

How would it look with quote/unquote? Let’s find out:

\n
version = ActiveRecord::Migration.current_version\nquote do\n  __.class(unquote(migration_class_name) < ActiveRecord::Migration[unquote(version)]) {\n    def change\n      create_table unquote(table_name) do |t|\n        unquote attributes.map do |attribute|\n          opts = attribute.inject_options\n          if attribute.password_digest?\n            quote { t.string unquote(:"password_digest#{opts}") }\n          elsif attribute.token?\n            quote { t.string unquote(:"#{attribute.name}#{opts}") }\n          else\n            # note use of unquote as method name\n            quote { t.send(unquote(attribute.type), unquote(:"#{opts}") }\n          end\n        end\n        unquote(\n          options[:timestamps] ? quote { t.timestamps } : :__nop__\n        )\n      end\n    end\n  }\nend
\n

Not very pretty, I admit, but maybe a little refactoring, splitting the code into distinct parts, would make it better:

\n
def attribute_ast(attribute)\n  opts = attribute.inject_options\n  if attribute.password_digest?\n    quote { t.string unquote(:"password_digest#{opts}") }\n  elsif attribute.token?\n    quote { t.string unquote(:"#{attribute.name}#{opts}") }\n  else\n    quote { __.call(t, unquote(attribute.type), unquote(:"#{opts}") }\n  end\nend\ndef timestamps_ast(options)\n  options[:timestamps] ? quote { t.timestamps } : :__nop__\nend\nversion = ActiveRecord::Migration.current_version\nquote do\n  __.class(unquote(migration_class_name) < ActiveRecord::Migration[unquote(version)]) {\n    def change\n      create_table unquote(table_name) do |t|\n        unquote attributes.map { attribute_ast(it) }\n        unquote(timestamps_ast(options))\n      end\n    end\n  }\nend
\n

Oh yes this is much better, as we can now see the shape of the generated code!\nOne more example, fitting for the title of this article:

\n
def rewrite_block_param(ast, v) {\n  block_param_name = ast.parameters.parameters.requireds[0].name\n  mutate(ast) { |n, t|\n    if n in Prism::LocalVariableReadNode(name: block_param_name)\n      unquote(v)\n    else\n      n\n    end\n  }\n}\ndef unroll(o, &block)\n  block_ast = Sirop.to_ast(block)\n  o.map { |v| rewrite_block_param(block_ast, v) }\nend\nast = quote {\n  -> {\n    unquote unroll(%w{foo bar baz}) { |v| p v }\n  }\n}\nunrolled_printer = eval(Sirop.to_source(ast))
\n

Here we use #mutate to change the body of a given block such that all\nreferences to the block argument will be replaced with an arbitrary value, such\nthat the actual source code of unrolled_printer would be:

\n
-> {\n  p 'foo'\n  p 'bar'\n  p 'baz'\n}
\n

Walking the Fine Line of Abstraction

\n

This morning I was looking at a vibe-coded port of\nCampfire from Rails to plain\nRuby (with ractors). This is an interesting project, and I think it demonstrates\npretty well the performance costs of\nRails’ abstractions.\nWith Rails, we choose developer happiness at the expense of machine happiness.\nBut the results show that Ruby is actually pretty fast. OK, not as fast as Rust,\nbut in some cases faster than Go!

\n

And the code itself is interesting - a lot of unrolled code for sure, but generated by an LLM:

\n
def dispatch(request)\n  ...\n  if (verb == "GET" || verb == "HEAD") && (file = Assets.file(path))\n    return static(file, request)\n  end\n  return health(request) if path == "/up"\n  if path.start_with?(STORAGE_PREFIX)\n    # ActiveStorage controllers; the proxy ones stream (ActionController::Live).\n    return Front.finish_response(request, Storage.call(request, path, query), live: path.include?("/proxy/"))\n  end\n  body = nil\n  if verb == "POST" && request.headers["content-type"]&.to_s&.start_with?(FORM)\n    body = (request.body&.join || +"").force_encoding(Encoding::UTF_8)\n    if (i = body.index("_method="))\n      m = body[i + 8, 6].to_s[/\\A[a-z]+/i]\n      verb = m.upcase if m && %w[PATCH PUT DELETE].include?(m.upcase)\n    end\n  elsif verb == "POST" && request.headers["content-type"]&.to_s&.start_with?(MULTIPART)\n    # Rails forms with file inputs carry _method as a multipart part.\n    body = (request.body&.join || +"").force_encoding(Encoding::BINARY)\n    if (i = body.byteindex(METHOD_PART)) && (j = body.byteindex("\\r\\n\\r\\n", i))\n      m = body.byteslice(j + 4, 6).to_s[/\\A[a-z]+/i]\n      verb = m.upcase if m && %w[PATCH PUT DELETE].include?(m.upcase)\n    end\n    body.force_encoding(Encoding::UTF_8)\n  end\n  ...\nend
\n

Look at the style. The lines stretch to the right, and the code itself is\ndealing with tiny details, no abstractions here, just pure algorithms (and lots\nof branching!) The #dispatch method is about 45 lines long, and could have been\neasily refactored into a few separate methods that each does a single thing.

\n

An experienced programmer would probably have a blast refactoring this code, there are lots of opportunities in there to make it more readable, more maintainable, even snappier than it already is. This is obviously unrolled code, but other parts of the code base do use metaprogramming. For example, let’s look at the router config code, which may look familiar to a Rails developer:

\n
Campfire::ROUTES = Campfire::Router.new do\n  get "/", to: "WelcomeController#show", format: false\n  get "/first_run", to: "FirstRunsController#show"\n  post "/first_run", to: "FirstRunsController#create"\n  get "/session/new", to: "SessionsController#new"\n  post "/session", to: "SessionsController#create"\n  delete "/session", to: "SessionsController#destroy"\n  get "/session/transfers/:id", to: "Sessions::TransfersController#show"\n  patch "/session/transfers/:id", to: "Sessions::TransfersController#update"\n  put "/session/transfers/:id", to: "Sessions::TransfersController#update"\n  ...\nend
\n

So there’s a DSL here, using the builder pattern:

\n
class Router\n  ...\n  \n  def initialize(&block)\n    @groups = Hash.new { |h, k| h[k] = [] }\n    instance_eval(&block)\n  end\n  %w[GET POST PATCH PUT DELETE].each do |verb|\n    define_method(verb.downcase) do |pattern, to:, defaults: nil, format: true|\n      add(verb, pattern, to, defaults, format)\n    end\n  end\n  ...\nend
\n

This is just the syntactic sugar, but it’s the #add method that does the work\nof computing and storing the route information:

\n
def add(verb, pattern, to, defaults, format)\n  controller, action = to.split("#")\n  names = []\n  src = pattern.gsub(%r{:(\\w+)|\\*(\\w+)|\\.|@}) do\n    if $1\n      names << $1\n      "([^/.]+)"\n    elsif $2\n      names << $2\n      "(.+)"\n    else\n      Regexp.escape($&)\n    end\n  end\n  src << "(?:\\\\.([a-z0-9]+))?" if format\n  first = pattern.split("/")[1] || ""\n  first = "" if first.start_with?(":")\n  @groups[first] << Route.new(verb, Regexp.new("\\\\A#{src}\\\\z"), names.freeze,\n    controller, action.to_sym, defaults&.freeze)\nend
\n

The actual routing of incoming requests is done in #recognize:

\n
def recognize(verb, path)\n  verb = "GET" if verb == "HEAD"\n  slash = path.index("/", 1)\n  first = slash ? path[1, slash - 1] : path[1..]\n  dot = first.index(".")\n  first = first[0, dot] if dot\n  route_in(@groups[first], verb, path) || route_in(@fallback, verb, path)\nend
\n

Here we can see that what this routing DSL does (as in many cases) is to convert\ncode into data. All routing configuration is stored in @groups, and the work\nof actually routing requests (done in #recognize) is all about consulting the\nrouting data. But with quote/unquote we can convert data into code, as we saw\nabove in the Syntropy router example. Here’s the original #route_in method:

\n
def route_in(routes, verb, path)\n  return nil unless routes\n  routes.each do |r|\n    next unless r.verb == verb\n    m = r.regex.match(path) or next\n    params = r.defaults ? r.defaults.dup : {}\n    r.names.each_with_index { |n, i| params[n] = m[i + 1]&.force_encoding(Encoding::UTF_8) }\n    return [r, params, m[r.names.size + 1]]\n  end\n  nil\nend
\n

See that loop in there? We can unroll it using quote/unquote:

\n
def compile_groups\n  @groups = @groups.transform_values { make_route_in_proc(it) }\nend\ndef make_route_in_proc(routes)\n  eval Sirop.to_source quote {\n    ->(verb, path) {\n      unquote routes.map { |r|\n        quote {\n          if (unquote(r.verb) == verb && (m = unquote(r.regex.match(path))))\n            params = unquote(r.defaults ? r.defaults.dup : {})\n            unquote(r.names).each_with_index { |n, i| params[n] = m[i + 1]&.force_encoding(Encoding::UTF_8) }\n            return [routes[unquote(routes.index(r))], params, m[unquote(r.names.size + 1)]]\n          end\n        }\n      }\n    }\n  }\nend
\n

With this, we’ve converted each route group to a custom-made piece of code.\nNotice the frequent use of #unquote - this allows us to change all references\nto the r iterator variable into literal values! And we can do this safely\nbecause the routing configuration is immutable. The only place where we need to\ndo a bit more work is in the return statement, where we need to also return a\nreference to the specific route. We do this by calling routes[] where the\nsubscript is hard-coded using #unquote.

\n

Taking Ruby Metaprogramming to the Next Level

\n

Ruby is famous for its productivity and simplicity, and Ruby programmers have\nwholeheartedly embraced its metaprogramming facilities in the quest for\ndeveloper happiness. Tools such as #eval, #instance_eval, and\n#define_method let us create beautiful abstractions that make our code more\nreadable and arguably easier to maintain. All those Rails idioms, they’re\ncatchy, they make the intent clear, it’s almost as if they’ve become part of the\nRuby syntax!

\n

The quote/unquote mechanism I’m proposing here doesn’t exist yet in Ruby, but if it ever materializes, I think it would open a whole new world of possibilities for Ruby. Such tools will allow us to create better abstractions without paying the associated performance overhead. They might make it possible to express new ideas, new idioms, and new techniques for manipulating Ruby code.

","headings":[{"level":1,"text":"Unrolled Code","id":"unrolled-code"},{"level":3,"text":"07·10·2026","id":"07-10-2026"},{"level":2,"text":"Some complementary tools","id":"some-complementary-tools"},{"level":2,"text":"Walking the Fine Line of Abstraction","id":"walking-the-fine-line-of-abstraction"},{"level":2,"text":"Taking Ruby Metaprogramming to the Next Level","id":"taking-ruby-metaprogramming-to-the-next-level"}]}}