+ (car (string-tokenize (utsname:sysname (uname)) char-set:letter)))))
+
+;; We don't use (srfi srfi-39) (parameter objects) here because that
+;; does not give us a name/handle to the underlying fluids themselves.
+
+(define %parser (make-fluid))
+(define %location (make-fluid))
+;; No public setters: should not get overwritten in action
+(define-public (*parser*) (fluid-ref %parser))
+(define-public (*location*) (fluid-ref %location))
+;; but properly scoped location should be fine
+(defmacro-public with-location (loc . body)
+ `(with-fluids ((,%location ,loc)) ,@body))
+
+;; It would be nice to convert occurences of parser/location to
+;; (*parser*)/(*location*) using the syncase module but it is utterly
+;; broken in GUILE 1 and would require changing a lot of unrelated
+;; innocuous constructs which just happen to fall apart with
+;; inscrutable error messages.
+
+;;
+;; Session-handling variables and procedures.
+;;
+;; A "session" corresponds to one .ly file processed on a LilyPond
+;; command line. Every session gets to see a reasonably fresh state
+;; of LilyPond and should work independently from previous files.
+;;
+;; Session management relies on cooperation, namely the user not
+;; trying to change variables and data structures internal to
+;; LilyPond. It is not proof against in-place modification of data
+;; structures (as they are just reinitialized with the original
+;; identities), and it is not proof against tampering with internals.
+;;
+;; As a consequence, session management is not sufficient for
+;; separating multiple independent .ly files in "-dsafe" mode: you
+;; should give each its own LilyPond process when reliable separation
+;; is mandatory.
+;;
+;; For standard tasks and programming practices, multiple sessions in
+;; the same LilyPond job should work reasonably independently and
+;; without "bleed-over" while still loading and compiling the
+;; relevant .scm and .ly files only once.
+;;