Exon Language: Invitation for Contributors · atdrez/exon · Discussion #2 · GitHub
//voltron/discussions_fragments/discussion_layout" data-turbo-transient="true" />
Skip to content
Search or jump to...
Search code, repositories, users, issues, pull requests...
-->
Search
Clear
Search syntax tips
Provide feedback
--><br>We read every piece of feedback, and take your input very seriously.
Include my email address so I can be contacted
Cancel
Submit feedback
Saved searches
Use saved searches to filter your results more quickly
-->
Name
Query
To see all available qualifiers, see our documentation.
Cancel
Create saved search
Sign in
//voltron/discussions_fragments/discussion_layout;ref_cta:Sign up;ref_loc:header logged out"}"<br>Sign up
Appearance settings
Resetting focus
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
atdrez
exon
Public
Notifications<br>You must be signed in to change notification settings
Fork
Star
Exon Language: Invitation for Contributors
#2
atdrez
announced in<br>Announcements
Exon Language: Invitation for Contributors
#2
atdrez
May 25, 2026<br>·<br>0 comments
Return to top
Discussion options
Uh oh!
There was an error while loading. Please reload this page.
{{title}}
Something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Quote reply
atdrez
May 25, 2026
Maintainer
Exon Language: Invitation for Contributors
Hi, I'm Adriano. I'm the CTO of PetitFabrik, a mid-sized game studio in Brazil. My main area is game development and graphical frameworks, but back in 2017 I had to create this language called Exon to solve a very practical problem: dealing with giant CloudFormation "spaghetti" files.
At the time, I was working with large infrastructure definitions where everything slowly collapsed into massive blobs of duplicated JSON. Reusing pieces was painful, inheritance didn't exist, and organizing related concepts across multiple files quickly became difficult to maintain.
I needed a way to:
modularize infrastructure definitions
inherit and override data
compose large object graphs from smaller pieces
and structure architecture information in a way that humans could actually digest
So I created Exon.
The idea was simple: instead of treating configuration as static text files, treat it as composable structured data with inheritance, flow control, and extensibility built directly into the language model.
The project has been open source under the MIT license since 2017, but I never really promoted it. Initially, I created it as an internal tool for our game studio, and I stopped contributing to it around 2018 because it already had every feature I needed at the time.
However, since Apple launched Pkl in 2024, I've noticed the idea of programmable configuration gaining more traction each year. That motivated me to revisit Exon. Over this last week, I've spent time modernizing the language and expanding its capabilities. I've been using it more heavily again for scripting, tooling and document generation, and I'm enjoying the experience quite a lot.
I'd welcome feedback, criticism, alternative perspectives, and ideas from people interested in experimenting with the project. The language is not production-ready yet, as I'm still exploring syntax ideas and features, and I haven't started the stabilization and optimization phase yet.
I'm curious whether the concepts behind this language resonate with other people as well.
The Git repository is:
git@github.com:atdrez/exon.git
Below is a quick overview of the language.
What Exon Actually Is
At its core, Exon is a structured object language.
Everything revolves around composing object graphs.
A minimal Exon file can look like this:
host: "localhost"<br>port: 8080
But the interesting part begins when objects become programmable and composable.
For example:
using fn.*
host: "localhost"
port: coalesce { process.env { "PORT" } 8080 }
url: string.join { "http://" @root.host ":" @root.port }
The language is intentionally built around a few core principles.
1. Uniform Syntax
There are no special syntax rules for loops, operators, functions, or conditions.
Everything is just an object call.
Arithmetic:
x: fn.add { 10 fn.sub { 20 2 } }
Conditionals:
host: fn.if {<br>condition: fn.eq { fn.process.env{"ENV"} "prod" }<br>then: "example.com"<br>else: "localhost"<br>port: fn.cond {<br>fn.eq { @root.host "localhost" } 3030<br>8080
Iteration:
using fn.*
values: ["Alice", "Bob", "John"]<br>messages: foreach {<br>data: @root.values<br>do: string.join { "Hello " parameter { "value" } "!" }
The above .exon generates the following JSON:
"values": ["Alice", "Bob", "John"]<br>"messages": ["Hello Alice!", "Hello Bob!", "Hello John!"]
The goal was to keep the grammar extremely small while still...