> What I do right now, is that I start the
> process in screen. And logs are printed directly in screen stderr.

Forgot to mention, have you read about the Twelve-Factor App conventions
(<https://12factor.net/>)? They also leave processes in the foreground,
write logs to stdout and use environment variables for configuration,
just like daemontools. So this line of thinking is now very widespread.

12factor originated from Heroku, and the idea is to run the development
versions of the services using a tool like Foreman
(<https://www.theforeman.org/>) that simply writes the logs to your
terminal instead of real log files. When shipping to staging/production,
the exact same process interface (foreground, stdout logs, envars) is
connected to a real logging and supervision system.

> This logging thing is something I would like to tackle at some point.
> In particular what is called structured logging. I am waiting for the
> completion of (scheme show) library (aka. SRFI-159?) to start working
> on it.

One simple approach to structured logging is JSON Lines
(<http://jsonlines.org/>). As with traditional log files, one log entry
is one line of text. But instead of free-form text it's a JSON object.
So the lines can be very long, but the files are easy to process. One
could do a similar S-expression Lines thing (each line is one plist).
The log timestamp can be just another field in the entry.