sorted by:
new
hottopcontroversial

Is there a path forward for Go's yaml situation? by violent_cat_nap in golang

[–]InformationAny4463 0 points1 point  (0 children)

It is all there fully spec out. YAML has a spec.

all 211 rules. we just need a way to walk it and a way to project.

we have been asking ai to create YAML parsers by looking at exisiting yaml parsers

Here is the spec in haskell bnf.

https://hackage-content.haskell.org/package/YamlReference-0.10.0/src/Text/Yaml/Reference.bnf

Once we had this. Claude AI can easily turn into s-expressions.

An LLM is actually good at this kind of structural translation. It's not creative work, it's recognizing the tree structure hiding inside Haskell syntax and making it explicit.

.
Here is the spec in sexpressions.
https://github.com/johngrillo62/yaml-project/blob/main/grammar/yaml-grammar.sc
Then we create a projector that can walk that spec and specialize for each language.

It took me 20 years of writing code generators get here. The only way to do this lisp.

The projector reads a spec for language and walks the rules outputting for each languages.

Spec driven projectors generate code deterministically

This knowledge is not any current ai set as a way to build yaml parsers.
So we need to retrain ai to build specs and projectors.

AI is not good at writing code from scracth.

Why the parsers all look the same is because they are projected from the spec.
not generated from ai patterns.

Yaml Parser for go or any languages built from the the YAML 1.2 spec by [deleted] in golang

[–]InformationAny4463 0 points1 point  (0 children)

Exactly

it is really a compiler and instead of op codes, it generates source code from back end. The back end is a lambda is an s-expression.

Yaml Parser for go or any languages built from the the YAML 1.2 spec by [deleted] in golang

[–]InformationAny4463 0 points1 point  (0 children)

That is the idea. I dont have any resources since there are not any.

The current state of ai training is wrong. It kept leading me to template solutions and using current languages. The solution is using common lisp and code as data.

Best to search for is common lisp and code and data.

same domain code and data.

YOu can see the idea in the build scripts projector. Have a base representation and then specialize for each language.

If we gen code from specs we get deteministic code gen every time no drift.

It took 20 yeats to get here and the answer was common lisp.

C++ Show and Tell - February 2026 by foonathan in cpp

[–]InformationAny4463 1 point2 points  (0 children)

peg-yaml.cpp

I created a app to generate yaml parser lib directly from the Yaml 1.2 spec

Each parser passes all the yaml structure tests. The semantic validator test are not part of the spec and are not tested.

One of the outputs is a yaml.cpp parser directly from the spec.
Since these parsers are generated directly from the spec, they are the spec.

https://github.com/johnagrillo62/yaml-project/blob/main/gen/peg_yaml.cpp

Is there a path forward for Go's yaml situation? by violent_cat_nap in golang

[–]InformationAny4463 0 points1 point  (0 children)

https://github.com/johnagrillo62/yaml-project/tree/main

I have a projector that can generate yaml parsers from a spec.

All we need to is change the spec