InterLanguage Connectivity Solutions

[Francois-Rene Rideau]

> 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...


> 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.
   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 Object Mangament Group (OMG) and Corba seem to be a good starting point
> in that direction.
   I'm convinced that because their IDL is so little expressive,
it can't really bring much.
   To me, the future is
in high-level semi-reversible semi-automatic code rewrite,
not in one-way manual low-level interfacing.


> 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.


> Hope that puts a new spin on our musical engine, that useful not
> expedient system. Comments and requests to further references are
> welcome.
   Thanks for the contribution.
   
   I admit I really have not a second for Tunes these weeks.
   Patrick ? Have you got the code from the latest unofficial release ?

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"