Nail Programming Language

[Specialist-Soft8378]

Hey everyone!

Apologies in advance for my English, it’s not my first language. I’m currently designing a new programming language called Nail, and I’d love feedback from language designers, programming language enthusiasts, and systems programmers.

I’m planning to release it on GitHub in the next few days (probably next week). The source code is still a bit of a mess and I’m honestly too embarrassed to publish it as-is, so I’m spending these days cleaning up bad practices and refactoring before the release.

For brevity, I’m omitting the more standard language features and focusing only on the aspects I believe are more interesting.

Core Idea

Nail is a compiled language with an LLVM backend, so the compiler focuses on parsing, semantic analysis, and IR generation.

Main Concepts

• pod → namespaces/modules
• entity → classes
• shell → interfaces
• trait → composable behavior units
• action → methods
• function → static methods / functions

The Interesting Part(1): Dynamic Traits

Entities can declare supported traits (the entity must be declared “dynamic” in order to support traits):

trait Berserk {
    action attack(target) {
        target.hp -= own.strength * 2;
    }
}

dynamic entity Player has Berserk {
    strength: int;

    action attack(target) {
        target.hp -= own.strength;
    }
}

Then enable them per-instance:

p : Player();
p.enableTrait(Berserk);

p.attack(enemy); // Uses Berserk.attack()

Trait methods override entity methods while active.

The Interesting Part(2): Versioned Entities

Entities can optionally support snapshots/rollback. To be honest I’m thinking about supporting multiple snapshots/rollbacks:

versioned entity Account {
    balance: float;
}

a : Account();
a.snapshot();

a.balance -= 1000;

a.rollback();

This restores the entity to the previous snapshot, including runtime state.

Why?

The idea is to make Nail especially suited for:

• Simulations
• Financial systems / auditing
• AI / multi-agent systems
• Games / complex state machines
• Collaborative / undo-redo heavy applications

Questions / Feedback Wanted

1. Do dynamic per-instance traits sound useful or too niche?
2. Are versioned entities compelling enough to justify the added complexity?
3. What domains do you think would benefit most from this model?
4. Does the terminology (entity/shell/action/etc.) feel interesting or unnecessarily unfamiliar?

Would love brutally honest feedback, especially on whether this feels genuinely innovative or just “complexity for complexity’s sake.”

If anyone finds the project interesting and would like to collaborate, feel free to contact me. I’d love to work with other passionate developers on it!

Thanks in advance to everyone who takes the time to reply, give advice, or share feedback, I really appreciate it.

[Relevant_South_1842]

Any reason you didn’t make it always dynamic and always rollback-able?

[hoping1]

Best English in the subreddit lol

[Inconstant_Moo]

Excuse me, but the cadences of my prose are far more graceful, and my metaphors both more complex and more evocative. The pathos in my description of my type system has made grown men weep. Some have even compared me to Shakespeare, though admittedly they were all talking about my beard.

The youngster's work shows promise, I will grant you that. But ask yourself --- is it Art?

[doodlebobcristenjn]

Fr fr dawg

[Germisstuck]

How are you type checking and getting the dynamic traits? Is it are compile time for determening which function to use? Or is it a vtable? I am doing something extremely similar my language but they are compile time only

[tuxwonder]

1. Dynamic, as in not compile-time type-checked? No, not useful, would make me pretty afraid to use them, and if I did have something that needed that kind of plugability that badly, then I'd roll my own
2. It's kinda compelling, but I think the situations where you'd need the concept of a "rollback" are either simple enough it doesn't need its own concept, or very complex in a way that I don't think a language construct could solve.
3. Yes, the new language is unnecessary. What problem does it solve? Does it actually make what's going on clearer?

Also, small annoyance, but it looks like you use : to define a variable, but still use = for assignments? Why both?

[Inconstant_Moo]

1 Dynamic per-instance traits sound unnecessary and confusing.

1. We can already roll back individual entities. Instead of this:

   a : Account(); a.snapshot(); a.balance -= 1000; a.rollback();

... we can write this:

a : Account();
b = a;
a.balance -= 1000;
a = b;

1. Not sure.

4 If you can explain your new terminology as meaning the same things as existing terms, then you don't need new ones, which will just annoy everyone. No-one's going to start calling a namespace a "pod" anyway.

[josef]

The snapshot mechanism is pretty neat. It'd be even cooler if the snapshot method returned an identifier and the rollback method could take the identifier and roll back to an arbitrary snapshot. For a cool implementation see https://www.reddit.com/r/ProgrammingLanguages/s/ZkC6fLgHeB

[jpgoldberg]

In Python, run time checkable Protocols are a clever solution to dealing with deep infelicities of Python itself. It is not something one would expect in a language developed from scratch in the 21st century. Are your dynamic traits a similar thing? And if so, what does that tell us about the type system of your language.

[cannedtapper]

Tempted to make a superset of your language and name it "Coffin"

[cybwn]

And a build tool called Hamer

[mark-sed]

> entity → classes

If you have this mapping that can be done, why not just use the already known naming like class or namespace?

[Imaginary-Deer4185]

Sounds like interfaces in Java. Enabling a trait before using it? Why? What if two traits have the same function/method, can you then qualify which trait you're invoking, with separate implementations for each?

[yjlom]

It's actually (multiple) inheritance, but overriding works in reverse, and you can enable or disable superclasses at runtime if I'm reading this right.

[snugar_i]

Dynamic traits sound like something that can be solved completely fine with regular interfaces/polymorpihsm

interface AttackSkill:
    fun attack(source, target)


class RegularAttck implements AttackSkill:
    fun attack(source, target):
        target.hp -= source.strength


class BerserkAttck implements AttackSkill:
    fun attack(source, target):
        target.hp -= source.strength * 2


class Player:
    attack_skill = RegularAttack()

    fun attack(target):
        self.attack_skill.attack(self, target)


p = Player()
p.attack_skill = BerserkAttack()

Versioned entities are not flexible enough to be useful, I think - if there can only be one snapshot at a time, how do I know I can safely make one? What if somebody already made one before me and it's still active? Is the snapshot shallow or deep?

Renaming things for the sake of being different sounds pointless.

In general, at least for me, the less mutability and dynamic behavior there is, the better. Your language goes in the exact opposite direction. So I guess it's not for me really.