On Fri, Apr 06, 2018 at 05:41:38PM +0700, Roy Lanek wrote:
> Better idea of an improvement: express execline as a Scheme
> library to be used via Chicken Scheme-to-C translator,
> Chibi-Scheme, and similar, which should be easy to do. Maintain
> bug-fixes for old execline. New implicit-execline successor
> becomes plain Scheme.
My idea:
* Port the execline-specific process state control functionalities
(eg. `redirfd -wnb') to Scheme; wrap, if necessary, process state
control functionalities as functions readily usable by Scheme scripts.
* Reimplement the process state control commands in Scheme, with the
source code / scripts just calling the underlying Scheme functions.
* Perferably, support something like scsh, so the Scheme scripts would
be nearly as clear as shell scripts; and perhaps rebase the Unix
interface in the Scheme implementation onto something like skalibs ;)
I consider this to be much more powerful than the current solution.
Considering the existence of elegant yet performant self-hosting Scheme
compilers (like Chez, which self-compiles in seconds), the proposed
solution can also be simpler in terms of total complexity.
With this solution, we probably no longer need chainloading commands
other than those manupulating process states: execline scripts for
oneshots and the stage 1/3 can be replaced by Scheme scripts; and AFAIK,
there are few (if any) longrun scripts that chainload into daemons which
themselves require commands like `foreground'/`if' on their command
lines. A last thing to address is libexecline, which can be reduced to
only support the nosh syntax at most.
As a final word, I guess reconciling Lisp and Unix would be much easier
than reconciling quantum mechanics and general relativity; and it would
be, in a perhaps exaggerated sense, as meaningful.
--
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Received on Tue Apr 10 2018 - 03:12:30 UTC