I know not everyone will even have one, but I'm interested in people's ideas and I'm hoping it'll help me refine my own.

I'm thinking things like Nevalang's data flow, Lisp data-as-code, Ruby's "everything is an object," Go's first class coroutine/thread multiplexing, Zig's comptime, Rust's no GC lifetime management, Haskell's pure FP, blisp's effect system in lisp, Smalltalk's tooling integration, maybe ML's type system. Not just a feature that could be added or removed from the language, but the core vision or defining, killer feature.

Some languages are simply "a better version of <x>" or even just "my own preferred take on <x>" which isn't a bad goal at all. Plenty of the most used languages are mostly this, but I'm more interested in novelty.

I'm especially interested in ideas that you feel haven't been explored enough yet. Is there a different way that you would like to write or think about your code?

Beyond AI writing all of our code for us, is there a different way that we could be writing code in 20 or 30 years, that isn't just functional lisp/Haskell/ML, procedural C-like code, or OOP? Is there a completely novel way we could be thinking about and solving our problems.

For me, Python and Go work great for getting stuff done. Learning Haskell made my brain tilt, but then it opened my eyes to new ways of solving problems. I've always felt like there's more to this than just refining and iterating on prior work.

Hey everyone!

I've been fascinated with linear logic, session types, and the concurrent semantics they provide for programming. Over time, I refined some ideas on how a programming language making full use of these could look like, and I think it's time I share it!

Here's a repo with full documentation: https://github.com/faiface/par-lang

Brace yourself, because it doesn't seem unreasonable to consider this a different programming paradigm. It will probably take a little bit of playing with it to fully understand it, but I can promise that once it makes sense, it's quite beautiful, and operationally powerful.

To make it easy to play with, the language offers an interactive playground that supports interacting with everything the language offers. Clicking on buttons to concurrently construct inputs and observing outputs pop up is the jam.

Let me know what you think!

Example code

define tree_of_colors =
  .node
    (.node
      (.empty!)
      (.red!)
      (.empty!)!)
    (.green!)
    (.node
      (.node
        (.empty!)
        (.yellow!)
        (.empty!)!)
      (.blue!)
      (.empty!)!)!

define flatten = [tree] chan yield {
  let yield = tree begin {
    empty? => yield

    node[left][value][right]? => do {
      let yield = left loop
      yield.item(value)
    } in right loop
  }

  yield.empty!
}

define flattened = flatten(tree_of_colors)

Some extracts from the language guide:

Par (⅋) is an experimental concurrent programming language. It's an attempt to bring the expressive power of linear logic into practice.

• Code executes in sequential processes.
• Processes communicate with each other via channels.
• Every channel has two end-points, in two different processes.
• Two processes share at most one channel.
• The previous two properties guarantee, that deadlocks are not possible.
• No disconnected, unreachable processes. If we imagine a graph with processes as nodes, and channels as edges, it will always be a single connected tree.

Despite the language being dynamically typed at the moment, the above properties hold. With the exception of no unreachable processes, they also hold statically. A type system with linear types is on the horizon, but I want to fully figure out the semantics first.

All values in Par are channels. Processes are intangible, they only exist by executing, and operating on tangible objects: channels. How can it possibly all be channels?

• A list? That's a channel sending all its items in order, then signaling the end.
• A function? A channel that receives the function argument, then becomes the result.
• An infinite stream? Also a channel! This one will be waiting to receive a signal to either produce the next item, or to close.

Some features important for a real-world language are still missing:

• Primitive types, like strings and numbers. However, Par is expressive enough to enable custom representations of numbers, booleans, lists, streams, and so on. Just like λ-calculus, but with channels and expressive concurrency.
• Replicable values. But, once again, replication can be implemented manually, for now.
• Non-determinism. This can't be implemented manually, but I alredy have a mechanism thought out.

One non-essential feature that I really hope will make it into the language later is reactive values. It's those that update automatically based on their dependencies changing.

Theoretical background

Par is a direct implementation of linear logic. Every operation corresponds to a proof-rule in its sequent calculus formulation. A future type system will have direct correspondence with propositions in linear logic.

The language builds on a process language called CP from Phil Wadler's beautiful paper "Propositions as Sessions".

While Phil didn't intend CP to be a foundation of any practical programming language (instead putting his hopes on GV, a functional language in the same paper), I saw a big potential there.

My contribution is reworking the syntax to be expression-friendly, making it more visually paletable, and adding the whole expression syntax that makes it into a practical language.

https://reddit.com/link/1if64he/video/l14fztxw2jge1/player

How much progress have you made since last time? What new ideas have you stumbled upon, what old ideas have you abandoned? What new projects have you started? What are you working on?

Once again, feel free to share anything you've been working on, old or new, simple or complex, tiny or huge, whether you want to share and discuss it, or simply brag about it - or just about anything you feel like sharing!

The monthly thread is the place for you to engage /r/ProgrammingLanguages on things that you might not have wanted to put up a post for - progress, ideas, maybe even a slick new chair you built in your garage. Share your projects and thoughts on other redditors' ideas, and most importantly, have a great and productive month!

Some days ago I read some document ( https://www.cs.vu.nl/~ast/Publications/Papers/tse-1992.pdf ) regarding the Orca language to find out how parallelization worked in Orca. Orca had a fork instruction to spawn new processes. But more interesting is the question on how the processes where synchronized. For this shared data was used. For this all methods of objects instances that where passed to any fork would work like synchronized methods of java objects. However there is a little bit more objects may have guards. On page 16 the GenericJobQueue has two guards in the GetJob method:

1. guard Q.first /= NIL do
2. guard done and (Q.first = NIL) do

From my understanding they work similar to switch/case the first condition that is true will be executed. But there is no case for(Q.first=NIL) and not doneand there is no explicit default case. In the case where no cases matches the process calling waits until one of the cases matches so default case is some kind of wait and loop back to the beginning of the method. But there is another case where the method could go back to the start. When a block by calling another objects method were no guards match occurs the changes made in the current guard are rolled back and the method starts from the beginning again.

Now the later part made me thinking how useful the whole construct is. I never have seen something similar implementing in another language. Are there any languages that have similar constructs? The Generic Job Queue could be replaced by a queue and maybe a global variable or an sentinel object in other languages. On the other hand the guard construct would allow more specialized objects however the more complex an object would be the higher the chance it could accidentally trigger a rollback would be. I never found any sources of more complex algorithms or applications written in Orca to see how the the guard construct was used in general and if it was used for something more complex.

Hello World in every language has been done many times. What about lambda calculus?

I love lambda calculus and want to see how one would implement the “core” of lambda calculus in every programming language (just booleans and church numerals). I think it’s fascinating to see how different languages can do this.

Only two languages are up so far (JavaScript and Racket).

What’s your favorite programming language? Would you like to contribute yours? If so, check out the GitHub repository: https://github.com/kserrec/lambda-core

Miranda2 is a pure, lazy functional language and compiler, based on the Miranda language by David Turner, with additional features from Haskell and other functional languages. I wrote it part time over the past year as a vehicle for learning more about the efficient implementation of functional languages, and to have a fun language to write Advent of Code solutions in ;-)

Features

• Compiles to x86-64 assembly language
• Runs under MacOS or Linux
• Whole program compilation with inter-module inlining
• Compiler can compile itself (self-hosting)
• Hindley-Milner type inference and checking
• Library of useful functional data structures
• Small C runtime (linked in with executable) that implements a 2-stage compacting garbage collector
• 20x to 50x faster than the original Miranda compiler/combinator intepreter

github repository

Many more examples of Miranda2 can be found in my 10 years of Advent of Code solutions:

adventOfCode

Why did I write this? To learn more about how functional languages are implemented. To have a fun project to work on that can provide a nearly endless list of ToDos (see doc/TODO!). To have a fun language to write Advent Of Code solutions in. Maybe it can be useful for someone else interested in these things.

I've been working on my language for about a while, it's actually my first language (second if you count lox). It's an embeddable scripting language for c++20. It's very far from complete but its in a fairly usable state.

The language features a borrow checker (or something similar), mainly to make it clearer to express intent of lifetimes of C++ types. I was frustrated with mostly gc oriented languages where you either had to risk invalid references or adapt your code to be gc'd. Yoyo does provide a garbage collector (its currently unsafe tho) in the case you might not want to worry about lifetimes. It does require llvm for jit which is kind of a turn off for some people.

What does it look like?

The hello world program looks like this

main: fn = std::print("Hello world");
//alternatively
main: fn = {
    std::print("Hello World");
}
//random program
main: fn = {
    //structs in functions are allowed
    Person: struct = {
        name: str,
        year: u32
    }
    person1: Person = Person { .name = "John", .year = 1999 };
    person2 := Person{ .name = "Jack", .year = 1990 }; //type inference
    person_arr: [Person; 2] = [person1, person2];
    for (p in person_arr.iter()) {
        std::print("Person: ${p.name}, ${p.age}");
    }
}

This code would not compile however as there is no std yet. The syntax is heavily inspired by cppfront and rust. It currently supports basic integer and floating point (i8, i16, i32, i64 and the unsigned versions), tuple types ((T1, T2, T3)), sum types/variants ( (T1|T2|T3)) , user declared structs, and c-like enums. It also currents supports c ffi and the libraries to link must be selected by the c++ code.

Checkout the repo here: https://github.com/Git-i/yoyo-lang

Fat pointers are a common way to implement features like slices/spans (pointer + length) or interface pointers (pointer + vtable).

Unfortunately, even a garbage collector is not sufficient to ensure memory safety in the presence of assignment of such fat pointer constructs, as evidenced by the Go programming language. The problem is that multiple threads might race to reassign such a value, storing the individual word-sized components, leading to a corrupted fat pointer that was half-set by one thread and half-set by another.

As far as I know, the following concepts can be applied to mitigate the issue:

• Don't use fat pointers (used by Java, and many more). Instead, store the array length/object vtable at the beginning of their allocated memory.
• Control aliasing at compile time to make sure no two threads have write access to the same memory (used by Rust, Pony)
• Ignore the issue (that's what Go does), and rely on thread sanitizers in debug mode
• Use some 128 bit locking/atomic instruction on every assignment (probably no programming languages does this since its most likely terribly inefficient)

I wonder if there might be other ways to avoid memory corruption in the presence of races, without requiring compile time annotations or heavyweight locking. Maybe some modern 64bit processors now support 128 bit stores without locking/stalling all cores?

Many languages allow you to write a += b for a = a + b, a -= b for a = a - b etc. for a few binary operations. I wonder whether it would be a good idea to generalize this to arbitrary binary functions by introducing the syntactic sugar a f= b for the assignment a = f(a, b)? Would this cause any parsing issues in a C-like syntax? (I don't think so, as having two variable tokens left of an assignment equal sign should be a syntax error, but is there something I overlook?)

Hello, I was wondering if there are alternative programming paradigms to pointers when working with low-level languages that heavily interact with memory addresses. I know that C is presumably the dominant programming language for embedded systems and low-level stuff, where pointers, pointers to pointers, etc... are very common. However, C is also more than 50 years old now (despite newer standards), and I wanted to ask if in all these years new paradigms came up that tackle low-level computing from a different perspective?

fun getMax(list: List<Int>): Int {
  var max = 0
  for (i in list) {
    if (i > max) {
      max = i
    }
  }
  return max
}

-->

fun getMax(list: List<Int>): max = 0 {
  for (i in list) {
    if (i > max) {
      max = i
    }
  }
} // Implicitly returns max at closing brace

I kinda don't usually like implicit returns, but when the return keyword is replaced with a different marker of what the function is returning...

There are probably oodles of drawbacks to this concept—I doubt the only reason I don't see this in the big langs is that nobody thought of it—but it seemed like an interesting enough idea to put out there.

Hi all!

I wanted to announce this release for the Blombly language, bacause it has finally reached a semi-stable state.

Taking this opportunity, I will provide a short faq. Do feel free to give any kind of suggestions or criticism. Many thanks to members of this community that provided feedback in the past too. :-)

What's this language about?

It aims to have those common 80% features one needs for fast prototyping or most simple and mid-level applications and makes sure that they work seamlessly with very simple apis. In the future, I will probably cover advanced features for scientific computations too - which is my main domain.

Overall, I am striving to enable dynamic usage patterns. For example, functions do not have hidden state (e.g., definition closure) but do have access to all final variables in the scope in which they are running (runtime closure - but you can keep state in callable structs if you want to).

The language also parallelizes a lot of stuff automatically, without any additional instructions. In general, I want to let people write portable algorithms and ignore implementation details that would be hard to get right. For example, Blombly does not parallelize everything possible, but it guarantees an absense of deadlocks.

Did I see "structs" somewhere in there?

Objects in Blombly are called "structs" because they have no reflection or classes; they are just initialized by keeping all variables created inside new{...}. But you can inline code blocks to reuse coding patterns.

Is everything as rosy as it sounds?

The language has two major caveats to keep in mind. First, it is interpreted. It does a pretty good job in optimizing arithmetics and several string operations (e.g., expect near-machine-code speed on the latter) and will have a JIT in the future. But for now it is rather slow, especially when calling functions. You can still run a lot of stuff at speeds similar (and usually faster in case of arithmetics) to other interpeted languages.

Second, there's a "gotcha" that may be hard getting used to: code is evoked sequentially, but always assume that structs other than this can be altered by external code segments. In most cases, this does not change how you write or think about code; it only matters when you do things like A=A.dostuff(); print(A.getsomestate()); where A= is needed to make sure that the next usage of A. uses the returned (basically synchronized) outcome of dostuff.

Are batteries included?

Yes.

Currently there are options to create simple rest servers, SDL graphics, web resources (over http, https, ftp), and sqllite databases. There are also vectors for fast arithmetics (no matrices or higher-order tensors yet, but working on it) as well as some standard library implementations for plotting. Naturally, there's file system manipulation and the console too. If you think there's a nice-to-have IO (I know I'm missing sound and plan to have controllers as part of keyboard input) or some other common feature that you think is important I would be more than happy to include it.

Overall, the language is very opinionated -perhaps far more than myself but it helps keep development simple- in that a) there should only be one way to do stuff, b) there is no C ABI for third-party libraries; there will be JIT in the future probably, but any functionality will be included through the main code base.

You can import Blombly code written by others, and there's a nice build system in place for this that takes pains to remain safe; just not any C stuff that can escape the confines of the virtual machine's safety. I know that this makes me miss out on a ton of software written for other languages, but again my goal is to restrict features to ones that are nice to have yet simple to use.

For example on simplicity, need to retrieve some https data? Just open them as a file:

!access "https://"  // preprocessor command to give permisions to the virtual machine at the beggining of the main file (mandated for safety)

f = file("https://www.google.com");
print(f|str|len); // equivalent to print(len(str(f)))

What do you mean by semi-stable?

You can pick up the language and tinker with it for fun, but some details might break before version 2.0.0 which will be a full public release. I may be several months away from that.

How are errors handled?

A huge part of any language is its error handling. Admittedly, I am not 100% certain that Blombly's current take will be the final one, but errors are treated as values that can be caught per catch(@expression) {@code on error} or if you want some assignment on non-error values with `if(@var as @expression) {@code on not error}. Importantly, you can just skip error handling, in which case errors are propagated upwards to function return values, and all the way into the end of program execution if not caught anywhere in the middle.

Is the language dynamic?

Yes. As menionted above, there's not even reflection! This prevents programmers from trying to play whack-a-mole with if statements, which is a frequent trap in dynamic languages. Just rely on errors (catching errors is the only feature that explicitly checks for some kind of type) to pull you out of invalid states.

How is memory handled?

A huge decision from my part is to not fully implement a garbage collector. That is not to say that you need to collect memory; I have proper reference counting in place. But you do need to handle/remove circular references yourself. Overall, I am trying to create a predictable experience of where memory is released, especially since under the hood it is shared across threads that the programmer doesn't know about.

There are ways to make your life easier with defer statements, clearing objects, and options from the standard library. You will also get notified about memory leaks at the end of program execution.

*Edit: syntax and typos.

Hello all,

I've been working on an interpreted language implemented in Go. I'm relatively new to the area of programming languages so didn't give the idea of LSPs or syntax highlighters much forethought.

My lexer/parser/interpreter mostly well-divided, though not as cleanly as I'd like. For example, the lexer does some up-front work when parsing strings to make string interpolation easier for the parser, where the lexer really should just be outputting simple tokens, rather than whatever it is right now.

Anyway, I'm looking into implementing an LSP for my language, as well as a Pygment implementation for the sake of my 'Materials for MkDocs' docs website to get syntax-highlighted code blocks.

I'm concerned with re-implementing things repeatedly and would really like to be able to share a single implementation of my lexer/parser, etc, as necessary.

I'd love if you guys could sanity check my plan, or otherwise help me think through this:

1. Refactor lexer/parser to treat them more like "libraries", especially the lexer.
2. Then, my interpreter and LSP implementation can both invoke my lexer as a library to extract tokens.
3. Similar probably needs to be done for the parser, if I want the LSP to be able to give more useful assistance.
4. Make the Pygment implementation also invoke my lexer 'as a library'. I've not looked super deeply into Pygment but I imagine I can invoke my Golang lexer 'library' from Python, even if it's via shell or something like that -- there's a way to do it!

If this goes as planned, I'll have a single 'source of truth' for lexing/parsing my language.

Alternatively to all this, I've heard good things about Tree-sitter so I'll be researching that more. Interested in hearing people's thoughts/opinions on that and if it'd be worth migrating my implementation to using that. I'm imagining it'd still allow me to do this lexer/parser as 'libraries' idea so I can have a single source of truth for the interpreter/LSP/Pygment impls.

Open to any and all thoughts, thanks a ton in advance!

Nevalang is a programming language where you express computation in forms of message-passing graphs - no functions, no variables, just nodes that exchange data as immutable messages, and everything runs in parallel by default. It has strong static typing and compiles to machine code. In 2025 we aim for visual programming and Go-interop.

New version just shipped. It's a patch-release that fixes compilation (and cross-compilation) for Windows.

I'm fooling around with the idea of accelerating some of my code that my language that I created, generates. So I want my lang to be able to generate OpenCL code, and then run it. Sounds easy?

I tried using the example here: https://developer.apple.com/library/archive/documentation/Performance/Conceptual/OpenCL_MacProgGuide/ExampleHelloWorld/Example_HelloWorld.html#//apple_ref/doc/uid/TP40008312-CH112-SW2

And... it doesn't work.

gcl_create_dispatch_queue returns null. On BOTH calls.

// First, try to obtain a dispatch queue that can send work to the
// GPU in our system.                                             // 2
dispatch_queue_t queue =
           gcl_create_dispatch_queue(CL_DEVICE_TYPE_GPU, NULL);

// In the event that our system does NOT have an OpenCL-compatible GPU,
// we can use the OpenCL CPU compute device instead.
if (queue == NULL) {
    queue = gcl_create_dispatch_queue(CL_DEVICE_TYPE_CPU, NULL);
}

Both calls (GPU/CPU) fail. OK... so why?

I get this:

openclj[26295:8363893] GCL [Error]: Error creating global context (GCL not supported) openclj[26295:8363893] Set a breakpoint on GCLErrorBreak to debug. openclj[26295:8363893] [CL_INVALID_CONTEXT] : OpenCL Error : Invalid context passed to clGetContextInfo: Invalid context openclj[26295:8363893] GCL [Error]: Error getting devices in global context (caused by underlying OpenCL Error 'CL_INVALID_CONTEXT')

OK, so it sounds like it can't get a context. I guess this is when gcl_create_dispatch_queue returns NULL.

The question is... why?

Is there something better than OpenCL? Something I can "get working" on any platform easily?

Ideally, my lang "just works" on any unix platform, without the need to install too much stuff. Like a basic desktop home-computer that already can run games, should have all the stuff pre-installed needed for my lang.

Is this wrong to assume? I know about vulkan (not tried it), but is vulkan installed on typical home-desktop computers? Mac/Windows/Linux?

OpenCL seems "unsupported" in favour of "metal", which is OSX only, so I won't use Metal. But its still installed, I have a huge amount of OpenCL libs installed on my Mac (50MB), which I did not install. Its pre-installed.

So why would Apple give me 50MB of libs that do not work at all? There has to be a way to get it working?

I've been saying this so often so recently to so many people that I wanted to just write it down so I could link it every time.

You can't practice language design. You can and should practice everything else about langdev. You should! You can practice writing a simple lexer, and a parser. Take a weekend to write a simple Lisp. Take another weekend to write a simple Forth. Then get on to something involving Pratt parsing. You're doing well! Now just for practice maybe a stack-based virtual machine, before you get into compiling direct to assembly ... or maybe you'll go with compiling to the IR of the LLVM ...

This is all great. You can practice this a lot. You can become a world-class professional with a six-figure salary. I hope you do!

But you can't practice language design.

Because design of anything at all, not just a programming language, means fitting your product to a whole lot of constraints, often conflicting constraints. A whole lot of stuff where you're thinking "But if I make THIS easier for my users, then how will they do THAT?"

Whereas if you're just writing your language to educate yourself, then you have no constraints. Your one goal for writing your language is "make me smarter". It's a good goal. But it's not even one constraint on your language, when real languages have many and conflicting constraints.

You can't design a language just for practice because you can't design anything at all just for practice, without a purpose. You can maybe pick your preferences and say that you personally prefer curly braces over syntactic whitespace, but that's as far as it goes. Unless your language has a real and specific purpose then you aren't practicing language design — and if it does, then you're still not practicing language design. Now you're doing it for real.

---

ETA: the whole reason I put that last half-sentence there after the emdash is that I'm aware that a lot of people who do langdev are annoying pedants. I'm one myself. It goes with the territory.

Yes, I am aware that if there is a real use-case where we say e.g. "we want a small dynamic scripting language that wraps lightly around SQL and allows us to ergonomically do thing X" ... then we could also "practice" writing a programming language by saying "let's imagine that we want a small dynamic scripting language that wraps lightly around SQL and allows us to ergonomically do thing X". But then you'd also be doing it for real, because what's the difference?

Hi folks, I have no background in PL implementation but I have a question that occurred to me as I was teaching myself Zig.

In Zig there are (broadly and without nuance) two paradigms for "interfaces". First, the language provides static dispatch for tagged unions which can be seen as a "closed" or "sealed" interface. Second, you can implement virtual tables to support "open" or "extensible" interfaces eg, Zig's std.mem.Allocator. Zig doesn't offer any particular support for this second pattern other than not preventing one from implementing it.

As I understand it, vtables are necessary because the size and type of the implementation is open-ended. It seems to me that open-endedness terminates when the program is compiled (that is, after compilation it is no longer possible to provide additional implementations of an interface). Therefore a compiler could, in theory, identify all of the implementations of an interface in a program and then convert those implementations into a tagged union (ie convert apparent dynamic dispatch to static dispatch). So the question is: Does this work? Is there a language that does anything like this?

I assume that there are some edge cases (eg dynamic libraries, reflection), so assume we're talking about an environment that doesn't support these.

how would one read such a book? should i make a language alongside the book? how did you guys read it? (i have 0 knowledge in programming languages design)

Extensive and patiently-paced, with many examples, and therefore unfortunately pretty long lol

https://ryanbrewer.dev/posts/sequent-calculus/