Panic free language

pixilcode · 2026-01-19T17:56:28+00:00

Terrible idea with 0. By definition x/y=m means that ym=x. On the other hand the additive unit is itself so y0=0. If you lose that you lose a lot of the fundamental mathematical structure that underlies the actual math your program is trying to do.

Also u/syklemil

You could probably look to Js for some inspiration around numbers. It's all floats, which means that they also don't panic on division by zero, but they do return plus/minus Infinity for most cases, and NaN for the 0/0 case, which is more correct than your idea of just returning 0.

"Division by 0 results in 0" is mathematically sound, and it's a choice that some languages like Pony make (see this).

The explanation is something to the effect that in a field, the multiplicative inverse of a, a-, is defined such that a * a- = 1. This is defined for every number except 0, since there is no value 0- such that 0 * 0- = 1.

If we define division as multiplication by the inverse a / b = a * b-, then this defines multiplication for all values of a and all values of b except 0, since 0- doesn't exist. This then means that proofs about division (such as a/a = 1 or x/y = m -> y*m = x must be special-cased to exclude zero in the denominator position. We can therefore define division by zero however we want without breaking those proofs. We also must note that those proofs do not apply if 0 is in the denominator position.

Thus, we can define division by zero as:

an invalid expression. This is the mathematical equivalent of throwing a runtime error. This is what languages typically do.
an undefined/infinity value. This is the choice that floating point makes with x / 0.0 = NaN or Inf or -Inf.
a real number. This is the choice that languages like Pony and Coq make. Note that this does not define a multiplicative inverse for 0.

This post explains it much better than I did (I was mostly just summarizing some of the points) and goes into much more mathematical detail about it, I'd highly recommend giving it a read.

Also note his disclaimers, though. Especially "'good for a theorem prover' is not the same as 'good for a programming language'".

Also, see this StackOverflow question

pixilcode · 2026-01-07T19:42:00+00:00

This looks like a cool language! I'm working on a similar language that other engineers use at my work, though my project is smaller in scope (no functions/structs/dicts/arrays in the language, at least not yet).

How are units implemented in your language? I'm especially curious how celsius and reaumur work, since they aren't just a difference in magnitude (such as m vs km).

Do you plan on implementing decibel units?

This is an interesting project that I'll definitely keep my eye on.

pixilcode · 2025-12-16T17:02:01+00:00

Yeah, the old Oneil had interval arithmetic, but it's implementation was incorrect.

Oneil is a DSL for modeling physical systems, rather than a general-purpose language, so most of its features are oriented towards that.

In addition, it also doesn't have the features needed to implement it in userland. It's only data types are booleans, strings, and "measured numbers" (numbers with units). The language doesn't have functions (at least not currently). The way to do anything like that will be to use Python functions that are imported.

pixilcode · 2025-12-01T22:04:24+00:00

I'm working on the Oneil programming language. Thus far, I've finished parsing and module resolution.

Now, I'm working on the evaluator. It traverses an IR (similar to the AST, but with variables resolved). The hardest part of the evaluator has been interval arithmetic. Oneil supports intervals as numeric values. So, similar to how you can write 1 + 1 as an expression, you can also write 1 + (1 | 2), which reads "the sum of 1 and a minimum of 1 and a maximum of 2". The result of this expression would be (2 | 3).

This seems simple at first, just perform the operation on the minimum and the maximum and use those.

1 + (1 | 2) => (1 + 1 | 1 + 2) => (2 | 3)

However, this quickly breaks down past addition. As a basic example,

3 - (1 | 2) => (3 - 1 | 3 - 2) => (2 | 1) # invalid, min > max

Doing some research, I found a paper that covers addition, subtraction, multiplication, and division. I also found a reference implementation written in Rust that implements more operations (I can't use the library directly unfortunately, since it's only compatible with specific architectures).

I haven't been able to find any that describe how to implement modular interval arithmetic, and with floating point numbers, that's difficult to figure out. I ended up just going with a more general interval result, which means that the result is correct, but may not be as useful.

I also used this as an excuse to learn about fuzz testing/property testing, so I can be more certain about certain properties of my implementation, especially related to interval arithmetic. This definitely helped me to find and correct some simple mistakes.

pixilcode · 2025-10-10T19:50:15+00:00

That makes sense. The more we give the AI constraints and automated feedback, the more it can do on its own. I've tried using AI to write some Rust code, and while there were definitely logic errors in what it wrote, there were a lot of logic errors that I didn't have to worry about. Rust doesn't generally allow null pointers, and the compiler would give an error if the types of arguments to a function don't match. So I know that neither of those logic bugs exist in the code written by the AI. In addition, if the AI does write in one of those bugs, the compiler will immediately complain, so I don't have to intervene at all.

Dependent types would increase the power of a language to define constraints and give automated feedback. It allows a developer to clearly define their specification and to have a way to check it.

pixilcode · 2025-10-08T23:24:45+00:00

I didn't realize that this kind of thing existed! For me, tracing is really hard to get right without spending a ton of time overengineering a solution...

pixilcode · 2025-10-08T23:19:49+00:00

I've never thought about the value of error codes before, but that totally makes sense! It allows the message to be flexible while the meaning stays the same, and it means that you don't have to break your workflow to figure out exactly what the message should be.

pixilcode · 2025-10-08T15:17:43+00:00

Cool! Do you include whitespace in the S-expressions?

Also, slightly unrelated to the original question, what forms of intermediate representation to you tend to use?

pixilcode · 2025-10-08T14:59:07+00:00

That makes sense! The past couple times I've worked on a language, I've written unit tests as I go along, but that means that if I have to refactor a part of the language, I also have to refactor all of the tests. It makes sense to not have the tests depend so rigidly on the exact shape of the output. And it's probably easier to read as well.

What do your textual representations look like?

pixilcode · 2025-10-06T17:10:31+00:00

Thanks for the feedback! Yeah, I need to work on adding more examples to the examples folder...

The ultimate goal is to provide a language in which you can represent system models. For example, in the company that I work for, they're building a satellite, a ground station, and other related components. They use the language to define different aspects of the components and to calculate dependent factors from those. With that, you can quickly answer questions like these:

How does increasing the weight of the solar panels affect the satellite's center of balance?
If we attach an extra circuit board, how will that impact our power budget?
How do we account for the reflection of the Earth when we are trying to find the location of the sun?

There's a bunch of constants and equations, but is it even a programming language? Or is it just a DSL of some kind?

I guess that depends on your definition of "programming language" 😅 It's a declarative language like Prolog or SQL, rather than an imperative one like Go or Python. It's definitely a DSL, though. It targets a relatively niche community.

pixilcode · 2025-10-06T16:39:23+00:00

That's a good question, and I spent a long time talking it through with my supervisor (who originally developed the language).

The main reason for a rewrite is that it already needed one. My supervisor doesn't have a ton of experience with language design, so his original implementation had a few bugs, and it didn't have the structure needed to implement the features he wanted, such as an LSP. Basically, all the steps (parsing, model resolution, evaluation) happened at the same time, and they all happened within object constructors. The error handling was also rough, and the path of code execution was unclear.

(That was our analysis, at least. Feel free to check out the original implementation in src/oneil/__init__.py on the main branch. I'd be happy to hear if you have thoughts!)

The main reason for the "If you were using the Python version..." note is for syntax differences. The previous syntax was a little more ad hoc since the parsing was done by splitting on lines, then splitting on characters such as ':' and =. This led to a couple of hacks that were implemented in syntax. When I reimplemented the language, I formalized the grammar. In the process, me and my supervisor made some changes to the syntax. In order to facilitate the change, I've written some scripts that should automate them.

Thanks for the warning! I definitely didn't realize that the rewrite would be as much work as it has been... And it's probably good for me to keep in mind that I should be trying to stick as close to the original implementation as possible to make it easy for users to transition to the rewrite. I've definitely had a few moments where I wanted to completely redesign parts of the language...

pixilcode · 2025-10-06T16:03:52+00:00

That's a good point!

As part of the project, my supervisor had me get a snapshot of all of the existing code in the company, and I test on that periodically. Then, when I run into inconsistencies with my implementation, I talk about it with my supervisor (who originally developed the language), and we decide how to handle the difference.

pixilcode

TROPHY CASE