Minimum set of primitives?

Laurent Martelli
29 Mar 1998 19:24:00 +0200

>>>>> "Kragen" == Kragen  <> writes:

 Kragen> #1 is a little disturbing.  It implies that the "minimal" set
 Kragen> depends on the machine you're using.  If your machine is an
 Kragen> i386, it has instructions to do BCD arithmetic, for example.
 Kragen> Assuming some users of your Lisp have a use for BCD
 Kragen> arithmetic, you really ought to provide them with access to
 Kragen> the underlying machine's BCD arithmetic capabilities, instead
 Kragen> of forcing them to implement their own in Lisp.

That's why the minimal set should be as hash lvel as possible, in
order not to be machine dependent. But one could have different
implementations of the min-set depending on the machine's CPU and
other stuff. On a CPU with no mult instruction, the define that you
gave would be a good choice. But of course if you have a mult on your
CPU, you'd better take advantage of it.

Ideally, we'd have several implementations for each service of the
min-set. The choice of the implementation to use could be made at
compile time of the kernel.

We could extend the idea to non min-set services, so that an OS built
on top of Unix uses the native FS (possibly to implement an object
storage), whereas a from scratch version would implement its storage
with the bare device. I know that you can access raw devices with
Unix, but then you must have a partition for LispOS. The idea is the
same as UMSDOS for linux (ext2fs on top of FAT).

My dream is that you could give multiple definitions for each
service, and the choive woudl be made at run time, depending on some
kind of environment variables. A good compiler would be able to
optimize a service implementation for the most used environments. The
idea behind this is that dynamic binding is not needed all the
times. I'd say that 90% of the times, static binding can be used. But
one cannot determine exactly what the 90% are, so it's better to have
the compiler do this.

All this can be very nice if we have a well defined API. Let's say
that you have written a little library management program for all the
book sthat you have at home. It works pretty well because you do not
have a lot of books. But if you want to use it for your university's
library, a performance problem will arise. You could rewrite a part of
the appli to use a database but you'd have to deal with 2
versions. You'd to do the binding at hand. Whereas with a dynamic
binding, you'd just have to tell which implementation of the storage
interface you want to use : high performance DB at university, poor
man's FS at home. And the parts of the appli that use the storage
interface don't care what implemenation will be used. Nor does the

This is one way to have an open implementation. And I think that open
implementation is an important issue.

Laurent MARTELLI