[E-Lang] Re: Your visit

Jonathan S. Shapiro shap@eros-os.org
Wed, 24 Jan 2001 14:13:44 -0500

[Copied to e-lang because the second part may be relevant to E-based
projects as well]

Francesco writes:

> ... I have been reading the last few
> e-mails focused on exception handling in the language binding of
> CapIDL and in its relationship with the underlying OS. I do not
> believe it is a good idea to revise the system call interface to support
> language-based runtime exceptions at this time.

I'm glad you raised this, because I completely agree. At this stage, the
only immediate change we plan to make to the EROS system call interface is
to rotate the resume capability so that it lives in the first position
rather than the last position. If I can convince myself that this rotation
can be hidden within the CapIDL stubs I'll even defer the rotation. Other
changes to the mechanism will be made, but they will not be made in the
critical path. The reason to do this particular small change early is that
it will drastically reduce the amount of code that needs to be rewritten
later. If CapIDL can hide the rotation, then of course it becomes a

Note that this change isn't a change in support of exceptions at all, and
that the invocation transport layer (a) has no knowledge of exceptions and
(b) probably never will. The CapIDL layer is currently expected to have such
knowledge, but this is purely a user level matter. The kernel implements no
runtime support for this at all. Norm has reminded me about a KeyKOS feature
in which a non-zero return code could be converted into a process-level
exception. This may prove a sensible thing to do. It can be compatibly added
later if we want it. I have no immediate plans to do it.

The question at hand is to define the language binding. This is one of those
areas where changing the interface later could cause a fair amount of pain,
so it is worth arguing it out. Appearances may be deceiving, but Mark and I
have been converging on CapIDL very very quickly. In fact, I think that the
question of exceptions vs. return codes is just about the last issue on
which we need to converge, and I'm about to pose a question on the e-lang
list that I think will force us to resolve one way or the other.

> I strongly believe that we should strive to keep the system simple
> and to get to the point that it works, without overburdening it with
> new constructs.

I agree. that said, I do object to "defer now, fix later" when it can be
avoided -- as you well know, rework never happens. Also, defining the CapIDL
interface is in the critical path of several things. If we can get a clean
interface definition language whose semantics is properly specified, it
becomes possible to write the *interfaces* for objects that do not yet exist
and build code against those interfaces while their development is in
progress. That is, CapIDL is an enabler for development parallelism.