[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
- To: <xanatech>
- Subject: C Meeting
- From: Bob Perez <bobp>
- Date: Tue, 5 Dec 89 13:28:08 PST
- Cc: <bobp>, <joel>
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++
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
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
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
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"
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.