maintenance/talks/scheme-2016/outline.org

5.4 KiB
Raw Permalink Blame History

GNU Guix or the Search for a New Scheme Machine GNU Guix or Putting Your GNU/Linux Distro Within Reach of the REPL GNU Guix: The Functional GNU/Linux Distro Thats a Scheme Library

abstract

GNU Guix is a functional package manager: it views package build processes as pure functions, and the graph of build products as an immutable, persistent data structure. The Guix System Distribution (GuixSD) uses the concepts of Guix to build a complete bootable GNU/Linux distribution instantiated from a pure operating system declaration. But Guix and GuixSD are also Scheme libraries that expose all their data structures and code, letting users fiddle with their distro and operating system configuration and services to their hearts content.

In this talk I will give an overview of Guix and GuixSD and their Guile Scheme interfaces and implementation: from the embedded domain-specific languages (EDSLs) they devise, to the compilation pipeline from package declarations to low-level “derivations”, to the instantiation of GNU/Linux from high-level operating system declarations. Since Guix is designed by piling Scheme on top of Scheme, I will discuss staging and in particular “g-expressions”, and compare it to related work. I will conclude on open design questions and future work.

Guix project

free software roots, GNU project

~40 contributors per month

functional package management

free software: "pragmatic", incremental

concept, paradigm

  • package graph = persistent data structure
  • "pointer discipline"

concrete advantages

  • referential transparency
  • transactions
  • garbage collection
  • controlled environments

Scheme integration

declarative objects (records, sort-of EDSL)

  • define-record-type*

    • default values
    • let bindings
    • thunked fields

compilation tower

  • diagram with package/origin/derivation

two tiers: build and host

  • diagram with build daemon and client code

service management, mcron, etc.

  • diagram with PID 1, initrd, etc.
  • again two tiers

staging

initial attempt: %build-inputs, labels, etc.

gexps

  • how we came here
  • usage

    • with-imported-modules & source-module-closure
    • compilers & expanders
  • implementation

related work

  • syntax-case (Dybvig, 1992)

    • focuses on hygiene
    • syntax object can refer to pattern variables that are in its lexical scope
  • meta-scheme (Kiselyov, 2008)

    • 'bracket' (like quasiquote), and 'escape' (like unquote)
    • alpha-renaming, unique identifiers

      • but only handles bindings introduced by 'let' and 'lambda', not the whole shebang
    • handling of free identifiers and "cross-stage persistence" (CSP)
    • does not mention free identifiers, modules in scope
  • Hop (multi-tier semantics, 2010)

    • target language is JS, not Hop
    • special-purpose forms ('define-service')
    • client/server interaction ('with-hop')
    • '~' and '$' are built in the compiler
  • Nix language (ICFP, 2008)

    • string interpolation
    • bash, etc.

a pattern: monadic procedure vs. declarative object

  • gexp->file vs. plain-file, etc.

'gexp->file'

shepherd, system tests

services and monads (?)

initial attempt

  • flat list of monadic values

current design

  • list of values, extension relationship

fears

scalability

language as a database

CPU time to evaluate all the package jobs

efficient monads

staging

modules? (should gexps embed the set of imported modules? visible modules?)

  • with-imported-modules
  • compare with Hop top-level ~(import …) forms

    • in Hop's case, no difference between imported and used
    • Hop doesn't have first-class ~ expressions

hygiene? (gexp composition, see Oleg's meta-scheme)

  • currently no alpha conversion (renaming)

record serialization?

              (define search-paths
                ;; Search paths of MANIFEST's packages, converted back to their
                ;; record form.
                (map sexp->search-path-specification
                     (delete-duplicates
                      '#$(map search-path-specification->sexp
                              (append-map manifest-entry-search-paths
                                          (manifest-entries manifest))))))

debugging info?

  • Hop

    • maintains a mapping between generated JS code and the source (~)
    • is able to show client/server backtraces intermingled

relation between declarative (computed-file), monadic (gexp->file), and direct style

formalized relation between OS and service graph