Why not use YAML for configuration and package declaration?


#24

apparently in the context of nix
functions + referential transparency is use full

sandervanderburg/2012/11/an-alternative-explaination-of-nix

There are many causes why function invocations with the same parameters yield different results, such as functions returning time-stamps, generating random numbers, performing I/O, accessing global variables. These causes are called side-effects in the functional programming community.

Because C (and many other commonly used programming languages) allow these side-effects to be programmed, they lack referential transparency , meaning that functions cannot be replaced by its value without changing the behaviour of a program.


#25

interesting …
never heard of Dhall before

You can think of Dhall as: JSON + functions + types + imports

it sounds amazing …

after briefly scanning some of the perhaps more complex examples …
dhall-lang/wiki/How-to-translate-recursive-code-to-Dhall

The general algorithm for translating recursive code to non-recursive code is known as Boehm Berarducci encoding and based off of this paper: Automatic synthesis of typed Λ-programs on term algebras

…i feel sufficiently out of my depth
in fact by contrast
makes nix look simple
;]


#26

my pref would be … json

:upside_down_face:

and json makes me think of jq

which apparently has functions and …
‘Most jq builtins are referentially transparent, and yield constant and repeatable value streams when applied to constant inputs. This is not true of I/O builtins.’ - stedolan.github.io/jq/manual/

:crazy_face::thinking:


#27

jq wasn’t designed as language from beginning. It is simple when query is simple, but you quickly dive into quirks when your query is out of original jq scope. Nerveless, it’s a nice tool and I made a Nix equivalent some time ago, nixq (https://gist.github.com/danbst/be08fde47e5645f568ff73133f8c0053). To be fair, my approach isn’t performant at all (it chokes on large inputs).