There’s a feature I find handy in Ansible, it’s the way it manages the executable files : if a configuration file has the exec bit, ansible would run the file and use the stdout result as if it’s the content of the configuration. It’s often use to generate dynamic inventories, and I, for myself, use it to store secrets in GPG encrypted files (long story short: this whole idea popped while I was trying to figure the best way to securely add secrets in a Dhall configuration).
So the proposal here is to make Dhall run local executable files at import. I understand that this proposal defeats the whole not-turing-complete thing, but I’d argue that it pushes the impure, turing-complete stuff at the boundaries, much like the JSON import solution in #121. Speaking of JSON import, let me show a code example that solves #121 using the executable import feature:
in myconfig.yaml (this requires that your /usr/bin/env support the -S option):
#! /usr/bin/env -S yaml-to-dhall '{a: Natural, b: Bool}' --file
a: 42
b: true
then in my dhall files:
let a = assert : ./myconfig.yaml === { a = 42, b = True }
Tadam! the user defined parsers are just executable files that output valid Dhall.
For security purpose, there could be limitations such as not interpreting *.dhall files or freezed imports.
Any thoughts ? Is it irrevocably deemed way too impure to even think about it ?