Hacker News Reader

> the premise is that because of these few existing dsls (like PlantUML mentioned) my "new dsl" will be equally effective. PlantUML has millions of examples in the training data, my new dsls are not (*specially if its not json/yaml* or just function chain based)

I can confirm that having a DSL that is json/yaml helps a ton. Kind of like static type checking, it eliminates entire swaths of syntactical errors, allowing the LLM to focus on the semantics.

> because if then you are going to ask the llm to "compile the dsl to implementation" we are back to square 1.

I think this is an edge case; 99% of the time you (and/or the LLM) would have access to the implementor so it wouldn't need to do this.

> it eliminates entire swaths of syntactical errors, allowing the LLM to focus on the semantics

As I understood it, the idea the article presents is basically the opposite: The LLM is completely clueless about the semantics, but by constraining the language so that semantic errors are syntax errors, we can catch the LLM's bullshit with a simple validation step and make it try again until it produces valid syntax, which limits how wrong it can get the semantics.

It does apply to JSON in a way: An LLM doesn't always produce valid JSON, but it's easy to do a syntax check with a JSON parser and make the LLM try again until the JSON is valid. The JSON might still be semantically wrong on the level of the application domain (have the wrong values), but at least you can be sure that the generated data consists of lists, dictionaries, strings and numbers.

I thought they got like a logit mask that removes illegal next tokens, at least in llama.cpp and GBNF.

You're probably right about that. It looks like llama.cpp lets you specify a grammar file or a JSON schema - is that what you mean? If the syntax of your DSL can be expressed that way, I suppose you wouldn't have to validate it externally and retry.

the grammar support/json-schema applies to a whole response, but I was under the impression a similar logit guide rail can be applied when a tool call is opened.

> DSL that is json/yaml helps a ton

it definitely does, and i would say json/yaml is not a dsl. this example of json/yaml keeps coming in the form of "DSL". i would say your configuration is not a dsl, it a declaration. llms are better at declarative stuff ? maybe but there are hardly that many of complex declarative frameworks.

PlantUML is a real dsl. not just declarative yaml.

I would say any JSON or YAML that carries semantics with the syntax is a language. It may be a configuration language rather than a programming language, but it’s a language rather than just generic data for some program to slurp.

> any JSON or YAML that carries semantics with the syntax is a language

semantics are defined by the converter/compiler/interpreter, and that is the process which is going to consume the said json/yaml. if the json/yaml is going to be consumed by any process then the semantics are inherently defined, so by your definition all jsons/yamls are in their own a "language" (or they are not being consumed at all), which just defeats the purpose of calling it a language at that point.

At that point you can say C has no semantics, because the compiler defines them.

yeah and so llm cannot write C reliably

> and i would say json/yaml is not a dsl

But you can have DSLs that are json/yaml, is my point.

> PlantUML is a real dsl.

PlantUML is a DSL that isn't json/yaml. That doesn't make it better, and you can make the argument that it is worse because the tooling around it won't be as good.

> you can have DSLs that are json/yaml, is my point

i disagree on the semantics of "DSL" vs "config in json". these are different.

and anyways both of them just pretend to be "reliable" by throwing the responsibility to an upper layer of validator/compiler/interpreter

> it is worse because the tooling around it won't be as good

plantuml is good because of the the tooling around it. not sure if we are agreeing/disagreeing there, confused by the wording

That's not a domain-specific language. You can use JSON and YAML in other domains. A DSL is defined by its syntax.

the best language by a mile for dsl-as-data-structure is kdl2

it reads like code and you can easily define a schema too

well that's what i am using

https://kdl.dev/

and https://crates.io/crates/knus/ to define the schema

actually more than that. it would be awesome to have a programming language whose code is also valid as kdl 2. like lisp code being composed of s-expressions

Have you looked into YAMLScript?

I’ve had good luck with LLMs and ad hoc DSLs, as well as much less common DSLs like liquidsoap’s stream management DSL.

I don’t think there’s magic in DSLs, I just think LLMs respond well to clear, simple structure.

Compilation / execution is often true, but not necessary. DSLs can be entirely declarative and used just for gating the stages of a multi-step workflow with checkpoints that have more structure than natural language.

> less common DSLs like liquidsoap’s stream management DSL

seems to be on github since 2008 so definitely in the training data. i am not talking about less or more common. either "your dsl" would need to look something like someone elses dsl (at this point is it your dsl?) or you need some way to get your dsls examples in the training data for the llm, or feed it in the prompt.

> LLMs respond well to clear, simple structure

and what a "clear simple structure" for a dsl is also quite not mentioned. clear and simple would be quite subjective based on the domain, the article says let the llm go in a loop trying to figure out the dsl for you.

> checkpoints that have more structure than natural language

if llm is at any point in the structured generation part then either you have a deterministic validator/compiler or you are back to reading/reviewing it manually, what can you trust ?

> or you need some way to get your dsls examples in the training data for the llm, or feed it in the prompt.

I'm really not sure this is true. Recently for work I've been making changes in a system written in tcl in the early 2000s, including a custom dsl that has never escaped this company. The LLMs can write it fine. It wrote it almost acceptably on first sight, an hour or two of targeted test cases to extract a one page functional spec of the subset we needed and that was it. They are quite good at finding and fitting to patterns, go figure.

> The LLMs can write it fine. It wrote it almost acceptably on first sight

you are probably talking of some coding harness which looked up the existing code base and then made it and not something like first prompt to llm "write xyz testcase in my systems company dsl in tcl from early 2000".

> LLMs can write it fine

sure, coding by examples is fine (it goes back to "system prompt describing the language"). but the claim we are arguing is reliability. did the llm generate 100% test case or code after reading your existing codebase, likely not as you mention it "almost acceptably on first sight".

i would probably be in denial if was suggesting llms not good at finding and fitting patterns.

Well yes of course I was using a harness lol. We're talking about the application of tools to engineering problems. Getting an LLM to cold start on a completely novel to it language without prompting is a different problem that I don't have.

The whole point is that a dsl syntax is constrained enough to fit in the context window and not rely on training data. LLMs are damn near built for this exact use case.

For open source llms you can give your grammar to the llm to help it decide what valid next tokens it can generate.

Re: less common, I was just saying it doesn’t take millions off examples like PlanetUML.

> what can you trust

I wasn’t clear enough here — you’re responding to DSLs as an interface from non-deterministic LLMs to deterministic external systems.

What I meant was using DSLs as intermediate checkpoints in multi-LLM processing. If you just flow natural language through 5 LLM calls, the last one may be getting something very different from what it’s prompt is designed for.

But if you make the DSL a contract for handoff, results are much more stable.

Perfect and deterministic? No, of course not. Just an improvement and mitigation. But it’s served me well.

its served me okay.

> Perfect and deterministic? No, of course not. Just an improvement and mitigation.

exactly, not reliable, as the article tries to portray

Interesting … do you see reliable == infallible? I don’t. But certainly all software is imperfect, and LLMs doubly so.

for me reliable = deterministically repeatable. if a llm has been able to do a task successfully and i ask it to do the same task again, i want the reliability that i get the same outcome (be if failure or success)

like if someone says "is this car reliable", i dont expect an infallible car. but if the cars third gear is 'you know sometimes it doesnt work', i wouldnt take that car out of city.

This seems too strong to me. I agree with reliable as "repeatable", it's the determinism which seems excess to purpose.

If I have a great meal every time I go to a restaurant, that chef is reliably good. I do not require that the tomatoes on the salad be of identical number or placement, or cut along the precise same bias. Nor would I count the sesame seeds on the bun.

Are LLMs reliable by that standard? Sometimes yes, for some tasks. The envelope of tasks for which they're reliable is continuing to grow.

The situation is much better than you think. I actually have a little DSL project along these lines: it's meant to be a declarative component in a larger application which enforces certain data guarantees.

It is not based on JSON or any other out-of-the-box format. The only source material for this DSL anywhere in the world is on my laptop: a little documentation, a few examples, a partial implementation.

This is enough. Codex can not only give me arbitrary examples in this novel DSL on demand, it can see what I'm trying to do with the compiler and extend it for me.

I just have them write the tools to write the DSL's to do the thing then (most of) the sloppy code stays in the generator and if all the different things depend on each other they don't go stale and whatnot. And let them design the DSL themselves for whatever task so it matches their 'internal concept' of how the things work.

Worked out pretty well so far but not really practical unless your goal is to make the tools to make the DSLs to make jitting VMs -- https://github.com/dan-eicher/BBQ kind of snowballed from "let's parse some binary files" to a way over the top toolkit for playing around with this stuff but, it's fun...

DSLs are a great middle ground for 'use LLM to turn ambiguous spec into something well defined', with the caveat that without discipline they'll inevitably expand until you should just have the agent write whatever the final language is.

There's a context tax up front (which will hopefully be less relevant over time) and then you really need a compiler/linter with helpful errors to keep it on the rails, because there is no corrective context in pretraining for something novel.

A purely descriptive DSL is just a convention, which is useful, but doesn't inject reliability the same way an enforced syntactic contract does.

> you are basically looking at a whole system prompt just describing the new language

whats wrong with this? You may be over-indexing on the need for large quantities of examples. These days self-play through RL is far more effective and data (not compute) efficient.

nothing wrong if your dsl stays small and you have deterministic validators/compilers to your actual target.

if dsl gets large, the number of potential interactions your dsl allow will grow exponentially (unless you are building an one dimensional action layer). and there will be semantic issues unless your dsl is "clear and intuitive", also comprehensive enough to accomodate your ongoing changes, else every change is now 2 changes.

so you now you need a comprehensive manual for your agent which needs to be sent in every /completion request.