[Openmcl-devel] sharing data between fortran and OpenMCL

[rm at fabula.de]

On Sat, Oct 02, 2004 at 11:51:49AM -0600, Hamilton Link wrote:
> >Getting even further off-topic, one of the things that bothers me 
> >about lisp is the notion that the lisp way is the right way and 
> >everything else doesn't matter. One of the things that I _really_ like 
> >about OpenMCL is the interface database and the relative ease with 
> >which one can interface with foreign code. It's a fact of life that we 
> >live in a heterogeneous world.

Yes, but it's exactly there where you leave "real" Lisp. There is no
such thing as an "memory address" in Lisp. That's an opaque implementation
detail hidden from the user (btw, up to a point this is the same even
in C today - try to write to your PC's parallel port under Linux ;-)
It's just that the OS/LibC developers take great pain to hide it from
the poor C coders vision. Never followed a "why does program X not
give back it's memory even if i call free()" thread?).
OpenMCL is very generous: it gives you a chance to get "under the hood" -
but you still have to play by _it's_ rules. One just can't hide all
memory resource menagement and at the same time have the user mess
with that resources (and here lies the problem: thank's to C's wounderfull
pointer fiddling it's almost impossible to control what resources are
still in use).

> I could say the same thing about C++ etc. -- many of them have FFI 
> libraries to different languages, but to which ones? Mostly they can 
> call into C libraries. Java has garbage collection and moves stuff 
> around, and you can't allocate stuff as far as I know in a way that 
> prevents it from moving around. If you want to do JINI magic to make 
> FFI calls, those objects get copied all over the place in and out of 
> GCed space (iirc).

Well, in certain ways C _is_ different: it's not so much C the language 
but rather the object code produced by C compilers. By now that object
code (aout/coff/elf) is the de-facto ABI on modern OSsen. Now, what
we want/need is a way to access that ABI ...
(Hmm, my co-worker has this nagging idea about using the information
in the object code to do ffi - or even use the debugging information.
After all, if gdb can call into a running application, why can't Lisp?).

> I don't know that Java can call into Fortran, and I'm pretty sure C++ 
> is right out for the same reason it's right out in openmcl -- i.e. that 
> there's no standard memory representation for C++ objects and every 
> compiler does it a little differently. So doing FFI calls into C++ is a 
> nightmare that is very target-libraries-compiler specific.

Objcet-oriented languages are different (since data and code are coupled).
It's less the memory layout (that should be detectable/or even standardized),
it's the code that goes with it. C++ ibs are a pain in the ... since there
are things like global initialization code etc. 

> Anyhow, hey let's all play nice with one another -- it's the why can't 
> we get along question, and as heterogeneous as the world is most 
> languages don't play well with others. Lisp has to play well with 
> others because the others all have enough resources to redundantly 
> define a thousand libraries, and we don't. Sure is a sore spot for some 
> lisp programmers though, not me so much (honestly, I'm mostly talking 
> from a tech point of view of the obstacles of why it won't happen in 
> the ideal complete fashion).

So, what _can_ we do? 
One thing that always struck me was the lack of support for FFIs where
the foreign code could return _native_ (LISP-native) datatypes. In all
the other languages i've toyed so far (TCL,Perl,Python, Guile) i could
create arrays, vectors, lists and even objects from within my library.
I'm still looking for a convincing way to even return an s-expression
to Lisp.

  Ralf Mattes
> h
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel