Chat-Native Output in Kaya

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 unreleased, but I thought I'd blog about some of the ideas.

In this post: Chat-Native Output

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 say it like this:

<?php echo "hello"; ?>

But that's not necessary because output is the default.

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

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?

Kaya is output-defaulting and chat-native

I really like the idea that Kaya could read like chat room log. Chat messages are the data abstraction we've adopted for LLM scripting, and they're also a near-universal UX. So to the extent that every programming language needs a core idea to anchor its design, chat feels as good as any to use.

After playing with a bunch of different syntaxes, I think RenPy comes closest to that while still permitting code to weave naturally in. I prefer the [Name] style formatting over Name: style formatting, so that's what Kaya uses:

[Narrator] "The wind howled outside."

[Ted] "What was that?"

[User] "Probably nothing"

I think we don't even need to require a username; we can just reuse the last one invoked if it's absent:

[Narrator] "The wind howled outside."

[Ted] "What was that?"

"Did you hear that?"

[User] "Probably nothing"

To pull this off, I believe we need three things:

• A parsing strategy that treats lines as meaningful, just like Python treats spaces as meaningful. We'll classify each line as a code line or a dialogue line.
• A small set of tokens that could possibly begin a code line. This means the keyword set (if, for, etc) needs to be relatively small, and we probably need some perl-style prefixes to functions and possibly variables. Otherwise a function like myFunc() would appear to the parser as raw text.
• An escaping strategy for starting a dialogue line with a code token: any line that starts with [ or a quote gets priority parsing as a dialogue line.

I think that gives us a syntax that would look something like this:

[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}}."

In this code:

• " on a line by itself indicates a dialogue line
• set is a keyword required for setting a variable
• {{name}} implies automated string templating against the local stack frame

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. Rendered completely to output, it might look something like this:

[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.

If we had wanted set name = input() to be dialogue we could have written it either of these ways:

[Ted] "set name = input()"

"set name = input()"