Output Defaulting Languages

I've always thought PHP was fascinating because it's one of the few programming languages where output is the default and code is the exception.

The following file is valid PHP. It prints "Hello" to the output buffer:

Hello

You could also write it like this:

<?php echo "hello"; ?>

...but that's not necessary because in PHP, output is the default.

Output-defaulting languages are rare, but there are others. Ruby's ERB is an output-defaulting Ruby format. I wrote EJS back around 2007 as an output-defaulting Javascript format.

RenPy is a Python-like visual novel engine that's mostly output-defaulting. Any barren, quote-enclosed string is narrator output:

"The wind howled outside."

And character dialogue is implemented by instantiating a character object and then using it like a macro:

define Ted = Character("Ted", image="ted.png", color="#c8ffc8")

"The wind howled outside."
Ted "What was that noise?!"

The Ink language goes even further. It expresses control structures like user-driven branching and GOTO statements with a Markdown-like syntax:

The wind howled outside.
"What was that?" Ted asked.
*  "Probably nothing," I shrugged.
   Ted turned back to his newspaper.
   -> BURGLER_BREAKS_IN
*  "A burglar!" I said.
   Ted jumped up from the couch.
   -> FIGHT_SCENE

And then there is the Hollywood script format. Not a programming language in the strict sense, but a very rigid syntax for conveying scene descriptions, camera notes, blocking, and dialogue.

What I love about all of these is how readable they are, but also the challenge they present: readable at what cost to ease of coding?

Goofing off with Language Design

I've been hacking on-and-off on an LLM-native scripting language called Kaya¹. It's been a fun way to explore what programming might look like if LLMs and Chat were as fundamental to the stack as the CPUs and I/O.

It's not released anywhere, but it is great fodder for blog posts like this.

I really like the idea that an LLM-native language could read, in its simplest form, like a chat room log:

[Narrator] "The wind howled outside."

[Ted] "What was that?"

[User] "Probably nothing"

So that's the core design element of the language. Essentially RenPy, but with with [Name] syntax instead of Name: syntax.

Whoever spoke last is the default speaker, so you can omit the [Name] if the person continues speaking:

[Narrator] "The wind howled outside."

[Ted] "What was that?"

"Did you hear that?"

[User] "Probably nothing"

Single quotes are permitted too, and back ticks permit multi-line strings.

I experimented with not requiring quotes, to get that clean Hollywood script look, but that left me uncomfortable once I started introducing code: it was much harder to write a syntax highlighting plugin, and it felt more prone to user error: if I mis-typed a function name, instead of failing it would be interpreted as speech! Major footgun².

So this is what Kaya looks like with a bit of code added to the mix:

[Ted] "Hi there!"

"What's your name?"

set name = input()

"It's great to meet you {{name}}!"

[Susan] "Oh hey there guys."

[Ted] "Hey Susan, let me introduce you to {{name}}."

• set is a keyword required for setting a variable.
• input() is a function that awaits stdin from the user. Stdin in Kaya is a chat message!
• {{name}} is template interpolation. All strings in Kaya are Liquid templates.

The program above should have two messages from someone named Ted, followed by a pause for user input, followed by greeting that user by name. Then Susan arrives and Ted introduces the user.

Kaya output ends up looking like a variant of Kaya input:

[Ted] "Hi there!"

"What's your name?"

[User] "Bob"

"It's great to meet you Bob!"

[Susan] "Oh they there guys."

[Ted] "Hey Susan, let me introduce you to Bob."

One final note about implementing this is that this makes Kaya a line-aware language, in the same way that Markdown is, or in the same way that Python is space aware. The parser evaluates each line as either dialogue or code, and then applies different rules based on how the line began and ended.

I think we'll see more of this

I think we'll see more of this blending of human language and computer languages.

LLMs are completely comfortable weaving in and out of the two styles, and if we can just find the right syntax to enforce structure, then we can maintain a control plane atop the LLM in those places that it matters.