[info-mcl] digitool (MCL) / clozure (OpenMCL)

[Lawrence E. Bakst]

At 3:02 PM -0400 10/10/07, Andrew Shalit wrote:
>The question of whether to provide a detailed Cocoa interface or a 
>portable GUI toolkit is something we've been arguing about internally 
>at Clozure.
>
>We have our own opinions inside Clozure. Some people love the idea of 
>being able to use Core Animation from inside our CL applications. 
>Others just want to type (MAKE-INSTANCE 'WINDOW) and have it do the 
>right thing.  We'd be very interested in hearing where on that 
>spectrum MCL users come down.

I think this discussion should move to the OpenMCL mailing list.

Here's my take. In order.

1. A lot of effort has been put into the objective C bridge and Cocoa support and that should continue. While I'd prefer Carbon, it looks like the Cocoa folks have one the political war that has raged since NeXT took over, and finally won. It is now confirmed that Carbon on Leoprad will not have full 64 bit support, which is probably the beginning of the end, and is the end for 64 bit OpenMCL.

http://www.carbondev.com/site/?page=64-bit+Carbon

http://arstechnica.com/journals/apple.ars/2007/06/13/64-bit-support-in-leopard-no-carbon-love

2. I would like to see more work go into the IDE. I'm not a big emacs / slime fan and I miss the MCL IDE and other LispM and SmallTalk inspired IDEs. Having said that part of the magic are debugging tools and cross language alien calls make it much more difficult to achieve a superior result.

However a great IDE is hard work and it takes a great deal of iteration.

This is a large effort and there clearly aren't enough users to pay for it to make a business case. SSo i suspect that someone would have to sponsor it. It's kind of ironic that for a marginal language on a marginal platform there are so many Lisp alternatives (Allegro, Lispworks, SBCL, ...).

3. I would like to see the FFI polished up some more. There are some corner cases that aren't so easy to do, like float vectors that need to be copied back and forth, passing functions (I think), and I can't remember the whole list, but I am sure Gary does.

I would really like OpenMCL to be able to to interface to anything in a obvious way without any seams.

Some of this may require fixing or enhancing parts of OpenMCL. For example I think you need to have a way to allocate floating point vectors in a non moving heap so they don't have to be copied. If anyone is wondering, my motivation is OpenGL, where you often need to pass a vectors of 4 or 16 float numbers. It needs to work for float and doubles.

4. I would like to see the compiler improved. In particular, I would like to see math be faster, especially floating point math.

5. This is a topic for a different post, but I would like to see the GC re-worked or re-written so that it can run concurrently with the other threads. The eventual goal would be a fully parallel and concurrent GC.

I know this is a very big deal, but if we are going to move to a highly threaded programming model (we are) at some point in the not too distant future it won't be acceptable to stop all other computation on all the other cores, just to do run a (gc). I have some extended thoughts in this area but I'd prefer to share them with Gary, in private, at the right time.