first draft of the spec for mize lang.

TLDR

  • toml with functions
  • a bash like pipe operator to avoid heavily nested parentheses
  • a way to embedd other langs (like the multi line strings in nix)
  • code == data (like lisp)
  • I think a file like this should always be a MiZe Part which does set_config("path", value) for all paths it has in it’s json-like representation and can also do get_config("smth.smth"). making it act quite similarly to NixOS modules.

GOAL

the goal of this lang is not to implement any program logic but to:

  • declare configuration
  • declare how to wire together pieces of software (eg MiZe Parts, or packages + config to form a whole OS - NixOS style)
  • declare the architecture + datatypes of an application (with the goal that agents can take that and do the implementation mostly on their own)
  • combine functions, logic from other programs/libraries/places into new useful stuff.
  • maybe declare UI
  • make code act as data, lisp style.
    • functions producing other data which is then the same as code.
    • code can be processed grammatically very well.

some examples

# simple config
log.level = "trace"
someFeature.enable = true

# instead of writing heavily nested comples paths use a simple function
# complex paths, all functions evaluated (pure json-like data), good for programms to use
mos.hosts.my-host-name.disks.main = {
	type = "gpt"
	partitions = [
		{ type = "esp"; size = "100M" }
		{ type = "ext4"; size = "100%"; fillScript = ''echo my test file > $mnt/test.txt'' }
	]
}
# function which will produce complex paths structure: (and when serializing data from complex path structure we should produce function calls again... somehow)
# nice for humans to use
host "my-host-name" {
	esp {
		size = "100M"
	}
	rootfs "ext4" { // 100% of left over space by default
		fillScript = ''
			.....
		'';
	}
}
# you store the pure json-like-data version in a DB... and can edit it in the function like thingy.

# example for the bash-like pipe
# this is an actual nix expression from my dotfiles:
# with a pipe operator it becomes sooooooooooo much more readable imo
 without_pipe = lib.attrsets.genAttrs (map (value: lib.strings.removeSuffix ".nix" value) (builtins.filter (el: lib.strings.hasSuffix ".nix" el) (lib.attrsets.mapAttrsToList (name: value: name) (builtins.readDir ./mods/nurPkgs)))) (name: (pkgs.callPackage "${pwd}/mods/nurPkgs/${name}.nix" {}))
 
with_pipe = builtins.readDir ./mods/nurPkgs | lib.attrsets.mapAttrsToList (name: value: name)  | builtins.filter (el: lib.strings.hasSuffix ".nix" el) | map (value: lib.strings.removeSuffix ".nix" value) | lib.attrsets.genAttrs (name: (pkgs.callPackage "${pwd}/mods/nurPkgs/${name}.nix" {}))

# and i think the "calling this for every el in the list or dict" needs to be made possible with even less code (as that is used a lot)