Ray Dillinger  <bear@sonic.net> 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

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607