Ray Dillinger <email@example.com> wrote:
| Kenny Tilton wrote:
| > Lisp on the fly. Well, OK, it would be nice to have the Lisp advantage
| > and just recompile one bit of "C" header code and have The Right Thing
| > happen...
| A C-to-lisp compiler? We still wind up with an FFI problem, it's just
| moved back to the OS interface instead of the library interface. Or
| maybe the OS interface is relatively small? A few crucial things, like
| dealing with its abstractions over interrupts and hardware ports, and
| lispy versions of all the c libraries could be autocreated and work?
Hmmm... You guy have just given me a really evil idea... ;-} ;-}
Many [well, several] current operating systems permit some degree of
virtualization, such as VmWare, User-Mode Linux, or even just the
Linux emulation offered by the BSDs (especially FreeBSD). Suppose,
as an alternative to running the nasty C or C++ or Java code in a
separate process connected with a pipe or socket [a common solution
when the FFI is too messy], you hosted a User-Mode Linux (say)
*inside* your Lisp image, and then ran the nasty C or C++ or Java
code inside a virtual machine under Lisp's control. Could this
provide any advantages over either direct FFI in the same process
or pipe/socket communication in a separate peer process?
Lisp would not be "the" operating system, but would be a middleware
operting system virutalization layer [an O/S without needing all of
the messy hardware-dependent "real" O/S stuff.] That is, the Lisp code
would intercept any system calls from the slave "process" and could
provide "interesting" results to certain of the trapped file I/O calls,
say, while passing the rest on to the underlying O/S.
Just a thought... ;-} ;-}
Rob Warnock <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607