Hacker News Reader

Comment by neolog | Hacker News Reader

Why do I want Turing completeness and general functions in my config language?

As soon as you add some kind of macro system or any other content-rewriting, template-with-parameters or functional-abstraction mechanism, you may as well go full Turing. Otherwise people will try to simulate it using the available mechanisms, as they have for example with the C preprocessor, resulting in higher complexity than if you’d just given them Turing completeness in the first place.

So the only real choices seem to be either a pure data format or else full Turing completeness. There doesn’t seem to be a useful middle ground, unfortunately.

I think Dhall is an interesting point in this design space: powerful enough to write real functions, not Turing complete so all Dhall programs can be reduced to a normal form and compared for equivalence.

It seems to me the equivalence comparison will always have its limits. The Dhall documentation gives the example of `even(n + n)`, which Dhall is unable to recognize as equivalent to `true`. The feature is of course still useful, but I‘m doubtful the non-Turing completeness is absolutely essential to it, given its limitations.

In a total language, you can prove that `even(n+n) = true`. Dhall probably doesn’t bother with this because it’s focused on proving that your resulting data structures are equivalent: so, since functions are guaranteed to run in a bounded amount of time, it just runs all the functions it finds and then normalizes the resulting data structure. Equality between these data structures implies program equivalence.

sendmail.cf was a warning, not an example!

People like to write entire plugin systems in their config languages. This tends to be a bad idea in my experience, but there's a steady demand for it.

why not use python as the configuration language then ?

Or Scheme :)

One of the motivating cases is working around the Nix language's shortcomings:

> The Nix package manager: Nix is a declarative package manager using its own language for specifying packages. Nickel is inspired in part by the Nix language, while trying to overcome some of its limitations. It could be used instead of the Nix language.

Guix sidesteps this all by just using a proper language with macros for its configuration.

Or GNU Shepherd. With Lisp-based configuration, you get all the power of imperative programming with all the transparency of declarative programming.

- Python isn't sandboxed

- What version of Python? They seem to have abandoned semver and are breaking changes across releases.

Granted, a Lua-like language would work well for some of these situations. Lua does have the "what version" problem.

I was more talking about things like this:

    HOME_DIR = '/home/ubuntu'
    WORK_DIR = HOME_DIR + '/workspace'
    STARTUP_TIME = time.time()
    TIMEOUT = 10 * 60
    PLUGINS = {
        'remoteLogging' : { 
             'server' : '::1', 
             'port': 60000 
        }

It's a bad thing if you're doing big side effects at configuration time (creating directories and such)

Btw, there used to be a sandbox built in into stock python (Bastion), but they abandoned it (IRC because of security issues)

They didn't abandon semver - semver didnt exist (formally) when python started making breaking changes across releases :)

This is essentially what starlark does, although a slightly limited subset of python that's less prone to complicated things (no classes, so no multiple inheritance and no need to do what cue does).

https://github.com/tweag/nickel#use-cases

Those use cases don't require those features.

This comment requires explanation.

I had to use Terraform at work to configure some SDN controllers . I never felt the need for an external language.

You can list a directory, read all the json that dir (in a single list/map comprehension/building expression) and use that to feed your modules that manage the actual terraform resources.

When you realize that terraform modules are functions, terraform become a usable functional language.

Why would I want to generate some terraform when I can simply use it to generate the desired state using my higher level data ?

Edit: Please disregard, wrong person

> terraform modules are functions

You seem to have found this feature useful. Doesn't that answer your question about why you would want a configuration language to have functions?

I just gave a counterexample to that part of the link you posted:

  ... all requiring potentially complex generation of configuration.

I am just skeptical that past some level of complexity, terraform requires a generator.

Nickel does not generate Terraform. It is simply a language. The idea is that projects like Terraform could use it rather than create their own language out of a mess of JSON files.

In that sentence, I believe their meaning is that Terraform's language is already capable of generating configuration, and in fact this is a feature which is quite essential to Terraform's use. They acknowledge that all these projects (Nix, Terraform, Bazel, etc) already utilize relatively sophisticated programming languages for configuration. Nickel merely aims to be a better designed language for the purpose.

They’re not the one who asked the question…

Thanks, my mistake

in general when you don't have it you end up with a mess of nested if statements. Or end up calling some outside script to inject some form of a function. Plus even without turing completeness you can still end up with exponential complexity.

Sre workbook page 317.

Reply on news.ycombinator.com