I made the anna programming language for a Language Jam I hosted in the beginning of August. 1 week is not enough time to explore too many ideas but 2 interesting(ish) ideas I explored were

1. all function invocation is infix with . (dot) operator. This lets you chain/pipeline nicely.
2. the only looping semantic available is the iterate operator which produces a stream.

I made a playground if anyone wants to poke at it. https://jzwood.github.io/langjam2/submissions/anna/playground/

I feel like curly braces aren't enough alone for organizing code. I also want it to have natural steps that induce some blank lines after completion of the step. like with assembly. my main concern is readability and self documentation. It will mainly be for programming on windows. The 'thunk' libraries are mostly wrappers for tedious apis like writeconsole. I plan to add more for things like graphics and math in addition to the planned window/console/file. I see 'thunks' in ghidra so its a reference to them being wrappers. It will also support normal win32 imports.

thankz

edit 1: I have read all feedback so far. the language is case insensitive. for branch{}endbranch and alias.name{}end alias.name the idea was to make it a little more clear which curly brace belongs to what if someone had a bunch of nested stuff. with that being said, it seems the consensus is that the syntax is awkaward while readable, there are still some large wrinkles.

because of your feedback, i will 1. Allow the pattern "name{}end name"," name end name", and/or" {}". 2. Make the language case insensitive 3. Make whitespace completely optional 4. Sinilar to the first thing, allow parameters for functions to be entered either on seperate lines or within parenthesis and seperated by commas (but not both within the same function) 5. allow %/n% within a string, or a %hexConstant% for other characters instead of 'newline' on a seperate line.

i am still accepting feedback, and i appreciate those who have responded.

This is the official documentary about the history and design of Java, featuring James Gosling and many of the engineers who were involved in creating and evolving the language.

Rather than focusing on Java as it’s used today, it covers the engineering decisions, constraints, and trade-offs that shaped the language over the last 30 years.

Many years ago while trying to make my own programming language I faced an issue. In short, parsers didn't parse specific inputs as expected, due to some implicit rules.

For instance, let's consider EBNF grammar for a sequence of expressions a=aaaa, where a on the right can repeat arbitrary number of times. This will look something like this:

symbol = "a" params = symbol params | symbol Line = symbol "=" params lines = Line lines | Line

I designed it without + and * notation on purpose, to narrow down the root cause to the most basic rules: terminals, and and or expressions, and recursion.

Using this grammar I expect the text a=aaa=a to be parsed as (a=aa)(a=a): as two separate Line. But typically parser generators will not produce parser that can handle such case. Instead, the parser will (typically) fail.

The root cause is of course the nature of such parsers: they don't scan for all possible combinations. Instead, in case of collisions (like in this case a at the end of a=aa and a at the beginning of next a=a) it is expected that user will insert negation or something to "fail" a specific route fast, eliminating the collision.

But doesn't this challenge the whole purpose of grammars as "simple" description of language rules? It might get very difficult to predict all possible such collisions for a large grammar, like for Python or C++. Are there any generators that don't have such limitation and can pass (a=aa)(a=a) test?

Hey guys, since I've been lurking around this subreddit for some time, I have decided to throw my little compiled language into the open for criticism. I won't update the language itself, as there's no point in doing that to such a small toy language (that's not even that widely useful), but I would appreciate your thoughts and criticism going forward. I grew to admire LLVM IR and compiler engineering, and this definitely isn't my last compiler I'll make! (Yes I know LLVM has a whole API for building IR... I'll utilize it in bigger projects XD)
https://github.com/norbcodes/Arrokoth-0

Hi all!

I'm making a DSL, and I am not sure which comment syntax to choose due to couple of constraints:

1. The DSL deals with URLs (unquoted), so preferably the comment syntax must use a character sequence that cannot occur in a URL.

2. I really want to keep lexer lookahead under 1 character.

This disqualifies familiar // and /* */ as urls containing those are common. # is a URL fragment and -- is valid path and is also quite common in crm-generated urls.

The thing i'm leaning towards right now is an xml/html-style <!-- -->. It is not valid in URLs and is still familiar, with the drawbacks being that it's a bit verbose and needs to have an end.

I really want to hear some suggestions on this, no matter serious or silly!

I want some inspiration. I want to see a simple language spec/reference that is tiny and covers most of its features. eg: https://plasmalang.org/docs/plasma_ref.html

Thanks for all the specs, but I was hoping for recent languages (especially, amateur ones that get posted to this sub). What would I do with a spec from 1980s that was typeset with LaTex :) That's too much effort for hobbyist languages.

I made a post introducing Admiran about 18 months ago, and have been making steady progress on migrating it towards the language I want to use each day. Since that time I've made a lot of performance and coding-style enhancements, such as:

• escape analysis in the compiler's analyze pass to help determine if a lazy thunk is only evaluated at most once, allowing it to be emitted without extra code to update it to its value (saves ~15% code space and execution time!)

• optimization to coalesce consecutive continuation closures on the stack during lowering to the Spineless Tagless G-machine (STG) implementation, deferring the popping of the entire closure until a tail-call or return

• added a uniform set of left-to-right operators for creating computation pipelines

• tweaking the inlining pass parameters to get the best performance / code-size tradeoffs

The latest big change was to fully migrate from an ad-hoc prefix naming convention to using qualified names, and deferring name conflict resolution to the name-resolution pass, allowing modules with conflicting imports to still be imported, as long as the conflicting unqualified names aren't used, or are used only in a qualified form.

During these changes, I've migrated new features into the (self-hosting) compiler's code base itself, through a continuous bootstrapping process.

If you have an interest in lazy functional languages and how they are implemented, you might be interested in looking at it. I'm open to any questions or comments about the language and it's compiler implementation.

git repository: https://github.com/taolson/Admiran

Lovingly hand-crafted with no AI.

I'm building my own interpreted language.

I had an idea, to base my I/O API on the linux terminal commands, that many developers already know, so a user wouldn't need to learn an entire new API.

This is a basic example:

using io  

// create a directory  
mkdir("notes")  
cd("notes")  

// create files with content  
echo("Do my math.", "A note about homework.txt")  
echo("Buy milk and bread.", "shopping list.txt")  

const currentCD = pwd()  
const allFilesAndSubDirs = ls()  

debug(cat("shopping list.txt")) // prints "Buy milk and bread."

but I'm not that sure that this is a good idea, maybe some techniques are good for terminals but bad for programming, and some of the function names might be confusing (like pwd() which is "print working directory" but in my language it does not exactly PRINT anything, but just returns a string value).

What do you think?

schedule here https://icfp26.sigplan.org/program/program-icfp-2026/?past=Show%20upcoming%20events%20only

Hi yall,

This is a continuation to my last post, on formalizing Principia Mathematica, as well as a slight status update. I am planning(*) to slowly substitute the shallow embedding on PM into a deep embedding. For any backgrounds, please check the old post.

If you want to transform the monster 100 years ago into a furry boy, you might want to read through the following Q&As. *tap tap*

- Why you suddenly want to make a deep embedding? Because I can't in the beginning.
- What makes you available to deep embedding? I have asked enough questions on internet to get rid of necessary technical details
- What's the major feature for deep embedding? It enables formalizing Axiom of Reducibility.
- How many ppl would you like to look for? At most 2 ppl. You are welcome to ask me for prerequisites and anything else related
- What do you expect them working on? Either the shallow embedding or the deep embedding, since they are both necessary.
- How many time do you expect to put in? My current plan is 3 hrs a week so make sure you also have the availability.

------------------

Alternatively, I'm still welcome to collaboration with 1 - 2 ppl onto another project - we pick another random mathy, esoteric, maybe sacred book and formalize it

(*): Yes, I have not written a single line of code so far and this remains to be a plan.

I hope that question makes sense. I just don't like inequalities nor the unnaturality of working with left and right residuals (talking about "max and min divisors") that rarely coincide with rational arithmetic's exact division nor with the natural interpretation of inverses in numerical mathematics, thus I would like more explicit boundaries (thus the result of a division maybe being a set or interval including max and min divisors) in division.

(Mind that I have no experience in numerical computation, I am trying to make sense of computable, numerical and interval analysis works and transport their results to residuated lattices but that's somewhat hard for me)

Had some free time last week so I made a visual explainer on how LLVM works and why so many languages end up using it.

The video goes through LLVM IR, why having a common IR makes sharing optimizers and backends possible, and how code eventually gets turned into machine instructions.

I also use a small C vs Rust example where both end up producing the same x86 instructions.

Link for anyone interested

Feedback welcome :)

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.