Anna's Notes

Ambiguity in Natural Programming

2026-06-27 · 4 min · #computing

I am once again thinking about programming in natural language.

For most programming languages, you can parse them according to strict grammars that eliminate their ambiguity. These can get ugly, especially for languages like C++ where one symbol can mean many different things depending on its context, but the code is, in theory, able to be parsed.

One of the biggest barriers for programming in natural languages, however, are their inherent ambiguity. Natural languages were optimized for efficiency and convenience in communicating between people. They were not designed for clearly communicating with machines.

This means that computer programs that try to understand natural language must do so stochastically. It is likely that the text means this. It is possible that a text means that. It's impossible to work with certainty, even if we had a language model with perfect knowledge of a language and the surrounding cultures.

One answer is to embrace the probabilistic nature of language and use Large Language Models (LLMs) for natural language programming. After all, they can already write code that seems statistically likely based on natural language prompts. This approach embraces the chaos.

The other answer is to describe a strict subset of a language and use that. Instead of trying to let the computer understand the entirety of what a user is saying, make the user explain it in language the computer will understand. This is still a computer language, but something more like the user's native language. This approach clings to rigidity.

Neither of these options are ideal, in my opinion. LLMs require a large amount of resources to use, shackling access to natural language programming to those who can pay to rent from large corporations or can afford an expensive GPU while costs are rising. Another computer language might ease new programmers into the concepts of programming, but they are still forced to describe their problems in a rigid language that punishes straying from its parser.

I'd like to propose a combination of the two. A language model that parses natural language but checks back in with the user to see if it has understood. This can be done by converting high-ambiguity sentences to low-ambiguity ones when appropriate and storing the latter as source. When the interpretation program is confused, it can check back in with the user to ask what they meant.

There are a few important differences between this and programming with an LLM. First, the source is unambiguous natural language, not prompts. This means we can retain deterministic pipelines and reproducible builds. Second, the language model needs to parse, not generate. This should mean that we can use models that are less expensive to run, opening it up to be used more wildly.

The goal is understandability. A system that produces consistent output based on given input is more understandable than one that doesn't.

In summary, there would be three main layers:

• Natural language (parsed by a language model)
• Computer language (subset of a natural language)
• Language-agnostic IR

The computer language is still considered the "source code". It is a common-ground understanding between both the user and the machine. It is expected that such a programming environment convert between the natural language to the computer language live to provide immediate feedback.

Once this is done, the computer language can be compiled into a language-agnostic IR that can then be compiled or interpreted. I say language-agnostic because the top-level natural language should be any language the user desires.

I haven't made a proof of concept yet, because this is outside of the realm of my current expertise. The current state of Natural Language Processing (NLP) is focused on LLMs and generating text, not interpreting it. I don't know if there are robust solutions for machines to understand human text beyond simply transforming it directly.

If anyone reading this has any suggestions or knows of any existing research in this area, please contact me! I'd love to hear your thoughts.

Scheme is a Hoot

2026-05-21 · 3 min · #computing

Lately I've been spending time learning Scheme and using it to implement the concepts I'm learning in my physics classes as time permits. One of the most exciting things I've been doing with this is getting my Scheme to compile to the Web thanks to Hoot.

One of the biggest challenges has been the fact that Hoot is unstable. It's currently at version 0.9.0. The documentation is decent, but it could be better. The error messages can be cryptic. But it's a massive accomplishment to see Scheme code running on the Web via WASM. It's even more incredible to know that it's running on a stack the team created themselves, not relying on Emscripten.

My initial understanding of Hoot was that it could compile any Guile program to the Web. I quickly learned that I was mistaken when my code wouldn't compile. I then ported my code to use the Hoot versions of all of the functions, causing my code to be unable to run independently from Hoot. I then realized that Hoot actually supported more of Guile than I thought. I just had to manually import a lot of the stuff I previously took for granted.

Now I have set up my code to run on native Guile and on WASM via Hoot, with tests automatically running in both to make sure everything's set up correctly for both environments. It's a bit of a pain, but it works now. Most of my code is agnostic to whether it's running with the system's Guile interpreter or if it's been compiled to WASM and being run in the browser. I think that's amazing.

Currently, most of the work I've done has been on the backend. Working on getting this whole setup to work at all has been a hassle. I've also been working on getting the more fundamental physics logic working, which is especially difficult as a someone new to Scheme. But I've been making progress, and I've published a small prototype on a new page on my website and have published the source code.

In the future I'm curious to see if it's reasonable to compile Zig + Scheme programs to the Web with Hoot. I'm starting to feel more and more that Zig + Scheme is the perfect combination and I want to do more experimentation in that direction. That may be too complicated! I don't know yet. There's a lot for me to learn in the WASM world, and that's a large part of the fun.

This has been an insightful exploration into the depths of Scheme. I can't wait to do even more.

Is it time to use Zig?

2026-04-16 · 1 min · #computing

Is it time for me to finally start writing Zig? I used to use it (and make minor contributions) years ago but got demoralized by constantly rewriting my code with updates.

But it seems like a solid language and one that will only increase in prevalence in the coming years.

Learning Special Relativity

2026-04-13 · 1 min · #physics

The number of ah-ha! moments I've had when learning about special relativity is incredible (at the cost of the constant pain of "how on earth is this possible").

I knew how to do Lorentz transformations before and even wrote some code to represent them, but now I'm finally building an intuition for special relativity instead of primarily relying on the equations.

Can't wait for general relativity to mess it up once again!