[Openmcl-devel] sharing data between fortran and OpenMCL

Cyrus Harmon cyrus at cyrusharmon.org
Fri Oct 1 21:19:34 PDT 2004

Sure, but in comparison with C memory management, the garbage 
collection really means two things, one obvious, one less so. The first 
is that memory just appears and disappears when you need it and no 
longer need it. That's really nice. The second is that objects in 
memory can move around on you to make the whole system work better. 
That's also nice, but poses some issues when dealing with non-lisp 
components, be they system resources, other code libraries, etc...

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. Back to my particular corner of the world. There's 
some really nice fortran code for dealing with big matrices out there. 
I don't want to (and probably can't) rewrite this stuff in lisp. On the 
other hand, I don't want to write my systems code, web server, db 
access, etc... in fortran. I want to use lisp. OpenMCL seems to be 
pretty useful here and I'm just trying to sort out all of the details 
in how one would use this stuff in a heterogeneous environment. In 
SBCL, and, I think, ACL, there are some tricks one can do to make it so 
one can avoid round-trip copies of the data as you move between lisp 
and the fortran code. It would be nice if I could do the same thing in 
OpenMCL and I think I can, I'm just trying to sort through all of the 
issues and trying to figure out the best way to proceed here.

Also, you shouldn't be so dismissive of a trumped-up portable assembly 
language. There's lots of really nice trumped-up (not-so) portable 
assembly language at the core of OpenMCL I'm discovering. One of the 
interesting things (to me) about lisp is that you can basically write 
lispy lisp, c-like lisp, or even assembly language in the same overall 
framework. This is pretty helpful if you need to interact with the 
c-world or the assembly-world, I think.


On Oct 1, 2004, at 9:00 PM, Hamilton Link wrote:

>> If you find yourself asking "why don't most lisps just do
>> memory management like C does?" ... well, that's a legitimate
>> question, but...
> It's a legitimate question, but... you might as well ask why lisp is 
> an OO language instead of a structured language. Built-in memory 
> management is a language feature, Lisp has it and ML and Java and a 
> slew of other languages have it. C doesn't, but it's not an OO 
> language either, nor does it have incremental compilation. It's a 
> statically typed, statically compiled structured programming language 
> (if you're more polite than I am -- I usually just call it a 
> trumped-up portable assembly language).
> h

More information about the Openmcl-devel mailing list