YAML2 and simple functional programming ?

[asmodehn]

My interest in YAML has grown recently, as I start using it for multiple purposes (deploying, configuring, transferring data, etc.), and I will just leave here a simple idea that I hope can motivate some and give a practical goal for yaml2...

YAML is a widely used format and syntax, and simple enough for people to read, even if they are not used to the syntax. YAML is good at describing things, representing data, in an understandable way, and in a simple way, that can be transmitted over the network.

I find however that YAML is sometimes "overused", or used in places that have not been intended for it at first. A good example of that is ansible. Configuration data is clearly expressed, however in that usecase, YAML lacks the expressive power of a full fledged programming language. And because of it, ansible can be very confusing at first, even for seasoned programmers. There are probably other examples of this that I am not aware of.

Very simple yet powerful languages have been used to describe complex data and configuration details. An example for this is Guix, where local package configuration is detailed in a descriptive way, using a simple functional language.

While I find C'Dent very interesting, it is focused on OO design, and it seems to me that functional design is more appropriate for YAML current use cases (describing data). I also think there is already a lot of theory developed and implementations available for simply typed lambda calculus, to make this goal a realistic one for YAML2.

I think it would be awesome if YAML2 could be powerful enough to represent functional programs. Maybe also provide a standard interpreter working alongside the parser.

Note : maybe it is already doable with YAML1, but I couldn't find any implementation of this so far...

Migrating to YAML2 would suddenly enable projects using it to run complex functional algorithm, right from inside their YAML files. Because it is functional, there would be no risk of side effects, but users could dynamically run algorithm inside their data and enable more complex behaviors...

So this to me seems very suitable for YAML2, and can set a "minimum required featureset" for YAML2 design, while already enabling more than is possible with yaml1.