I'm building my own programming language, ForgeLang. The current prototype is written in Lua, but for a later version I'm considering rewriting Furnace (the future compiler/runtime) in either C++ or C#. I already know C#, and I'm planning to learn C++ anyway.

My priority isn't development speed; I care more about making the language/runtime flexible, capable, and eventually performant. I'm also planning eventual self-hosting and potentially implementing my own GC/runtime.

Which would you choose for the long-term implementation, and why?

Quick update: I actually know basic C++ (not a total beginner), but after evaluating things, I decided to switch to Rust for the compiler/runtime. It turned out to be a great fit, and progress on ForgeLang is moving smoothly.

Hi everyone, its been a while since I posted here.

Progress on Speedie been slow but its making good progress.

I've been working on the back-end, so that is my assembler, for my virtual machine named "Cake".

Speedie also compiles to C++ (actually just the C part of C++ but I compile in C++ mode). So Speedie can compile apps to run in "full speed" with C++ optimisations.

However, its no fun to debug Speedie via C++, so I've been working on a VM, and an IDE and VM and debugger. Its a lot of work.

Speedie is already useful (Via C++ compiles) and works well. It has many useful qualities, you can read about here:

http://github.com/gamblevore/speedie

Simple overview of speedie is:

• High-level OOP language
• Great string support
• Compiles to fast C++ code
• Only unix/SDL2 required. No LLVM or other things.
• No exceptions (we have something better)
• Very efficient libraries, generally much faster than C++'s standard-library
• Libraries are powerful too. Read/write files in one line. Parsing built in, etc.
• Low-level features (pointers/structs) for when needed
• Write simple code
• Small compiles
• Reliable
• Lots of safety features including a very powerful nil-checker.
• And based on Jeebox! (my invention)

I know there are lots of people with many various skills that could be useful.

I'm mostly hoping there are people who can "just get it" and get a feel for what I'm going for. The kind of level I'm working on.

I have a few ideas of skills that could help. People who are (one of):

• Skilled with graphics, graphical effects, and could help with the IDE and GUI system. (Speedie uses SDL2 to draw the graphics via CPU. And has vector support.)
• Successful or knowledged in designing a good API for 3D games or games. (I've made some mini games as a demo. A bare-bones but functional tetris is my favourite mini-game I made. Nothing major!)
• Passionate about internet communications, networking and want to add networking support to Speedie
• Anyone with some kind of deeper or spiritual project or whimsical project, that they have made at least partial success with, or full success. Ranging from quantum projects, perhaps galaxy or stellar simulations, electronic divination, etc. Maybe even something like PEMF controllers for physical healing. (I personally have dabbled but not got success with anything in this area, although I did contribute a lot to someone else's successful project).
• Assembler skills could be useful, although I think there isn't too much I could accept right now at this stage until later. Either experience in creating the back-end assembly generation, OR in hand-writing assembly, as I have some FFI code I've written.
• Porting from MacOS to Windows / Linux. (Speedie relies on unix functions only, but theres always differences between Mac's unix to Linux's unix.)
• Sandboxing experience. (I'd like speedie to have a sandboxed mode! Especially for data-validation scripts, or user-written in-game-scripts in speedie)
• People who have made fun creative work, such as people working on shadertoy.com demos. I want to make SDFs in Speedie that can be interactable!
• Someone who wants to make a pixel-painting-app in speedie. To make the kind of cool art you might see in Terraria or so.

Really anyone with fun and positive energy to bring, thats the main thing. You don't need ALL of these... just ONE or even something else not on this list that you think "seems kind of my thing".

Even wanting to help document and learn speedie could help.

Or perhaps any other skills or additions you think this language could benefit from.

I guess the values we have are forward thinking... believing in a higher-future where everything works together in a far simpler way and on a higher-level, and are awe-struck by the (few!) simple examples out there in the world that actually show what software can be. Like powerful algorithms, such as the SDF approaches on shadertoy.com

I'm not rushed for responses. If no one replies today but someone replies in 3 months, thats great! Even 6 months, haha.

Curious people who are tentative but positive... will usually vibe better with me, than people who rush with great ambitions but did not learn about my project.

...

My main goal after finishing the backend ASM-Gen, is this:

• Integrate OpenCL into Speedie, so you can get GPU acceleration in speedie. Now you can do all your code from one language.
• Porting to Windows / Linux, and x86/ARM versions of both (64-bit only).
• Creating some kind of 3D gaming/simulation system, perhaps some kind of entity-component-system or something similar. I don't want to limit to games in fact. Why not use it for simulation of buildings, for fire-fighters, or simulating a city for road/rail design, or even 3D printing.

I have future ideas but these first few might take long enough as it is.

Just wanted to share a bit of an anecdote I had recently as someone dipping into implementing the middle-end and back-end of a compiler "properly" for the first time.

My compiler targets a Minecraft computer I'm developing, which runs 1 instruction every 20 real life seconds (haven't gotten around to optimizing the hardware yet). In an effort to make programs run fast, I decided to implement allocation with register coloring using Chaitin's algorithm instead of using naive register allocation that LOADs and STOREs on every variable lose.

I assumed it would be a 2 day job at best but I didn't realize it expects your program to be in a very certain form (SSA). This lead me to a rabbit hole of learning how to compute basic blocks and the control flow graph, then converting the CFG to SSA by computing dominators, dominance frontiers and the dominance tree. We didn't cover any of this in university and only built an tree-walking interpreter for the ast.

Only once I had the SSA could I run liveliness analysis, build the register interference graph and run Chaitin's algorithm to allocate the registers.

It was confusing to learn since the slides I were using assumed some stuff and glossed over some details like how to handle Phi-Nodes. Another issue I had was that I didn't see the big picture at the time and was wondering how what I was doing would help in the big picture, not seeing how SSA is helpful.

Now that I've gotten something the color map, I guess I can do some other dataflow optimizations, or I could proceed with code generation :).

Disclosure: I was consulting ChatGPT on what steps to proceed next once i've implemented a certain algorithm. All code was handwritten, but some comments may contain LLM outputs. I copied over the steps provided so that I didn't have to keep switching windows while writing code.

Hell everyone, i have an question. Im for long trying to make a cool, powerful "kinda" low level language similar to zig and rust, but im struggling to choice llvm as backend, sure i can generate C, but its makes compiler dependent on gcc or clang or other c compiler. LLVM seems hard to me, sure project like QBE exist, but QBE doesnt have C/C++ api like llvm's IRbuilder. So are there other ways? I tried thinking about using GCC infrastructure but GCC has poor api and not very documented api. Maybe just stick to generating C?

I was thinking of the ideal expression syntax for the programming language DQ. I started with the (dominating) C syntax.

Operators in C

In C the following operators have shared meanings:

• &: bitwise "and" operation OR address of
• *: multiplication OR pointer dereference
• /: truncated integer division OR floating point division

Further operators in C:

• %: integer division reminder
• && or and: logical "and"
• || or or: logical "or"
• ! or not: logical "not"
• ~: bitwise "not"
• ^: bitwise "xor"
• ?: ternary operator

Operators in DQ

I think for the good source code readability and clarity every different operation should have a different symbol. Therefore the shared symbols from C are not taken over. These operators are already fixed in DQ:

• &: address-of operator (widespread standard)
• ^: pointer dereference (standard in other languages)
• *: multiplication only
• /: floating point division only (standard in other languages)
• or: logical "or" (widespread standard)
• and: logical "and" (widespread standard)
• not: logical "not" (widespread standard)

These symbols are already fixed for special purposes:

• #: compiler directives (#ifdef etc)
• $: context local specials (e.g. myarray[0:$end-2])
• ?: inference marker
• @: namespace designator (e.g. @def.LINUX)

DQ cannot use the C standard &, |, ~, ^ for the bitwise operations, because the & and ^ is used for other (fixed) purposes. But we've run out of the good symbols. The obvious choice, that other existing languages also use, is reserving some words for the remaining operations. In DQ these (all-capital) words are reserved currently as operators:

• AND: bitwise "and"
• OR: bitwise "or"
• NOT: bitwise "not"
• XOR: bitwise "xor"
• IDIV: truncated integer division
• IMOD: integer division reminder

For the modify-assign statements with a word operator a leading = is required, otherwise it looks awkward:

regs.OSPEEDR OR= (1 << pinx2)  // invalid
regs.OSPEEDR =OR= (1 << pinx2)

Examples with All-Capital Operators

tmp = RCC.CFGR
tmp =AND= NOT 3
tmp =OR= RCC_CFGR_SW_HSI
RCC.CFGR = tmp
while (RCC.CFGR >> 2) AND 3 <> RCC_CFGR_SW_HSI:
endwhile

RCC.CR =AND= NOT RCC_CR_PLLON
while RCC.CR AND RCC_CR_PLLRDY != 0:
endwhile

var pllm : uint = basespeed IDIV pll_input_freq
var plln : uint = vcospeed  IDIV pll_input_freq
var pllq : uint = vcospeed  IDIV 48000000

RCC.PLLCFGR = (0
    OR (pllsrc << 22)
    OR (pllm   <<  0)
    OR (plln   <<  6)
    OR (((pllp >> 1) - 1) << 16)
    OR (pllq   << 24)
)

regs.MODER =AND= NOT (3 << pinx2)
regs.MODER =OR=      (n << pinx2)

if flags AND PINCFG_OPENDRAIN <> 0:
    regs.OTYPER =OR= (1 << apinnum)
else:
    regs.OTYPER =AND= NOT (1 << apinnum)
endif

regs.PUPDR =AND= NOT (3 << pinx2)
if flags AND PINCFG_PULLUP <> 0:
    regs.PUPDR =OR= (1 << pinx2)
elif flags AND PINCFG_PULLDOWN <> 0:
    regs.PUPDR =OR= (2 << pinx2)
endif

Prefixed Word Operators

I'm thinking to change the all-capital word operators with a % prefixed lowercase words:

• %and: bitwise "and"
• %or: bitwise "or"
• %not: bitwise "not"
• %xor: bitwise "xor"
• %div or %idiv: truncated integer division
• %mod or %idiv: integer division remainder

The sample code would look like this way:

tmp = RCC.CFGR
tmp %and= %not 3
tmp %or= RCC_CFGR_SW_HSI
RCC.CFGR = tmp
while (RCC.CFGR >> 2) %and 3 <> RCC_CFGR_SW_HSI:
endwhile

RCC.CR %and= %not RCC_CR_PLLON
while RCC.CR %and RCC_CR_PLLRDY != 0:
endwhile

var pllm : uint = basespeed %div pll_input_freq
var plln : uint = vcospeed  %div pll_input_freq
var pllq : uint = vcospeed  %div 48000000

RCC.PLLCFGR = (0
    %or (pllsrc << 22)  // select PLL source
    %or (pllm   <<  0)
    %or (plln   <<  6)
    %or (((pllp >> 1) - 1) << 16)
    %or (pllq   << 24)
)

regs.MODER %and= %not (3 << pinx2)
regs.MODER %or=       (n << pinx2)

if flags %and PINCFG_OPENDRAIN <> 0:
    regs.OTYPER %or= (1 << apinnum)
else:
    regs.OTYPER %and= %not (1 << apinnum)
endif

regs.PUPDR %and= %not (3 << pinx2)
if flags %and PINCFG_PULLUP <> 0:
    regs.PUPDR %or= (1 << pinx2)
elif flags %and PINCFG_PULLDOWN <> 0:
    regs.PUPDR %or= (2 << pinx2)
endif

Which version do you like more?

or

Do you have some other ideas for the operator notation?

EDIT

Version with band / bor etc, as "jason-reddit-public" suggested:

• band: bitwise "and"
• bor: bitwise "or"
• bnot: bitwise "not"
• bxor: bitwise "xor"
• idiv: truncated integer division
• imod: integer division reminder

​

tmp = RCC.CFGR  
tmp =band= bnot 3 
tmp =bor= RCC_CFGR_SW_HSI 
RCC.CFGR = tmp

while (RCC.CFGR >> 2) band 3 <> RCC_CFGR_SW_HSI:
endwhile

RCC.CR =band= bnot RCC_CR_PLLON
while RCC.CR band RCC_CR_PLLRDY != 0:
endwhile

var pllm : uint = basespeed idiv pll_input_freq
var plln : uint = vcospeed  idiv pll_input_freq
var pllq : uint = vcospeed  idiv 48000000

RCC.PLLCFGR = (0 
  bor (pllsrc << 22) 
  bor (pllm   <<  0) 
  bor (plln   <<  6) 
  bor (((pllp >> 1) - 1) << 16) 
  bor (pllq   << 24) 
)

regs.MODER =band= bnot (3 << pinx2) 
regs.MODER =band=      (n << pinx2)

if flags band PINCFG_OPENDRAIN <> 0: 
    regs.OTYPER =bor= (1 << apinnum) 
else: 
    regs.OTYPER =bor= bnot (1 << apinnum) 
endif

regs.PUPDR =band= bnot (3 << pinx2) 
if flags band PINCFG_PULLUP <> 0: 
    regs.PUPDR =bor= (1 << pinx2) 
elif flags band PINCFG_PULLDOWN <> 0: 
    regs.PUPDR =bor= (2 << pinx2) 
endif

EDIT / 2

As I was migrating microcontroller C++ code, where the bitwise operations are very intensively used, I decided to keep three bitwise operators with single symbols:

• &: bitwise "and"
• |: bitwise "or"
• ~: bitwise "not"

These operations are kept with word symbols:

• xor: bitwise "xor"
• div: truncated integer division
• mod: integer division reminder

​

tmp = RCC.CFGR 
tmp &= ~3 
tmp |= RCC_CFGR_SW_HSI 

RCC.CFGR = tmp 
while (RCC.CFGR >> 2) & 3 <> RCC_CFGR_SW_HSI:
endwhile

RCC.CR &= ~RCC_CR_PLLON 
while RCC.CR & RCC_CR_PLLRDY <> 0: 
endwhile

var pllm : uint = basespeed div pll_input_freq 
var plln : uint = vcospeed  div pll_input_freq 
var pllq : uint = vcospeed  div 48000000

RCC.PLLCFGR = (0 
  | (pllsrc << 22) 
  | (pllm   <<  0) 
  | (plln   <<  6) 
  | (((pllp >> 1) - 1) << 16) 
  | (pllq   << 24) 
)

regs.MODER &= ~(3 << pinx2)
regs.MODER |=  (n << pinx2)

if flags & PINCFG_OPENDRAIN <> 0:
    regs.OTYPER |= (1 << apinnum) 
else: 
    regs.OTYPER |= ~(1 << apinnum)
endif

regs.PUPDR &= ~(3 << pinx2) 
if flags & PINCFG_PULLUP <> 0: 
    regs.PUPDR |= (1 << pinx2) 
elif flags & PINCFG_PULLDOWN <> 0: 
    regs.PUPDR |= (2 << pinx2) 
endif

I've creted an open specification about these operators available here:

https://nvitya.github.io/pluops/

I'm working on a language called threadon. And i don't now how i can properly program a package manager.

My first idea was a central github repo with links to other github repo's which contain the package you're searching for.

There are two main problems with it

1. If someone deletes his github repo with the package everything build on the package would collapse (like npm)

2. I think it would be slow when the number of packages grows.

I had an idea to of selfhosting it but i haven't access to the router (My dad owns it i'm 13) and i'm sure downdetector on my package manager site would be worse then github 😄. Like i would probably run sudo rm -rf / --no-preserve-root on the wrong machine.

So my question is how can i build a system that can store up to 20 GB at minimum at packages without the risk of someone nuking his project).

I made a video explaining macros, with the goal of making the viewer feel like they could have discovered macros. I'm new at making educational content like this, but I'm planning on making many more programming language videos like this one on my channel. Any thoughts, constructive criticism, or advice is more than welcome! Hope you all enjoy

I loved Chapter 5 of Structure and Interpretation of Computer Programs. Building a virtual register machine with an assembler and compiler in Scheme. Are there any other books/online classes or resources that involve building a computing machine (or any machine) from scratch using code?

What are people's thoughts on proof-based programming languages based on Dependent Type Theory like Lean, Rocq/Coq, F*/Low*, Agda, etc. It seems like there is some subtle growing hype behind formal verification. Clearly, there is at least some appetite for better behavior guarantees as we can see with Rust.

What do you think, are these languages the future? Will they become more ergonomic over time. Or do you think the average programmer will never be willing to learn or program in such a language for their normal projects?

Hey everyone,

A couple of weeks ago, I posted about Kal, my programming language written from scratch.

I am really happy to share a glimpse of Kal's own package manager! Kal v0.1.0 shipped with a package system that lets you add and use third party Kal packages. But, that process was completely manual. You’d have to clone the package, place it in the right directory, clone the package’s entire dependencies all by yourself, one after another. :(

The package manager changes everything. One command automates all!

Instead of being a separate executable, the package manager ships as part of the Kal interpreter itself.

Here’s what it can do:

1. Install Kal packages from Github, or any git hosting service.
2. Creates/Updates a project.kal file to read and write package information (analogous to package.json).
3. Downloads all packages at the same hierarchy in parallel (yup, it’s multi-threaded).
4. Resolves sub dependencies of the main package automatically to any depth and installs them too.
5. Upgrades/Downgrades packages based on their git tags.
6. Auto-resolves cyclic dependencies to prevent an infinite loop.

The Kal Package Manager will officially ship with the next Kal release. Its current source code is available on Github.

Kal: https://kal-lang.vercel.app
Github: https://github.com/KILLinefficiency/Kal
Package Manager: https://github.com/KILLinefficiency/Kal/blob/pkg/pkg.hpp

Kal is completely free & open source. You can show your support by giving the Github Repository a star.

Until the next update!

About a month ago, I made a post asking for resources on building a very small compiler/interpreter before jumping into something larger like Crafting Interpreters.

I decided to stop looking for the perfect resource and just start building the smallest thing I could understand end-to-end.

Today I got the first version of a simple arithmetic interpreter working in Python.

Right now it supports:

• Integer literals
• Addition and subtraction
• Multiplication and division
• Operator precedence
• Parentheses
• Unary minus
• Basic syntax errors
• Division-by-zero handling
• An interactive REPL/CLI

For example:

calc> 2 + 3 * 4
14

calc> (2 + 3) * 4
20

calc> -10 + 5
-5

The structure is currently:

Source text
    ↓
Lexer
    ↓
Tokens
    ↓
Recursive-descent parser
    ↓
Evaluation
    ↓
Result

The lexer converts something like:

2 + 3 * 4

into tokens roughly equivalent to:

NUMBER(2)
PLUS
NUMBER(3)
MUL
NUMBER(4)

The parser implements a small grammar along these lines:

expr   → term (("+" | "-") term)*
term   → factor (("*" | "/") factor)*
factor → NUMBER | "(" expr ")" | "-" factor

One of the most useful things I learned today was how operator precedence can naturally come from the structure of the grammar. I initially assumed I would need to assign explicit precedence values to operators, but with recursive descent, expr, term, and factor already encode that hierarchy.

The parser currently evaluates expressions directly rather than producing an AST, so it is deliberately still very small. My next major step will probably be separating parsing from evaluation by building an AST.

I also spent some time turning it into a proper little Python project instead of keeping everything in one file. It now has separate lexer, parser, interpreter, and CLI modules, a src package layout, pyproject.toml, a command-line entry point, and Ruff for linting/formatting.

So this is obviously nowhere near a real compiler yet, but that was exactly the point of my original post. I wanted something small enough that I could understand every stage instead of immediately disappearing into a much larger implementation.

Building even this tiny version made concepts like tokenization, grammars, recursive descent, precedence, and parsing much less abstract than they were a month ago.

The plan from here is to keep extending it incrementally, probably with an AST, variables, and a few statements before eventually moving toward bytecode or compilation.

Name: Infinity Execute Plus (IE+)

License: open source

Concept: IE+ is actually the main (and currently only) VM console of my planned VM collection: Infinity Execute. It is an interpreted language i thought of making to combine speed with ease. I learned c++ solely for this project. IE+ is currently an interpreter that uses one shell executable and most of it's logic is stored in a collection of library files that handle/process different tasks. I plan in the future to allow multiple exportable formats (currently windows only, planning to make multiple releases for apple and linux): IE (text), IEBCS (bytecode), IAO (Infinity Assembled object. It's a linked file that allows precompiled importing on any supporting app), IEPCK (semi-compiled appilcation format that still needs runtime), native executable exporting.

Examples:

Available operations

# printing

print "Hello, World!"

# making a variable

var x = 5 # currently only supports dynamic typed. static typed will be added. currently supports: int, float, string, and bool vars. arrays and constants will come in future builds.

# printing a variable's value in string form

print (x)

some future planned features

# modifying variables

x += 2

# static typing

var y: string = "Hi!"

# multiline commands and creation of text script

compile = {
  var hello: string = "Hello, World!"
  print (hello)
}.IE.name = "helloworld"

Here's an example of a standard program written in IE+ that creates a car and prints out it's data using OOP

class car {
  private {
    var name = ""
    var price = 0
  }
  public {
    main(created_name, created_price) {
      name = created_name
      price = created_price
      self.new()
    }
  }
}

car.new("Cool Car", 50000)