C Meeting

[Bob Perez <bobp>]

A meeting was held Monday afternoon between markm, ravi, roland 
and myself on the issue of how we will provide Docs & Links level 
access to C programmers. I'm happy to say that this was a very 
productive meeting which resulted in a proposed solution which 
succeeds not only in meeting a good portion of our stated objectives 
but probably also adds additional general utility to our C++ 
code.

The meeting began with an exploration of how much of the task 
we felt could be automated, and how much we would have to do manually. 
This required an enumeration of some overall impedance matching 
issues confronting us:

1. Heaper ** vs. Array *
2. C representation of other tables
3. ""               "" Sets
4. ""               "" Regions
5. ""               "" Steppers [but see below]
6. Waldoes, Docs & Links stuff
7. Fluid variables, Garbarge collection and Bombs

>From a discussion of Steppers emerged the general observation 
Status: RO

that there are two fundamentally different ways of equipping 
C programmers: we could provide them with the raw data, document 
all of it, and then let them munge their way through it; or we 
could provide them with opaque ptrs and a procedural interface 
to the data that preserves at least some of its object-oriented 
heritage.

Initially it was argued that the first approach (raw data) would 
be more in line with the expectations of C'ers and that the second 
approach would seem foreign. After some discussion we agreed, 
however, that this probably wasn't true and that most C programmers 
in fact live in a world teeming with objects. Interfacing to 
an ISAM package, the Macintosh Toolbox or Microsoft Windows; 
these are all object-oriented experience to some significant 
degree and we had to remind ourselves that it wasn't our goal 
to insulate C'ers from object-orientedness per se, but rather 
to insulate them from C++. Accordingly, we decided to adopt the 
second approach.

After some discussion we discovered that with a few relatively 
minor modifications to our table classes we could use stubble 
to generate a set of C wrapper functions implementing the procedural 
interfaces (once again, stubble demonstrates its tremendous general 
utility!). The resulting tool for generating these wrappers came 
to be known as Ceran, and Roland seems sufficiently confident 
that it could be done that he attached a gleeful week's estimate 
to the task.

[Note that this discussion assumes a complete translation of 
everything. Although it's not clear that C programmers need/want 
a C representation of Tables and Steppers, for example, in anticipation 
of the various kinds of translations we know we will want to 
provide, it makes sense to begin with the general case and pare 
downward once we've agreed on a simplification strategy and assured 
ourselves that Ceran works].

Generated C wrappers implement exception handling by assuming 
the existence of a function called "Error_Happened", the implementation 
of which is left to individual developers using their own C libraries. 
"Error_Happened" gets passed a data type "Problem" (describing 
the exception) in the body of the wrapper's "catch" function 
prior to the return. (Note: I'm going from memory now without 
benefit of notes or videotape and so I'm sure that I've libelously 
misrepresented the true nature of the mechanism, in which case 
someone will  chime in :-).

I'm not sure that we need to provide any C representation for 
fluid variables, but the garbage collection issue was handled 
neatly with the notion of an Enrollment Module. This module would 
act as a registration table, keeping track of all ptrs allocated 
for the benefit of the C programmer, and freeing up discarded 
ptrs in a manner consistent with our garbage collection mechanism. 
As new ptrs are allocated to the C programmer they are "enrolled" 
in the table and used throughout the program as required. When 
the programmer has no further use for a ptr it is "expelled" 
from the table, freeing it for garbage collection (I guess this 
applies only to SPTRs?), and the experience sufficiently parallels 
the malloc/free model that it imposes no undue burdens (actually, 
it's even simpler because we'll probably handle most of the "enroll" 
calls explicitly in our wrapper functions prior to handing back 
the ptr, and leave it to the developer only to explicitly "expel" 
as necessary).

The bad news is that the minor alterations to our table stuff 
will probably have to be implememented by Hugh and Ravi. The 
good news is that the proposed changes are consistent with H&R's 
existing plans vis a vis protocol reduction anyway, and thus 
won't unduly block their progress (I guess you could say that 
this isn't necessarily an H&R block :-).

The task of implementing Ceran and documenting the extent of 
its visibility to C programmers will fall to Roland and I. The 
timing of all of the above work is still an issue and will depend 
on the resolution of other issues to be discussed this week. 
As has been pointed out in the recent C++/C threads, this effort 
represents work that was contemplated from the beginning as a 
necessary stage in the evolution of our developer toolkit. Personally, 
I'm happy to see that this aspect of the job, once defined, turned 
out to be less a chore than anticipated and many kudos should 
go out to the various architects of X++, stubble, and the table 
stuff for their design prescience. The big payoff for Xanadu 
is that C programmers will eventually have access to Xanadu with 
a very straightforward, neatly packaged interface.

-- bobp