Owen Densmore wrote:
> So figuring out a good way to manage using different languages  
> together, synergistically, is pretty important.
>   
A datapoint:  Swarm interfaces are declared using an extended version of 
Objective C protocols.   These interfaces are parsed into Lisp data 
structures and then dumped in whatever form is needed for a given target 
language.   For example, COM dumps IDL, Java dumps Java interfaces, etc. 
and each dump compilable stubs as appropriate.  The callout and callin 
mechanisms of Swarm use the native interface to the respective language 
runtimes as needed to make or accept calls, do object reflection, etc.  
None of this requires any pipes or network features, it's all can be 
within single process.  By avoiding the need to ever to do direct 
assignment in the interfaces, its feasible to have a simulation made up 
of many components in many languages and given a sufficiently fast 
interconnect (e.g. RPC on Cell processors), it's also possible to span 
objects and messaging over processor boundaries.

Another, arguably better, way to do the same thing is to have compilers 
for different languages target an intermediate runtime.  Like .NET does, 
or to a somewhat lesser extent the JVM.  My favorite example for Java is 
Kawa (http://www.gnu.org/software/kawa).

> JDK 1.6 took a tiny step: defining a way for Java to talk to other  
> "scripting" languages.  But not the reverse .. how to call Java from  
> other languages like Python.
>   
One way to do this is with IKVM (http://www.ikvm.net) and IronPython for 
Mono/.NET. (http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython).

============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org

Reply via email to