Re: if (c++ && x++)

[Roger Gregory <roger>]

This is a preliminary report on my discussion with bobp & markm
yesterday.  We have identified 5 interesting levels of support
for C programmers:
1) tranceiver 
2) docs & links libraries 
3) everything, including compositor access
4) subsystem access, prepackaged editors & the like
5) stdio

The tranceiver level is basic raw access to the backend documented
with a BNF and implemented with a few lowlevel communication calls.

The docs&links libraries are similar to the 88.1 libraries that roland wrote.
They will provide access to the be encapsulated in a standard set of
library routines.

Everything in the C++ class library can be made available by a simple
transformation of foo->bar(baz) to something_bar(foo,baz) where something
is to distinguish between overloaded functions.  This approach could either
treat pointers to c++ classes as void * or create the equivalent struct
definition for C.  My feeling is to create the C structs, mostly to reduce the mystery
of it all and to facilitate C program access to random internal stuff.
This is relatively eaisy to implement, and simple to abuse.  It is going to be
very difficult to learn, being identical to the C++.  It will also cause code 
to be non portable to later xanadu releases.  Caution will be advised.

Subsystem access will let developers bring up large pieces of our application
code, for example an editor in a window, withoud knowing any of the internal details.
Communication with the pieces will be through well defined interfaces.  In the
editor example, the selection mechanasim should be sufficient for most simple
applications of an edit window.  This should provide 90% of the power of our
tools with 2% of the complexity.  Exactaly which pieces can be cleanly provided is
a reasearch project, but I feel we should err on the side of simplicity.  If the 
simple stuff isn't enough at some stage in a project's development, that piece can be
coustomized in X++ or written from scratch.

The stdio package is a simple hack to allow programs written with standard c lib
stuff to read and write from xanadu.  Markm feels it could be quite important.
I'm agnostic on this one. 

We probably will do all of these, with the least emphasis on #3.
The problem with complete access to all of our c++ tools is the complexity.
Anyone who wants access to all the tools should be in C++, we may make them
available anyway so they can be used for special cases.

Of these 5 the most code will have to be written for the docs&links lib.
The most thought will have to go into the subsystem access.  The most documentation
will have to be written for the X++ classes.  The most clever hacks may be in the 
stdio lib.  Possibly most applications won't be written from the tranciever level, but
certainly the will all be debugged there.

This is all just preliminary, but I haven't heard any disagreement with it.  I keep wracking
my brain for other things we might provide for C programmers, but simplicity may be
more valuable.  There may have been some confusion in our previous mail discussions,
when I wrote of providing limited libraries, I menat that in the markm minimalist
sense.  Provide the sufficient subset to build the rest.  Given that we have 
already built the rest that seems unfair, but the complexity of using our stuff,
especially in C, probably isn't worth it.