a good volunteer

[Ray Dillinger]

On Mon, 28 Sep 1998, Yang Yuliang wrote:


>    what a pity that I saw this message so late,maybe you are doing 
> another project.
>    I'd like to be one of you.
>

Actually, I've joined the list sometime after it quit being
active, too.  My "read" from the archive was that things were
stalled waiting for a real honest-to-goodness LISP compiler that
compiled things to code just as fast and efficient as if they'd
been written in C and compiled with GCC. 

I mean, there were lots of problems discussed, but that's what
it comes down to.  The LISPs that produce real, solid machine
code tend to make very serious omissions in terms of numeric
support, dynamic compilation, or continuation support.  And
really, to do this thing well, we need all three.  And nothing,
but *nothing*, as far as I know, takes real full-bore LISP code,
complete with extended numerics and full continuation and
redefinition support, and produces kernel mode executables.

Once that LISP implementation exists, then a LispOS kernel can
be built.  And once the kernel is built, then utilities and
facilities and drivers can get made.  

I've chosen, quite independently, to work on the compiler.  But,
and this is a big problem, I'm still new to and struggling
with the C++ language.  My whole career has been spent hacking 
in Scheme, other LISP dialects, and in Application-defined
languages (AI languages that only exist in one shop) and C++ is 
very difficult for me to figure out what's going on in. At the 
same time, all the low-level interfaces I'm doing this to get
access to are defined with C++ API's, so that's the language
that this thing has to start with.  So it'll take a while....

My plan is to get a compiler, debugger, and a good IDE working
for windoze and/or linux, using mainly LISP (Scheme, to be
specific)  but with C++ code for the lowest-level OS interface
stuff.  Then I can develop a new kernel with Scheme API's and
rewrite the C++ bits for that kernel in native Scheme.

I've been working on it on sundays for several weeks now.  I've
defined an intermediate language (actually kind of a genericized 
machine code, plus semantic retention tags) and gotten an
interpreter written in scheme to execute a limited subset of it.  
That interpreter will be the basis of the system's low-level
debugger, when it's finished.

I've also worked on an IDE, but that gets into some of those
low-level C++ interfaces for fonts, text coloring, and unicode
strings, and I haven't got that working yet.  A wizard that came
with the compiler allowed me to build an MDI editor; I ported it
to win32 by changing some project configuration stuff and
recompiling, but it only works on ASCII and doesn't handle fonts
at all.  Furthermore, the source code for their class library is
unavailable. Even if it was available, I'm not sure it would be
"okay" to build it into a non-commercial product, so it's better
to re-implement than worry about later. Finally, if I'm going to
put font support into the compiler, I have to learn the API's
for it.... 

*sigh.*  There is much work to be done. Decisions about what the
kernel will look and function like can wait, I think, until
there is a truly viable compiler. 

If you can help me with the C++ bits of it for windows and/or
linux I'd be very grateful.  Of course, this implies a concrete
knowledge about the representation of scheme objects as seen by
the C++ functions... both in my current scheme dialect
(MIT scheme) and in the target dialect (which I haven't really
named yet, though right now I'm partial to "Ocelot Scheme" or
something like that).

I think I can specify these things as "C++ objects" with actor
and accessor functions -- then the C++ library is all that will
have to be switched out when moving from one OS or scheme
dialect to the other, and when making the final switch it can
just be replaced with the same library implemented in scheme to
run on the new kernel. 

				Ray Dillinger