Skip to main content

Dreams

This page documents the dreams of the Lix team. These are features which we have generally not roadmapped yet, and which may not have complete and thoroughly thought-through plans, and which we would like to think about more completely before implementing. We are writing them down publicly so that others can dream with us.

  • language versioning https://pad.lix.systems/lix-lang-version-investigation [PRIVATE LINK]
  • split the evaluator into a separate process, interact with it only via rpc (horrors)
  • bytecode evaluator with all the possible trappings (horrors)
    • allows arbitrary runtime-define breakpoints, watchpoints, program inspection and manipulation
    • interacts with rpc to allow perfect lsp hosts, better debuggers etc
  • new gc for the evaluator to replace bdw, prototype/template for gc in eventual rust evaluator (horrors)
  • flakes as a library of code that provides new nix subcommands (horrors, others)
  • lix.conf prelude-path = for system-wide subcommands a la git (horrors)
  • eval caching with a memoize :: str -> any -> any builtin that is overridden by scopedImport with a unique, deterministic subscope (horrors)
    • import := f: memoize (toString f) (scopedImport builtins f) (horrors)
  • flake eval caching entire attrpaths: mapAttrsRecursive (n: const (memoize n)) on all scopes/attrsets in the "flake" (horrors)
  • lazyUpdate is a disaster waiting to happen, turns all values into even worse errors sources than simple thunks (and is deeply intrusive to the evaluator for little gain). why not special attrset ops __members, __getMember to simulate lazyUpdate in a library that doesn't infect all future versions of the language and can be transpiled when necessary? (horrors)
    • pureImport is too fine grained, store paths as boundaries actually make sense (and give memoize stable starting scopes), pure eval mode could be "ask thing to pack itself up, add to store, eval from there like nix flakes do" (horrors)
  • all authoritative information about the store attached to store objects, not an sqlite database (eg in xattrs or similar) (horrors)
    • would make overlayfs stores for containers/vms trivial
  • redo the lazy trees infra on the basis of "virtual" store paths and mountpoints (turning eg a zip file into a virtual mountpoint /nix/store/lazy/thing.zip/...) (horrors)
    • notably do not use fuse for this, just a pure vfs implementation
  • fully decouple evaluator and store (horrors)
    • tvix has kind of done this with EvalIO, lix needs it too (otherwise the eval-process split will not be possible)
  • store operations state, like "what derivations were realized in the last build" (Qyriad)
    • "what attrpath was this accessed by to build"
  • ✨ fancy ✨ repl, a la IPython and pry (Qyriad)
  • Support instance of Lix running locally off the main page to try out
    • Obviously WebAssembly schenanigans involved
  • replacing nixos-option (jade)
    • CLI commands should be possible to actually deprecate (jade)
  • profiler for nix code (jade)
  • nix develop replace store path but actually good, with bind mounts (jade)
  • nixos-rebuild gets unfucked perhaps with samueldr code (jade)
  • we kinda wanna have inherits consistent by container type such that you can write inherit (thing) [ a b c ] to create a list, inherit (thing) { a b c } to create a set, or nest those in existing lists or sets to extend them in-place like current inherit (horrors)
  • unbreak the io model (horrors)
    • currently nix has an async io model shoved into a sync runtime, and an async model that can't decide whether it's push or pull. this sucks
  • pipe operator (Qyriad)
    • and either haskell's $ or left pipe operator
  • hyperlinked sources in docs (jade)
  • a debug macro like rust's dbg! https://doc.rust-lang.org/std/macro.dbg.html
  • a dependency graph for builds which explains why different dependencies are being built
    • store path truncated to unique names in output...?
  • native nix-output-monitor (nom) style (slash bazel-style) output formatting (showing a live updating list of stuff being built/fetched, with warnings stacking up above it)
    • web viewer for the build graph as it is happening with a nice live log viewer (jade)
      • relatedly: show closure graphs nicely (jade)
  • make the store properly multi-tenant, with things like, e.g. authentication and maybe even certain http done via hooks on the client side (jade)
  • replace nix profile with something not broken with a clear ramp to either have a manifest mutably in the store or operate mutably against a configuration directory. ideally out of tree. (jade)
Back to top