Settings

Theme

Show HN: Sigil – A new programming language for AI agents

5 points by inerte a month ago · 5 comments · 3 min read


I've been working on a new programming language for AI agents. I would love your input on what makes programming languages good for AI agents, especially syntax, compiler, and tooling that could help AI agents write code.

What makes Sigil good for coding agents?

I've turned conventions into compiler rules whenever possible. The compiler owns the canonical printer and every AST has one accepted textual representation. For almost every syntax feature I tried to save tokens.

Order and naming conventions are enforced. No more "I think this argument is important so it should come first." Most things are alphabetical. Declarations are categorized and ordered alphabetically; parameters, effects, and record fields are alphabetical too. Types are UpperCamelCase. Everything else is lowerCamelCase, including file names.

No nulls. No undefined. Bidirectional type checking. No shadowing. Fat stdlib (still in progress). `sigil debug` supports replay, stepping, watches, and breakpoints. `sigil inspect` lets coding agents query the compiler directly, including proof surfaces.

Solver-backed refinements and contracts. Different languages already choose different numeric surfaces: byte, short, smallint, unsigned integers, etc. Sigil pushes that one step further: domain constraints can also define types. `where` lets a named type carry a predicate, and `requires` / `ensures` let functions carry proof obligations across call boundaries.

Here is a contrived example from the roguelite:

  t InventoryCount=Int where value≥0

  λspendArrow(arrows:InventoryCount)=>InventoryCount
  requires arrows>0
  ensures result≥0
  =arrows-1
Under the hood this is backed by Z3: https://github.com/z3prover/z3 But the surface stays ordinary Sigil syntax. There are no proof scripts and no user-facing SMT language.

No imports, rooted references only. In some languages you can import code and have name clashes, so there are many ways to specify imports. Sigil eliminates all of that by only using rooted references. I think this reduces agent churn because when the model sees a line, it does not have to go hunt for an import statement.

Service dependencies are declared in `src/topology.lib.sigil`, and environment bindings live in `config/<env>.lib.sigil`.

The language has special syntax for tests and they are run in parallel. Every project `src/*.lib.sigil` function must be tested, and if a function can return multiple cases, tests should exercise all of them. "World" is Sigil's model for effects. That is how mocks work: swap one effect for another and make assertions without exercising real external systems.

The compiler toolchain is written in Rust, and Sigil outputs to TypeScript, with a Foreign Function Interface to Node.js. See some small projects here https://inerte.github.io/sigil/projects/ - the Flashcards is useful to learn about Sigil features https://inerte.github.io/sigil/projects/sigil-flashcards/dem...

Caveat: I did NOT type a single line of code for the compiler toolchain. It was all generated with Claude Code and Codex. I run both with permissions dangerously skipped. This actual post I hand crafted every word.

There is also a toy roguelite written in Sigil. It is a work in progress, but it is proof that Sigil can support nontrivial project code. You can play with `pnpm sigil:run:roguelike`.

Repository: https://github.com/inerte/sigil

Website: https://inerte.github.io/sigil/

And I would love if you can find ways to lock down LLM / user programs even more. In Sigil, there should be only one way to do anything.

boltyx0 a month ago

Interesting approach to constraining what agents can express syntactically. I've been thinking about a related but different problem: it's not just about how agents write code, it's about what they do at runtime. I've been building agents that call external APIs (ticket systems, chat tools, cloud infra) and the bigger risk I keep hitting isn't bad code, it's bad data flowing through correct code. An agent can write perfectly valid, type-safe code that reads a customer record and posts it somewhere, and the code is fine but the payload has an SSN in it. Curious whether Sigil's contract system could extend to runtime data constraints on API call payloads, not just function inputs. Like requires payload contains no PII as a contract on an external call. That would be genuinely novel.

  • inerteOP a month ago

    I haven't solved runtime data yet. Every time I try, my tendency to demand everything during compile time ends up with me adding an additional compiler rule, and kicking off the can down the road.

    When I added type constraints, it fit really well with validating values. If you specify:

      t BirthYear=Int where value>1800
    
    Then it's pretty obvious if you get 1500 you can throw an error, and I considered doing it, but didn't want to tackle runtime validation at the time.

    Maybe dealing specifically with "never send PII to the outside world", there are possible 3 things Sigil could have.

    Since Effects are explicit (and Http and Filesystem are effects in Sigil), maybe validate before the effect is performed by calling a function to see if a particular type (Ssn) is not empty or straight up validate the value of every field.

    Or with topologies, which is Sigil's way to specify external dependencies (I am not considering the filesystem one here). Same idea as effects, somewhere during the data flow some kinda of validation happens.

    Maybe a third way would be to be able on a Type, specify where the data can go to. Something like:

      t Ssn=String where isValidSsn(value) transit logApi
    
    `transit` in this case can tell where this type can live. Then, we can validate during compilation time if `Ssn` is only going to `logApi`, and not to the `mailApi` or any other external dependency.

    Thanks for the suggestion, I will explore this idea.

  • inerteOP 25 days ago

    So, an update, I took at stab and came up with this: https://inerte.github.io/sigil/articles/labelled-types-and-b...

EddieLomax a month ago

Curious if you have seen this:

https://moglang.org/

  • inerteOP a month ago

    Yes, very different from Sigil other than targeting coding agents. Mog seems to enhance coding agents by offering a (very fast) way for them to write quick scripts or apply hooks. Also, the security features are great, explicit capabilities.

    Sigil is a general purpose programming language, with tooling to help the AI agents write and fix programs.

    In theory it seems both of them could be used together, suppose you're writing a new big app using Sigil, you could then plug in Mog to speed up that even more.

Keyboard Shortcuts

j
Next item
k
Previous item
o / Enter
Open selected item
?
Show this help
Esc
Close modal / clear selection