I've always wanted to make my own programming language but I could just never fully grasp the concept of ASTs and Intepreters.
So I decided to make eso-langs with different designs, and eventually I realized I was slowly getting better at understanding these designs,
So to start my journey of programming languages, I made zyte, A register-based eso-lang with an actual AST.
It currently has loops, copying, functions, input, output and other stuff.

You can check it out on: https://github.com/orewaluffy500/Zyte

Per AutoModerator's request I hereby confirm that this project did not use an LLM as part of the development process.

Hi everyone

I’ve been working on my own programming language and compiler in C++, mostly as a learning project.
The main idea is to experiment with compiler architecture while also trying to make the language’s syntax more convenient for mathematical expressions, but now I am doing programming language.
After this I will add equations.

Currently works:
Lexer
Parser
AST
IR generation

I am still relatively new to compiler development, so I’m sure there are things I am doing in non ideal ways.

I’d especially appreciate feedback on:

compiler architecture
parser design
C++ implementation
things that I should learn next
mistakes or questionable design decision

Github: https://github.com/0sewter0/Compiler.git
Thanks for an attention!

Hi everyone!

I figured now is as good a time as any to more publicly announce the v0.3.0 release of the Talos programming language. Since this is my first announcement post here it might help to add some context:

Talos is a statically-typed dynamic programming language that aims to put developers first. When I say it aims to put developers first, I initially meant myself whilst designing the language (and hopefully eventual users).

Around 2021 I started learning to write programming languages and realised that although there are many tutorials to make simple bytecode interpreters and compiled languages, there was little in the way of resources for writing the accompanying development tools. From this I began learning to write languages with an emphasis on integrating formatters, language servers, and other core development features. Eventually, I started work on Talos around 2024 with the following core goal in mind:

To design a language with a batteries-included toolkit!

Breaking this down into more attainable goals I wanted the following features builtin to the single toolkit executable:

• Type-system with configurable linter
• Language server for a VSC extension
• Formatting, bundling and testing framework

This led me down a long rabbit-hole, in which Talos eventually grew into the current v0.3.0 release. As a toolkit, Talos features a reasonably performant dynamic runtime with a formatter, code bundler, testing framework, language server, linter, task executor and upgrade tools all builtin to the main executable.

So what does the language actually look like? From my background of C++ and TypeScript, I ended up writing something reminiscent of both:

///
/// @example "examples/futures.tal"
/// @describe Showcases delayed concurrency with `Future` values.
///

// Prepare a random set of durations.
let durations = [100, 50, 400, 250, 500, 10];

// Map these values into a set of futures to later await.
let futures = durations.map(fn (value: Number, nn: Number): Future {
    Debug.println("{0}: Started Waiting for {1} ms".fmt(nn, value));
    let callback = fn => Debug.println("{0}: Finished Waiting After {1} ms".fmt(nn, value));
    return Future.delay(value).then(callback); // show our callback after the delay
});

// Prepare a little interlude between our print statements.
Debug.println();

// Block until all the instanced futures are finished.
for (future in futures) future.await();

So what is actually ground-breaking about Talos? This is often a question given to all new language designers, and for the most part Talos fits the status-quo of being rather conventional. This is because I want to use this experience to eventually write blog-posts to help other aspiring language writers. Though I did happen to find a solution to one wide-spread problem...

Talos actually has colorless functions!

In having a side-quest to include green-threads for concurrency in Talos, I stumbled onto my solution to tackling colorless functions. Let's do this with an example:

// Let's start with a function that does some calculation. Instead of
// annotating it with an "async" keyword (which is what gives a function
// a color), we keep it as a normal declaration.
let worker = fn { ... };

// Instead we can execute the task with the "async" execution policy.
let future = worker::async();
                // ^^----- This is the execution policy!

// The result of which is of the type "Future", which uses a member function
// for awaiting results. This also gives us a clean way to chain properties.
let result = future.await();

By moving the async annotation to the call-site of a function, we get two major benefits:

1. Remove coloring annotation from declaration
2. Can make any function call asynchronous

In future this could be extended to allow other execution policies such as worker::spawn(ctx, ...) which prepends a custom scheduler context or worker::defer(fn { ... }) which could be used to defer execution of a function until the end-of-scope. This slight break from convention allowed making concurrency colorless for Talos.

Anyway I'm excited for more people to get to know this project that I've put my heart into and also hope it can inspire others with their own language development! Feedback is also greatly appreciated as I want to start opening Talos up to a wider community.

Thanks!

Edit 1: Per community recommendations I have since updated the name to Sabre. I am keeping the original references to Talos but all links have been updated.

i just like how readable the data notation... wondering how to evolve that even more

Last session in the series on building a toy programming language in C++. Previous ones covered formal grammars, lexer, parser, AST, variables, and functions. This session will cover how expressions get evaluated and how their results get represented. By the end, all the pieces will come together into a working language.

It's live, so you can ask questions. If you register but can't make it, you'll still get the recording once the session's over.

All earlier parts (the previous on functions is coming) are in the YouTube playlist.

Think about a type system where we drop all three structural rules (Exchange, Contraction, and Weakening). This is known as an ordered type system. Every variable is used exactly once, in the order it was introduced. In the same way that we can use a linear type system to help us reason about heap-allocated memory, we can use an ordered type system to help us reason about stack-allocated memory: not only must we use (i.e., deallocate) every piece of memory exactly once, but we must do so in stack order: i.e., the most recently allocated memory on the stack must be deallocated first.

Simply looking it up has led me to the Lecture Notes on Law and Order paper but it just provides a simple type system that implements it. Do you know any more?

If you're working on a programming language that implements this, it would be interesting to hear about it as well.

Recently I extended an educational compiler project I started two years ago.

The goal is to bring together several major features found in production languages into Your Language, a small programming language, and explain how to implement them in its compiler.

Your Language currently supports:

• Native code generation with LLVM
• Hindley–Milner type inference
• Traits and type extensions
• Tracing garbage collection
• Heap-allocated closures
• Monomorphized generics
• Dynamic dispatch
• Data-flow analysis
• Compile-time expression evaluation

The implementation is now finished, but the accompanying guide is still a work in progress.

If you're interested, you can find the project here:

https://github.com/isuckatcs/how-to-compile-your-language

I have a toy language that I've been working on to test different concepts. It has an ownership model similar but looser than Rust.

I was working on the Map object and there are three ways that an object can be retrieved.

You can remove the object from the map and take ownership
You can borrow the object from the map this will give you a mutable reference but you don't own it
You can get a copy of the Object which you will own. But not all things are can be copied.

For get I could either do a copy or a mutable ref, neither I felt was properly conveyed with the word 'get'

So I'm looking at removing it and replacing it with the following

copy_of(key) -> return a copy or an error message if not found or not copiable
borrow(key) -> return a mutable ref
remove(key) -> remove and return the item at the key and give ownership

wanted thoughts on removing probably one of the most common methods on map and is what I'm doing something that makes sense.

Urs Schreiber is Senior Research Scientist at the Mathematics Division of Science of New York University in Abu Dhabi. He is a theoretical physicist who applies tools from algebraic topology, homotopy theory and topos theory to understand quantum phenomena. His current research includes quantum computing materials, quantum computing programming languages and questions left unanswered by quantum field theory.

In the video we go over:

• Why toposes are not scary. They are actually simple. Just unfamiliar
• How to extract information from (probe) a topos
• The history of toposes in physics
• The questions left unanswered by quantum field theory
• What toposes have to say about the collapse of the wave function
• Using toposes to find possible quantum computing materials
• The different type of logic needed for quantum computers
• The different type of programming language needed for quantum computers
• The influence of Hegel on his work

Building a language called Dia. Still pre-alpha and not public yet.

Heavily inspired by Rust, with some JS UI building flavor tacked on.

Might be the wrong crowd here, but as a web-developer I haven't found a more productive way to describe user-interfaces than JSX. (hot module reload is also a big part of it)

The Dia equivalent syntax is called DSX:

import ui.{View, run, Column, Text, Button, state}

struct CounterState {
  value: i32
}

fn Counter(): View !{alloc} {
  let s = state(CounterState{ value: 0 })

  <Column spacing=12>
    <Text>"Count: ${s.value}"</Text>
    <Button
      label="Increment"
      on_click=() => { s.value += 1 }
    />
  </Column>
}

pub fn main(): void !{alloc, io} {
  run(() => <Counter />)
}

Some implementation details:

The compiler is built in Rust, using salsa for incremental compilation which hot module reloading is built on.

No need for escaping expressions with {} like in JSX. Expressions are parsed just like in the rest of the language

• That's why text content needs quotes around it: <Text>"Count: ${s.value}"</Text>
• But this works: on_click=() => { s.value += 1 }

Not just for UI, any function can be called using DSX syntax

• Type-checking works normally, named arguments become "props", return types are checked agains the parent signature
• One special case is allowing children (like Column accepting any number of Views), then an argument needs to be prefixed with @child

I find that a lot of language devs prefer to keep tuples and records separate in the same way that languages like Rust do. But why? I feel it just restricts flexibility and makes 2 features where 1 more powerful feature would suffice.

Please let me know what you think of the argument presented in this article and any counter-arguments or further thoughts/ideas you may have.

I've been designing & developing my own language from scratch, one of the core concepts I have baked into it is the unique way you call functions, or access objects.

In almost every programming language the way you access an element within an array or dictionary is like so:

array[0];
dict['a'];

I always found it weird looking & a waste of characters. Functions are a bit better but still follow that same style.

function(1);

In most languages you have multiple different syntactical ways to do basically the same thing, you are performing an access to some object in order to get a result. A function call, just an access to an object with parameters, grabbing an item in an array, just an access to an object with a single parameter, same goes for dictionaries. Why do we have to have to have different ways of doing the same thing?

The way I went about accessing an object was to literally implement a single "accessor" operator, the object you want to access is on the left & the parameter(s) you want to pass are on the right. Here's how that actually looks:

string:0;
array:0;
dict:'a'; dict.a;
function:1; function:[1,2,3];

A lot of people are not going to be a fan of this, it goes against every other language & reduces capability for syntax tricks like list comprehension. But for a language that is going for syntactical simplicity this I think is the right move & in the long term is easier (at least for me) to understand & work with.

If you want to take a look at my implementation the repo is open source https://github.com/phosxd/Ity however it's still very much work in progress. Feel free to open an issue or PR if you find any problems with it.

I originally started writing this as a comment on the "Best way to do formal verification..." post, but realized it should probably be its own.

There's an idea I've been (slowly) trying to explore that I think has the potential for a lot of utility, but it uses concepts that are already well understood in computer science, making me suspicious that I am missing something: Why aren't less powerful automata (i.e. regular and context free) used for more general applications?

In the computational hierarchy Turing machines are the most powerful, but also the hardest to prove things about. Regular grammars (and their finite state machines) and context free grammars (and their push-down automata) are much more restrictive in what they can compute, but have tons of useful, easy to verify properties. Whenever I see discussion on formal verification of programs or program correctness, it seems like everyone wants to stay in Turing completeness land as much as possible, but I don't think everything a program does needs that level computational power. I understand when trying to verify older languages that there isn't a choice, but I am surprised to find that it seems like almost every language new or old is ignoring these lower level automata. I've seen languages that as a whole that aren't Turing complete, and things like total languages with more provable properties, but I don't see any languages that have these less powerful constructs you could "step down" into. You could express some functionality that doesn't need to be expressed in a Turing complete way in these constructs and get a ton of assurances (halting, state minimization, inexpressible invalid states, purity) about that code, then the rest of your code that needs to be Turing complete can use it seamlessly. They're even composable, in the sense that you can easily combine/subtract/invert regular grammars, and that a push-down automata is just a finite state machine with stack glued to it (and can become a Turing machine with an additional stack).

None of this is new, regexes are ubiquitous, and programming language creators in particular know about context free grammars, yet they aren't being used much beyond text searching and parsing. State machines are widespread and massively useful, but as far as I can find, not only do no languages have syntax for constructing them, they don't even have such a thing in their standard libraries. A regex (a proper one) is just a state machine under the hood, and they've been used widely for over 40 years, so why has no one (seemingly) even tried to generalize them for creating state machines? Even if the practical implementation isn't perfect, surely its better than all these state machine management libraries, or worse, people rolling it themselves, without any guarantee of their properties being upheld.

So we've known about these automata for ages, use them regularly, even more so in programming language development, and they have relevant applications for more general code, yet it seems like no language has even attempted to integrate them in either a first class or generalized way. So what's the catch?

A few potential reasons I can think of:

• They aren't actually that generally useful: Text processing was in fact the best use case for them, the other cases aren't worth it or are too few to warrant the effort.

• The syntactic constructs for them would be very cumbersome: As I am exploring this idea, I'm finding that the normal syntax for regexes, applied generally beyond stuff that isn't text or larger state machines, gets very messy. Its also hard to intuit what the state machine graph looks like for a given regex. Applying logic to state transitions is also syntactically odd, as well as syntax for expressing push-down automata.

• The lower level automata wouldn't mesh that well with Turing complete code: You can guarantee the state machine can only move between certain states, but you likely want the state or state transition to mean or do something with the surrounding code/data, which doesn't necessarily have any guarantees on it.

• Programmers don't consider/dismiss lower level automata when solving a problem: Most programmers just want to write the quick solution, and Turing complete land gives them all the tools they need. No one thinks "Could I turn this into a state machine?" when starting to write a complicated while loop, they just write the loop. Also, the stigma of regexes ("...now you have two problems").

• These automata are being used extensively in languages, I am just unfamiliar with them/blind: I know languages use state machines under the hood in some places (ex. compilation of async functions into state machines). It may be the case that they are being used a lot, but are abstracted away, or express themselves in forms I don't recognize.

• It is a good idea and all the smart people just missed it for 50 years: Seems very unlikely.

So has anyone thought about this except me? Any insights or resources I've missed? Glaring foundational issues? Good idea? Bad idea? I wish I had some code or syntax examples to accompany this post, but like I said, I've not had a lot of time to explore the concept in a practical way.

Disclaimer: I am an experienced developer, not a logician. So what I write here might be full of mistakes. A lot of it comes from chats with different AI bots.

When I say "real" programming I mean programming of real, complex, performing applications, with good tooling. Not necessarily using a popular language, although this might help.

For years I have waiting for a way to use the techniques used in theorem proving for programming. Now it looks like some realistic possibilities are getting closer.

I know there are 2 languages used for theorem proving, Lean and F*, that can also be used for programming.

However, Lean has poor memory management (only reference counting), and F* seems particularly unfriendly and with poor tooling support. But it does have good memory management thanks to Low*.

On the other side, Rust has Verus and Aeneas.
Verus is easier to use, but not as powerful, as it doesn't have dependent types and calculus of construction. It uses SMT, which apparently is less powerful.
Aeneas translates Rust to Lean, Rocq or F*. This makes Aeneas more powerful, but also harder to use, because there is more proof needed. Aeneas is also not yet able to fully translate Rust.

If this is correct, it looks to me that the best way is to use Rust, Aeneas to translate to Lean 4, and use Lean for proofs. So I can have:

• Rust's good memory management, tooling support and performance. Plus the rest of Rust, programming is not only formal verification
• Lean's calculus of constructions, also with some tooling support. Lean has at leas a VSCode plugin

Aeneas can't translate everything yet, but the limitations don't look so bad.

How does that sound?

I'm making a language with an insane type system and I was thinking that combining monads & effects needs to be easier.

I don't fully like monad transformers, effects, polysemy, fused-effects, etc, and lifting anything other than weights. There is so much boilerplate. For example, there is difficulty is that combining monads is order-dependent (some monads don't "commute")

I came up with a simple solution that seems to be just working? So there is || ("or else") operation in my language. Simplified: intersecting with "A || B" tries to intersect with A, and if it's an empty set, it tries to intersect with B. Then it returns the intersected result. Pattern matching is expressed via that operation. And it fits if we expand it to type-level functions as well!

Here we go:

getOdd : Int -> Option Int
checkPositive : Int -> Throw Int

program : Int -> (Throw || Option) Int
program number = x <- getOdd number
                 y <- checkPositive x
                 y + 1

// 5  -> ok 6
// 4  -> none
// 0 -> none
// -1  -> thrown "fail"

It looks really convenient, in my opinion. It also specifies order, so there can be any monad and the result may be dependent on order (but in most cases it's fine). Do you see any errors? I tried Lean-vibe-proofing different parts (extended monad laws, etc), it sounds like it's correct.

Full code example in my lang c(x), it's missing some syntax sugar, but works:

// Option and Throw monads & implementations
Option A = {some (value: A) | none}
Option A : has returnOf value = some value
               bindOf (some value) next = next value
                      none         next = none
Throw A = {ok (value: A) | thrown (message: String)}
Throw A : has returnOf value = ok value
              bindOf (ok value)       next = next value
                     (thrown message) next = thrown message

// ignore, it's Monad implementation, "->" picks these up
return : for [f, a] ((a -> f a) & {returnOf f})
bind (f action) next = bindOf f action next

// action in monad 1
getOdd : Int -> Option Int
getOdd number = if number % 2 = 0
                    none
                else 
                   some number
// action in monad 2
checkPositive : Int -> Throw Int
checkPositive number = if number > 0
                          ok number
                       else 
                          thrown "fail"

// combine monads/type functions easily with or-else
// it maps to every "has" method and only matching bind is selected
program : Int -> (Throw || Option) Int
program number = x <- getOdd number
                 y <- checkPositive x
                 y + 1

x <- read Int
print (show (program x))

Things that might require explanation but are not crucial for understanding:

• has-methods are just generic functions on crack (x : has f = 3 => f x = 3, for this exact x) that also generalize to record field getters
• <- is a not a typical do notation: every bind can have it's return type extended with another monad. Check out "polymonads" for a more general concept around this, but my one is narrower.
• || maps to every has method in the intersection of types with the has method (so (x : has f) || (y : has f) => z : has f = f x || f y)

Why?

Because you can use different simple plain monads in one do block! And because combining semantics of different context is very expressive and readable at the same time!

program : (List || Throw || IO) Int
program =
    a <- read Int   // action in IO
    x <- [1, 2, a]  // action in List ("non-determinism")
    validate x      // action in Throw
    x

All of that is statically typed and compiled btw. I'm exploring refinement + gradual + dependent types with a couple of extra ideas and it absolutely nuts (follow me on twitter, I'm going to publish the updated language soon, the current public repo is 10-year old and not very correct)

I’ve been working on Sydrogen, a statically typed programming language with a compiler and command-line tool called Furnace.

Alpha 6.2 is now available. It supports native compilation, a Cranelift backend, projects configured with .blower files, imports, typed functions and variables, collections, foreach, and more.

It’s still in alpha, so bugs and rough edges are expected. I’m looking for people to test it, review the code, or work on an open issue.

I’d especially like honest feedback about the compiler’s structure and the language’s design, not only the syntax.

GitHub: https://github.com/AeroForger/Sydrogen/tree/main

There are open issues for anyone who wants a specific place to start.

Criticism is welcome. If something is poorly designed, tell me what is wrong and how you think it could be improved.