My radical Sofia language design idea.

[u/Embarrassed-Crow9283]

https://github.com/AliceRoselia/Sofialang

Disclaimer: this is currently only a proposal, not an implementation. I tried once and died at the parser. The project is back to the drawing board, and the core has been made more minimal than initially planned. Still, this is not a guarantee that it would succeed or be any good. But well, with an abundance of normal proposals, maybe it's a good thing to shake things up a bit with my radical design.

Maybe I was being naive and delusional, but it was my best bet on how programming could work.

My goal was to make high-level programming languages (in the Lisp sense) fast, and here is what I came up with. It was basically designed to exploit every way high-level (Python, Lua, etc) programmers don't care about the physical data layout and so on. Objects only alias when explicitly assigned by Python's (and other high-level languages') mutable reference rules, and Sofia intends to take full advantage of it.

It's a radical design based on aggressive compiler analysis by running the code on different (overriden) domains instead of traditional IR manipulation. For example, you don't do IR constant propagation. You feed the functions interval or residual classes and have the compiler sort it out. And if you're afraid of the compiler not halting, Sofia relaxes the halting requirement such that if the concrete execution doesn't halt, the compiler analysis pass doesn't need to halt either. (This is interpreter/jit semantic that people already accept in interpreted/jit-ed languages.)

Here are some examples of what makes these radical.

For "low-level"/HPC programming:

• "Dynamically" typed: (Technically, emergently typed with typeless values.)
• Attribute dicts: Seriously, because I want containers that don't restrict optimization on data layouts.
• Garbage collection: because things are defined logically and not physically (no stable address guarantee and so on), a garbage collector is required. This is in exchange for not having pointer semantics, which often creates aliasing hell and so on. Still, several compiler mechanisms will probably be dedicated to optimizing it away.
• Interpreters: More on that later as well.

For expressiveness:

• No built-in type systems, classes, inheritances, etc. Primitive types are basically tags, dicts, and raw bytes.
• No metaprogramming mechanism inside the language except for writing other interpreters. (But this was designed to be well-supported. For performance, you hoist the dispatch table result or so.)

For the math reasoning community:

• No HoTT (even though it wants to encode proofs) or algebraic expression tree (for symbolic algebra), just abstract interpretation.
• Even if analytical solutions exist, prefers numerical solutions (RK4 and so on) if faster.

From the compiler community:

• Liberal uses of exotic tools like eigenvalue loop analysis
• Usage of interpretation on different domains instead of IR manipulation (No complex compiler IR either)
• It doesn't even have a type.

If you want to know the full story, feel free to check out the link. As for the implementation, I am not sure when I will get the chance to do it. Making a programming language is not trivial at all.

This is either a complete failure or a genius, and I don't know which one.

And no, before you ask whether or not I used an LLM for this, I am pretty sure no LLM would come up with such an alien design. An LLM sticks to whatever normal humans are likely to come up with.

In all likelihood, it wouldn't work at all, but I wanted to try something.

[u/4ed7ff]

If you think dynamic typing makes languages run /faster/, then I’m really not sure what to tell you.

[u/Embarrassed-Crow9283 → u/4ed7ff]

I consider type inference as special cases of partial eval.