4 ms·

What about https://dhall-lang.org/ https://dhall-lang.org/ ?

bpicolo 8y ago
Dhall does indeed look like it starts to address this problem - haven't seen it before. I'd have to read deeper to decide whether I like it or not, though. I may try to convert some existing complex YAML I'm using into it to form an opinion.
- Leace 8y ago
  Dhall is nice that it can natively support configuration migrations via total functions. For example Config1 can be migrated to Config2 by applying a function that always completes. It's also possible to constrain that function so it must accept Config1 and return Config2. Dhall supports functions from URLs and it's good to pin them using SHA hashes of their internal representation.
q3k 8y ago
Also https://jsonnet.org/ https://jsonnet.org/ . Both of them are basically BCL/GCL but with some semantic/scoping horrors removed.
- jopsen 8y ago
  I was involved with json-e a while ago: https://taskcluster.github.io/json-e/ https://taskcluster.github.io/json-e/ Which to me seemed more intuitive. But I'm also pretty excited about the UI-as-code features happening in Dart: https://medium.com/dartlang/making-dart-a-better-language-for-ui-f1ccaf9f546c https://medium.com/dartlang/making-dart-a-better-language-fo... Mostly I prefer YAML w. json-e because it's declarative and expressive enough for those few cases where you needed fancy stuff.. But the new Dart features coming up, makes me think I could write config as code -- we'll see :) (Disclaimer: I work at Google)
crdoconnor 8y ago
Everything dhall advertises itself as useful for is basically as a replacement for situations where YAML has been abused or where the separation of concerns between code and config was improperly cut (this is largely how YAML files get to be mind numbingly repetitive). It does this by creating something not quite as powerful as a real programming language (sometimes a feature; probably not here though) while still complicated enough to effectively be unreadable to an average Joe.
kevin_thibedeau 8y ago
You can make Tcl as non-Turing complete as you wish. Stripped of most or all builtin commands, it becomes a flexible configuration language. You can add back power in small controlled doses as it becomes necessary. You can also make it more palatable to the cool kids by adding infix assignment and expression evaluation with a few simple helper procs.
- yellowapple 8y ago
  This was a big part of what motivated me to create OTPCL [1]; using full-blown Erlang or Elixir for configuration files feels dangerous and heavy-handed, and I want to be able to readily define DSLs for configuration files instead to offer better control/safety/ergonomics. Plus, I happen to like Tcl ;) Imagine being able to go from a foo.app like this: {application,otpcl, [{description,"Open Telecom Platform Command Language"}, {vsn,"0.1.0"}, {modules,[otpcl,otpcl_env,otpcl_eval,otpcl_init,otpcl_parse, otpcl_shell,otpcl_stdlib,otpcl_stdmeta]}, {registered,[]}, {applications,[kernel,stdlib]}, {licenses,["ISC"]}, {links,[{"Bitbucket","https://bitbucket.org/YellowApple/otpcl"}, {"GitHub","https://github.com/YellowApple/otpcl"}]}]}. to something more like a foo.app.otpcl: application otpcl { description "Open Telecom Platform Command Language" vsn 0.1.0 modules otpcl otpcl_env otpcl_eval otpcl_init otpcl_parse \ otpcl_shell otpcl_stdlib otpcl_stdmeta registered applications kernel stdlib licenses ISC links { Bitbucket "https://bitbucket.org/YellowApple/otpcl" GitHub "https://github.com/YellowApple/otpcl" } } I dunno about you, but I like the latter a lot better :) It ain't a 1:1 representation, but it'd be straightforward to define each of those parameters as commands that emit the corresponding Erlang forms that make up an actual app spec. While OTPCL's by no means ready for primetime yet, I'm hoping it'll eventually be good enough to fill that niche in the Erlang/OTP ecosystem the same way Tcl was meant to fill that niche for software in general. [1]: https://otpcl.github.io https://otpcl.github.io / https://github.com/otpcl/otpcl https://github.com/otpcl/otpcl
- eridius 8y ago
  There's a reason MacPorts[1] uses Tcl for its package definitions. The packages for the most part look just like structured data, but it's just a Tcl DSL that allows them to e.g. write hooks in Tcl instead of having to embed a shell script[2]. [1]: https://www.macports.org https://www.macports.org [2]: https://guide.macports.org/#development.examples https://guide.macports.org/#development.examples

Dhall does indeed look like it starts to address this problem - haven't seen it before. I'd have to read deeper to decide whether I like it or not, though. I may try to convert some existing complex YAML I'm using into it to form an opinion.

Leace 8y ago
Dhall is nice that it can natively support configuration migrations via total functions. For example Config1 can be migrated to Config2 by applying a function that always completes. It's also possible to constrain that function so it must accept Config1 and return Config2. Dhall supports functions from URLs and it's good to pin them using SHA hashes of their internal representation.

q3k 8y ago

Also https://jsonnet.org/ https://jsonnet.org/ . Both of them are basically BCL/GCL but with some semantic/scoping horrors removed.

jopsen 8y ago
I was involved with json-e a while ago: https://taskcluster.github.io/json-e/ https://taskcluster.github.io/json-e/ Which to me seemed more intuitive. But I'm also pretty excited about the UI-as-code features happening in Dart: https://medium.com/dartlang/making-dart-a-better-language-for-ui-f1ccaf9f546c https://medium.com/dartlang/making-dart-a-better-language-fo... Mostly I prefer YAML w. json-e because it's declarative and expressive enough for those few cases where you needed fancy stuff.. But the new Dart features coming up, makes me think I could write config as code -- we'll see :) (Disclaimer: I work at Google)

crdoconnor 8y ago

Everything dhall advertises itself as useful for is basically as a replacement for situations where YAML has been abused or where the separation of concerns between code and config was improperly cut (this is largely how YAML files get to be mind numbingly repetitive). It does this by creating something not quite as powerful as a real programming language (sometimes a feature; probably not here though) while still complicated enough to effectively be unreadable to an average Joe.

kevin_thibedeau 8y ago

You can make Tcl as non-Turing complete as you wish. Stripped of most or all builtin commands, it becomes a flexible configuration language. You can add back power in small controlled doses as it becomes necessary. You can also make it more palatable to the cool kids by adding infix assignment and expression evaluation with a few simple helper procs.

yellowapple 8y ago
This was a big part of what motivated me to create OTPCL [1]; using full-blown Erlang or Elixir for configuration files feels dangerous and heavy-handed, and I want to be able to readily define DSLs for configuration files instead to offer better control/safety/ergonomics. Plus, I happen to like Tcl ;) Imagine being able to go from a foo.app like this: {application,otpcl, [{description,"Open Telecom Platform Command Language"}, {vsn,"0.1.0"}, {modules,[otpcl,otpcl_env,otpcl_eval,otpcl_init,otpcl_parse, otpcl_shell,otpcl_stdlib,otpcl_stdmeta]}, {registered,[]}, {applications,[kernel,stdlib]}, {licenses,["ISC"]}, {links,[{"Bitbucket","https://bitbucket.org/YellowApple/otpcl"}, {"GitHub","https://github.com/YellowApple/otpcl"}]}]}. to something more like a foo.app.otpcl: application otpcl { description "Open Telecom Platform Command Language" vsn 0.1.0 modules otpcl otpcl_env otpcl_eval otpcl_init otpcl_parse \ otpcl_shell otpcl_stdlib otpcl_stdmeta registered applications kernel stdlib licenses ISC links { Bitbucket "https://bitbucket.org/YellowApple/otpcl" GitHub "https://github.com/YellowApple/otpcl" } } I dunno about you, but I like the latter a lot better :) It ain't a 1:1 representation, but it'd be straightforward to define each of those parameters as commands that emit the corresponding Erlang forms that make up an actual app spec. While OTPCL's by no means ready for primetime yet, I'm hoping it'll eventually be good enough to fill that niche in the Erlang/OTP ecosystem the same way Tcl was meant to fill that niche for software in general. [1]: https://otpcl.github.io https://otpcl.github.io / https://github.com/otpcl/otpcl https://github.com/otpcl/otpcl
eridius 8y ago
There's a reason MacPorts[1] uses Tcl for its package definitions. The packages for the most part look just like structured data, but it's just a Tcl DSL that allows them to e.g. write hooks in Tcl instead of having to embed a shell script[2]. [1]: https://www.macports.org https://www.macports.org [2]: https://guide.macports.org/#development.examples https://guide.macports.org/#development.examples