InterLanguage Connectivity Solutions

[Eric W. Biedermanebiederm@cse.unl.edu]

I'm putting this at the head so anyone can find it.  The rest rambles.
The major advantage I see in an IDL, (coupled with a PDL for
practicality) is that for various components of Tunes say a persistent
storage system (File system), Display system, OS interface,  and
others we could concentrate on the semantically important things the
interfaces.  Then we could write them in whatever language is
convinient and go from there.  The real advantage of OO is that it's
fine grained not monolithic after all.

   > The issue of how to interface multiple languages together, has never
   > been terribly difficult, but it has been a lot of work.
   Oh, yes.

   > Having
   > programs in multiple languages communicate can be made a lot simpler.
   Yes and no:
   if you mean it is simpler to reimplement languages
   with a weak communication channel than with a strong one,
   then yes, but you lose a lot for not much;
   if you mean it is simpler to take existing implementations
   of languages and have them communicate,
   then I fear it's not that simple *at all* !
   Whatever you do, it'll be costly...

Binary compatiblity and dealing with the objects produced in a single
address space/protection domain is not simple and has a great number
of problems.  OTOH communication between programs in different
protection domains is common and that interface is what I am trying to
work on here.  Local automony but global communication.

   > The best approach I have seen is to have a ``interface definition
   > language'' (IDL) and multiple compiler for it that create stubs in
   > various languages.  If we could use this technique and let the
   > interfaces be language independant in TUNES we could probably go a
   > long way.
      If it means yet another crippled language,
   as CORBA does, I strongly disagree:
   all the interest in programs is the abstract objects they express,
   with some low-level constraints and performance.

(low-level constraints and performance?)

I see it as the only interest in programs is the way the communicate.
Defining that in terms of objects allows for _interface_ subclassing
that has some neat benefits.  The unix guys when the try for
everything is a file are trying for something like this.

      If your IDL can only express
   the constructive aspect of not-so-abstract objects,
   then you lose the major long-term advantage of multiple languages,
   that is, using ones most adapted to each task undertaken,
   because you loose the 99% of the logical information
   that only can warranty program consistency
   (all the more when languages have to follow
   each other's implementation's contraints).

   Of course, you can still try to recycle code by interfacing it,
   but this may involve so much writing of IDL definitions
   and understanding of what's being done,
   that the advantage of the IDL is not clear to me.

The advantage is not in the fine grain one routine in this language
one in another, but more at the coarse grain, on module/library in
this language, another in that.  It also won't save you if you program
in M4 and assembly.  But it will let you do things like interface the
OS without C callouts.

   > I like the idea of an IDL if semmantics is to be the important thing.
   > Furthermore if we have an IDL we could concentrate on the _interfaces_
   > that are needed to write tunes in.  We can then split out and work on
   > an OO filesystem, and other things that it takes to create an OOOS,
   > you know a primordial oooz, that is to be TUNES. :)
      Yes, that's right.
   Perhaps you could try to define such a language for us,
   if possible as s-exps ?
   Well, I guess this could "just" be another kind of patterns in the HLL,
   so except for a few primitives, we're back at the HLL and its patterns...


   > An example of an OS that has done things in a similiar manner to what
   > I'm thinking is Spring from sun.
   > <a href = "http://www.sun.com:80/tech/projects/spring/papers.html">
   > Spring Bibliography</a>
      I should read the recent papers on Spring,
   but I admit this OS disappointed me,
   because it tried to make things with the same old paradigms.

I agree.  On the other had the foundations upon which spring are laid
are very much what it takes to be a good OO OS.  The doors, and the
fact that different programs communicated in a language independent
manner, and were completly replacible is what I liked.


   Mr. Nobody wrote:
   > Probably it'd be even better if interface definition and interface
   > representation could be separate things.
      Ahem, I'm not sure how you could separate interface definition
   and representation, or if they are different.
   Could you expand a bit on that ?

The IDL is completely language neutral with all those things that it
takes to describe an interface.  The Presentation Definition Language
also is language netral (or mostly so) what it does is vary the the
stubs are generated.  Switching order of arguments, specializing
marshaling and unmarshaling of arguments to reduce copying, changing
the semantics/specifying the sematics that are independent (mostly) of
the communications protocol used.  Of course also you need not have a
single commnications protocal either.

The current work on this is being done by those working on Mach 4.0
for program optimisation, but it also good for generalized
communication. 

   > That way you don't need to build a new
   > stub generator for every new language you're going to support.
Only half right you need a new backend for every language you are
going to support, or else it can't do anything.

      That, abstraction gives you, yes. But again, why another language ?
   The two languages will have a lot in common, need to interface,
   and mixing them can be particularly useful, as it would simplify the
   meta-language (which could be itself, by reflectivity).

Perhaps it's not really to languages the important part is the clean
seperation of the interface definition from the presentation
definition (which has a default, you just specialize it) and making
sure the IDL source need not be modified to do PDL work.

an example. IDL into C++

interface wanabe {
  void func(objref one, objref two)
};

___ now the IDL could generate any of  _____

void wanabe::func(object * one, object * two);
void wanabe::func(object * one, object & two);
void wanabe::func(object & one, object * two);
void wanabe::func(object & one, object & two);

void wanabe::func(object * one, object two);
void wanabe::func(object & one, object two);
void wanabe::func(object one, object two);
void wanabe::func(object one, object *two);
void wanabe::func(object one, object &two);

void wanabe::func(object * two, object * one);
void wanabe::func(object * two, object & one);
void wanabe::func(object & two, object * one);

void wanabe::func(object & two, object & one);

void wanabe_mine::func(cool_object & one, awesome_object & two);

___ 
without violating the the interface specification.  The PDL is used to
control what it generates.  Thats why you need two languages or at
least two parts.


Eric