[oalessandr]

I'm trying to use it for Kubernetes since it can both work like helm (paramerizing functions) and kustomize (using the merge // operator). Moreover it has (safe) imports which make defining constants quite easy.

There are already kubernetes bindings available https://github.com/dhall-lang/dhall-kubernetes .

The syntax in the examples looks a bit more verbose and less readable than yaml but I think building sensible abstractions on top of it will alleviate the pain (abstractions here are innocuous since you can 'normalize' the code and they disappear)

I'm not too happy with the default formatting though. I think if the formatter indented nested values similar to yaml that would look better to the human eye.

[amluto]

> Moreover it has (safe) imports which make defining constants quite easy.

I read about dhall’s imports, and I don’t think I like it. If I add a text configuration mechanism to software, I do not want it accessing the network by default, full stop. To me, a “safe” configuration language means that parsing terminates, does not have side effects, does not touch the network, and that parsing the same file twice gives the same output unless I explicitly change an input. Pulling a prelude off of github does misses several of these requirements.

(Having your config file fail to parse if your network is down is bad, bad news if that config is needed to bring your network up. It’s also bad news if a parsing failure due to a transient network issue leaves your system in a state where it won’t quickly recover if the network comes back.)

[jose_zap]

You can still do that, though. In Dhall you may import things remotely as you develop and then tell Dhall to pre-fetch the result, you can commit that and it will not access anything.

You may also just download any imports yourself and source them locally.

Additionally Dhall supports import fallbacks, for example you may try first a remote import, and if it fails it will look for another place, which I’ve could be remote or local. This is a good strategy for developing locally and then committing imports for production use.

You can also, of course, host the files in your local network.

[oalessandr]

I get your point, but you don't need to run imports over the network (local imports are fine).

Also, if you were to import over the network, by running `dhall freeze` a semantic hash of the content is computed so you are 100% sure that what you are importing is not going to change. Moreover, files that have a hash value will be cached by dhall.

If you don't want to bother with copying over Prelude and you don't trust the cache, you can also normalize the code before pushing it to the network. This will flatten all your imports and reduce your file to normal form.

You might be interested in what they say about imports here: https://github.com/dhall-lang/dhall-lang/blob/master/standar...

[singpolyma3]

Yeah, the formatting the `dhall` CLI tool uses isn't my favourite. Though luckily I don't usually have to look at it much :)