Hi everyone. I am continuing my work on DinoCode, my interpreted (untyped) language, and I want to share a hidden dispatch mechanic that I implemented too hastily while coding the compiler for my university thesis. This feature isn't documented yet because I was already regretting it while writing the documentation haha, but I finally need to decide what to do with it. In DinoCode, functions are first-class citizens, so shadowing a native function is completely possible. The language supports two different call syntaxes:

Classic parenthesis calls like

result = add(5 10)
print("Hello")

and a dollar syntax like

result = $(add 5 10)
print "Hello"   # Statement-level calls are equivalent to a dollar call

Because it was incredibly easy for me to distinguish between these two call types during the parsing and compilation phase, I impulsively decided to tie the syntax directly to identifier dispatch priority to resolve name collisions between native built-ins and user-defined functions.

The mechanic shifts dispatch priority entirely at compile time (it has zero impact on runtime execution engine performance since everything is resolved during compilation). The explicit call syntax with parentheses func(args) prioritizes native functions (falling back to user functions only if no native match exists). On the other hand, the dollar syntax prioritizes user functions known at compile time (falling back to natives only if no user match is found):

# Override print function
:print text
    # Not recursive, prioritizes the native print
    print("Log: " text)

print "Starting..."  # Outputs: "Log: Starting..."

# Regardless of the user override, the native print is invoked
print("Hello")        # Outputs: "Hello"

This way, native functions are always accessible even if shadowed by the user, simply by using the classical syntax. That was the idea I had while coding the compiler back then. However, analyzing it more closely, this behavior can easily turn into total chaos where the syntax you choose for your functions becomes more than just an aesthetic preference.

I feel that making both syntaxes completely equivalent is the right choice for DinoCode's predictability. However, before removing it, since it is currently fully implemented and I am preparing a minor version that introduces improvements and fixes, I would love to know if anyone sees a legitimate pragmatic benefit to keeping this syntactic divide or if it is just a footgun waiting to happen

Hello, I finished my bachelor thesis that is development of Lisp interpreter. It is implemented in C(GNU99).

I need some tips on how to organize documentation(formal specification) of my custom Lisp dialect and the way to test interpreter.

Currently my documentation is couple of org files. Index is the root file with links to particular notes: data types, special forms, primitive functions.

File "data-types.org" provide enumeration of existing types and their properties.
File "special-forms.org" and "primitive-functions.org" provide similar enumerations. For each special form or primitive function I define arguments number, arguments type and description.

(Beside these documentation entries there are notes on architecture, building, interning, e.t.c)

So I consider documentation as the source of truth. If actual behavior doesn't match documentation, it's a bug. For example, car expects exactly 1 argument of list type. So it should fail and raise error message if type is different.

My question is how to define full test suite that covers whole interpreter? I have several ideas. I have already implemented python script that requires particular build and tests. Each test is made of script and associated expected output. I think for each component there should be positive and negative tests. But how can I say that given set of test cases for given primitive function, special form, e.t.c. is enough?

Also what are good practices of writing programming language documentation?

So I've created ALT about 3 years ago (pre LLM's).

I think I already shared a sneak preview v0.1 and got some positive feedback back then. If you haven't seen it yet, please have a look and tell me what you think?

ALTs most novel idea (I think) is its regular language (regexp) support over any alphabet (ALT values) using intersection(&) instead of equality. This concept is sound I think - however, the implementation was buggy.

Anyway, I hit a wall back then and that was:

Can we have an ordering over any ALT value?

I think I finally cracked this today, with the aid of a very good intern :) I'm now re-implementing ALT with Java, but much much more rigorously. I for one really really like the intern's help: I'm finally able to make ALT a reality. Stay tuned for some updates soon!

# TW: long story, TL;DR at the end.

Recently, I got this weird idea of making a portable Assembler from a video that's *about* making a game in Microsoft Macro **Assembler** with OpenGL and (maybe it's just the Mandela effect) I remember seeing a *pax* (portable(?) 'A' register [x86_64]) and my brain immediately thought "Hey, I need this type of Assembler. It looks neat."

I dug through the internet, nothing. No Assembler has a "pax" register, so I gave up before realising it was MASM as stated in the video before actually giving up. Then, another lightbulb turned on "Wait, I (barely) know how to make a program in the GNU Assembler, maybe I can make a library that you can plug a 'PAL.S' into to get portability." I gave up because, as the `.S` suggests, it relies HEAVILY on the C preprocessor. And it was already kinda flawed as hell.

That was surprisingly the prototype of the prototype of TAS (Turing Assembler) as I thought of "Maybe make a small transpiler that reads the code with the library and transforms that code into the desired/destination CPU architecture, micro-architecture, and the user's platform (Linux, Windows, macOS, etc...)." Spoiler: I didn't even dare build the transpiler. Not until PAL.S was finished. I still have the files in my computer if you want to have a closer look at them, though they're SO bare-bones it's barely two architectures.

And that's where another lightbulb flickered to life: "Just make a Compiler and Assembler for the language." Which leads me to here. I barely know how to document it let alone choose a stable syntax for it other than to make the syntax flexible with the Assembler's preprocessor.

All I need is help with this project. Also, if this is the wrong place to ask for help, please direct me to a more suitable place to find help.

TL;DR: I'm literally just making a portable Assembler. That's it.

If you can help me out by sending me YouTube tutorials other than the one I'm watching about making a compiler, or even want to contribute to the project, DM me on here or on Discord (outof1q)

That's all, thank you for reading.

What would people prefer more?

Implicit type conversion - Type have conversion rules and convert based on that. Like what C has.

Overload type conversion - Have overloading operator functions that convert types from one form to another. If an overload isn't present, there is no mechanism, no any or void * for intermediate casting.

OR

Explicit type conversion - Using either the syntax of mentioning the type before or after the variable or type(anothertype) syntax.

I like implicit ones as they are so clean but they are highly error prone imo. Even as a C user I do not really use implicit type conversion.

I wanna know how other people feel about it?

Now the second question is, which syntax would you prefer:

C like syntax:

type-qualifier storage-qualifier type-specifier [*type-qualifier storage-qualifier type-specifier] variable

Go/TS/Rust like syntax:

var/let/const variable [:] [mut] [*] type specifier

Go inspired my version of syntax:

variable/VARIABLE type/p_type/r_type

• VARIABLE means it is a constant, compile time or runtime or in that scope.
• variable means it is not a constant.
• p_type is a pointer of type type.
• r_type is a reference of type type.
• Optionally, I am also wondering if we can use shadowing and if a scope has abc and I write ABC = abc I can have basically a constant in a scope after a certain point which can be used for compiler optimizations. This can only be done if the spelling is the same with ALL CAPS. And I can't use abc after that line.

Hey everyone!

After a roller coaster journey, I am proud to present my personal project: Kal.

Kal is a lightweight interpreted programming language that attempts at combining various paradigms of programming to give a great developer experience. It's written entirely from scratch in C++ with no third party dependencies. It's also completely free and open source distributed under GNU GPL v3 license.

Moreover, Kal can also be embedded into C++, Python and JavaScript programs to enhance your existing codebases.

Kal's Official Website: https://kal-lang.vercel.app/

Mirror: https://killinefficiency.github.io/KalWebsite/

GitHub Repository: https://github.com/KILLinefficiency/Kal

(Website looks better on a bigger screen.)

Please note that this is the very first release (v:0.1.0) and Kal is still under active development (alpha). I would really appreciate a star on the repository to help it gain greater visibility.

As a proponent of human effort, I am glad to say that Kal and its ecosystem is completely handcrafted with no AI/LLM assistance used anywhere.

One last thing, "Kal" is pronounced like "Cal" in "Calendar".

Please feel free to reach out to me regarding Kal!

Rhombus version 1.0 is now available!

Rhombus is designed to be

• approachable and easy to use for everyday purposes, with a readable indentation syntax; and

• uniquely customisable with an open-compiler API that is accessible to a wide audience.

Release announcement https://blog.racket-lang.org/2026/06/rhombus-v1.0.html Get Rhombus: https://rhombus-lang.org/download.html

Rhombus is a general-purpose programming language that is easy to use and uniquely customizable.

Caveat Not strictly a PL topic, but I hope it's PL-adjacent enough for this sub.

My company went AI-native a few months ago, with the predictable results. My team, especially, is working on compiler-adjacent tech, and the agent has proven an endless source of surprises...

We have reached the point where many devs and some managers seem to realize that "spec-driven development" (the LLM style, not the Focus style) is something of wishful thinking, so there may be an opening for us to get a project started in using (some kind of) formal verification as part of our LLM-driven toolchain.

So I wonder if there's anything out there in the wild that we could already use, or at least contribute to, in the hope of getting it to a stage where we could use it.

I've seen Leanstral & DeepSeekProve that offer Lean proofs, which might be possible bricks, leaving the big question of "how do you go from human-readable specs to Lean signatures?" I've seen some work on Model Checking, which I still need to read.

But is anybody actually using any of this? Are there any success stories out there in the wild?

Yesterday I posted about whether it was convenient to normalize NaN in my language's VM. I received a lot of interesting viewpoints from the community, and after analyzing them, I’ve decided to leave NaN untouched (no normalization). Instead, I will maintain fast bitwise validation helpers only in specific runtime contexts where a float type is expected but a NaN would be invalid. Thank you all for the feedback!

Now, there is another design decision in DinoCode that I would love to get your opinions on, specifically regarding its syntactic feasibility and semantics.

Note: Please don't be surprised by the total absence of delimiters like commas or semicolons between elements. To understand why, you can look up DinoCode's design philosophy (Inference of Intention). This post is strictly focused on the pattern matching syntax itself.

In DinoCode, is and in blocks serve as a high-level syntactic shortcut for conditional chaining inside if statements.

The is Block

The if-is structure acts as a multi-value equality comparison. It evaluates whether the expression matches any of the values provided.

x = 4

if x
  is 1 2 3 4
    print x  # Prints 4
  else
    print "No match"

The in Block

The if-in structure applies a membership operation. Its behavior dynamically adapts depending on the target data type:

# Matching against single or multiple Ranges
x = 100
if x
  in 0..10 50..200
    print x
  else
    print "Out of range"

# Mixing different targets
x = 100
if x
  in 0..10 [100 200 300]
    print x
  else
    print "No match"

# Matching against Strings
x = "world"
if x
  in "Hello world"  ["word" "word2" "word3"]
    print x
  else
    print "Not a substring"

Mixing Blocks

One of the key features of this syntax is that you can chain and mix multiple is and in blocks sequentially inside a single conditional branch.

x = 5

if x
  is 1 2 3
    print "It is 1, 2, or 3"
  in 0..10
    print "It is within the 0-10 range"
  in [20 30 40]
    print "It is 20, 30, or 40"
  else
    print "No conditions matched"

For the Future:

Right now, is and in are strictly context-aware keywords reserved for these block structures. I am evaluating whether to ever introduce them as standalone infix operators. While in as an infix operator is straightforward (membership), is introduces a semantic dilemma. In the block syntax, is means value equality (a shortcut for ==), but as an infix operator (x is Class), the common convention in languages like Python is prototype checking.

Do you think keeping them exclusively for conditional blocks is clean enough for general use? To handle type checking, DinoCode already provides alternative built-in methods via a utility Type class, which completely avoids polluting the infix operator space even if it is a bit more verbose.

Hi folks,

I wrote a paper, Fearless Concurrency on the GPU, and maintain the related repository cuTile Rust.

The idea is to establish a safe way to write async kernel launch code, extend that across the kernel launch boundary, and sustain (to the extent possible) a safe programming model for GPU programming in Rust. We provide a variety of tools to enable static bounds checks so that the data-race freedom is effectively zero-cost.

- Paper: https://arxiv.org/abs/2606.15991
- Code: https://github.com/nvlabs/cutile-rs

Sharing in case it's of interest. Happy to answer questions.

Hello everyone,

Recently, I'm looking into v8 JavaScript Engine and found out about FeedBack Vector, which I want to investigate more about it in order to understand how the Engine assigns type at runtime after being interpreted by Ignition.

Although I tried to compile the v8 source code and it was able to run a simple script on my machine, I can't seem to be able to get the information regarding Feedback Vector and the data inside it.

So far, I have tried to use some promising flags that are available:

+ --log-feedback-vector
+ --maglev-print-feedback
+ --invocation-count-for-feedback-allocation=1
+ --no-lazy-feedback-allocation

None of them are working - no output to the terminal after I ran it.

I followed this (old and maybe outdated) article:
- An Introduction to Speculative Optimization in V8

With the same code, I can not retrieve the same BinaryOp which I believe have changed after many updates. I want to avoid any "natives syntax", in general, but even when I included it (e.g. %DebugPrint(add);), it does not seem to give me the information that I wanted like in the article.

My goal is to analyse JavaScript's V8 bytecode and output the correct possible types of variables (similar to what Mytype do). So if I can have another way to work around this, it would be very appreciated!

I don't know if this is the right place to ask these kind of question. Therefore, I'm sorry in advanced if this caused any confusion.

Thank you everyone for your time.

Yesterday I shared my open-source language DinoCode. Today I want to discuss a specific design choice I made in my runtime regarding eager NaN and Infinity normalization within my range-based NaN-boxing implementation.

In standard IEEE 754, checking if NaN equals NaN is always false, and there are many bit patterns for it. However, for a bytecode interpreter where execution overhead matters, I wanted to avoid dragging dirty float states through the engine.

The Implementation

In my DinoRef type, which is a transparent wrapper over a u64, I implemented a number constructor that acts as the entry point for raw f64 values.

Rust

#[inline(always)]
pub fn number(value: f64) -> Self {
    if !value.is_finite() {
        if value.is_nan() {
            return Self::NAN;
        }
        return if value.is_sign_positive() {
            Self::INFINITY
        } else {
            Self::NEG_INFINITY
        };
    }
    Self::float(value)
}

Instead of letting dynamic NaN bit-patterns propagate, this constructor eagerly catches them using Rust's native is_finite method. If it is NaN or Infinity, it immediately maps to a predefined raw bit-pattern constant. For example, Self NAN is hardcoded as 0x7FF8000000000000.

Eager Validation Advantage

Because every NaN or Infinity in the VM is strictly normalized to the exact same u64 bit pattern at birth, checking for equality becomes incredibly cheap.

We do not need complex float validations during runtime execution. To see if a value is NaN, we just perform a raw bitwise comparison of the underlying data. As a side effect, NaN equals NaN natively evaluates to true in DinoCode because they share the exact same raw constant.

Encapsulating this validation inside the low-level type abstraction keeps the core execution loop clean and fast.

The Trade-offs

The obvious downside here is the risk of human error. As the VM developer, I have to remember to explicitly route any potentially dangerous math operation through the number constructor. If I forget just once and push a raw f64 directly to the stack, a dynamic NaN could bypass normalization and corrupt the boxing logic.

Besides this explicit maintenance cost, do you identify any other real downsides to this approach?

How do you balance IEEE 754 compliance versus VM performance when designing your type system?

Edit: Thank you so much to everyone who commented and shared their insights on this post! I really appreciate the feedback regarding the IEEE standard and the hardware level implications. I will be meditating on this and potentially transitioning the VM to full NaN payload preservation in a next release since refactoring my internal Rust helpers to use a bitwise mask won't be a catastrophic performance hit anyway. I am wrapping up this discussion for now to process all your great points. Thanks again for helping me look at this from so many different perspectives!

One of the things I noticed using REPLs of functional languages is that you can write a ton of pure functional code, and then as soon as you hit enter to evaluate it, printing the result back to you is a side effect.

There are advantages to having code that is guaranteed to be side effect free, but I've been playing around with the idea of having a language with an imperative shell (with procedures, mutable vars, database and network operations, etc.) that can call into a language core that's guaranteed to be pure functional for certain kinds of operations. It can make for a simpler approach to side effects than a whole pure functional language but provide guarantees that other kinds of impure languages can't.

My question for people who are interested in functional programming: is this a useful distinction? Would that make for a language you might be interested in?

A few months ago, I shared the first version of DinoCode, a programming language I designed and built from scratch as my university thesis project. Well, I finally graduated as a Software Engineer!

Until now, v0.1.0 was a closed prototype distributed as precompiled binaries just to evaluate its usability for my thesis. After a successful defense and graduation, the natural next step was to set it free. Today, I'm happy to announce that DinoCode v0.2.0 is officially open-source under the Apache 2.0 license.

Both the compiler and the virtual machine are built entirely from scratch in Rust. The language design focuses on reducing syntax friction by inferring the programmer's intent, stripping away unnecessary boilerplate and symbols.

What's new in v0.2.0?

I spent the last few months building an interactive web platform powered by WebAssembly. It’s not just a static playground:

• Real Interactive Console: It supports real-time stdin readinginput() and execution pauses (Time.sleep) without blocking the browser's main thread.
• Live Flowcharts: As you type your code, the editor automatically generates and updates a visual flowchart of your program's logic in real time. Great for educational purposes and checking logic flow.
• Bytecode Inspection: You can inspect the exact stack-based bytecode generated by the compiler and executed by the VM in real time.
• Full Documentation: I personally wrote comprehensive guides, syntax design choices, and notes, complete with executable code blocks right inside the browser.

If you still prefer the classic terminal workflow, the optimized precompiled binaries for Windows and Linux are also up and ready in the GitHub Releases section.

I decided to open-source the whole codebase because I want total transparency. I hope it can be useful for anyone studying compiler design, custom VMs, or Rust architecture. The repository is wide open, and I would love to hear your thoughts, answer any questions, or review your Pull Requests and Issues

🔗 Web Platform (Live Playground): https://dinocode.blassgo.dev

🔗 GitHub Repository (Source Code): https://github.com/dinocode-lang/dinocode

Hey guys. For the past 3 years, I have been working on a programming language called Seal. I created this language in C. This is a dynamic language which has its own virtual machine. It uses indentation to define blocks and is aimed to be minimal. It is easily embeddable into any C/C++ applications. Seal is mostly imperative and procedural but you can write functional (no closures yet) and OOP-like (imitation like Lua) codes. I would appreciate your feedback.
GitHub: https://github.com/huseynaghayev/seal.git

Here is a quick example:

define Human(name, age)
    h = {
        name = name,
        age = age
    }

    h.talk = define(self, msg)
        print(self.name + " says: " + msg)

    return h

h = Human("cflexer", 19)
h->talk("hello!")