[Openmcl-devel] OpenMCL future

Rainer Joswig joswig at lispmachine.de
Fri Sep 13 15:17:44 PDT 2002

At 15:27 Uhr +0100 11.09.2002, Christophe Rhodes wrote:
>On Fri, Sep 06, 2002 at 09:21:44PM +0200, Rainer Joswig wrote:
>> At 6:34 Uhr -0600 06.09.2002, Gary Byers wrote:
>> >These are things that I have in mind; I'd certainly be interested
>> >in hearing other people's ideas.
>> It seems that there are a lot of Lisp implementations on OS X.
>> ACL is there and LispWorks seems to be in the works. Plus
>> some more.
>I suspect that CMUCL and/or SBCL will eventually be making an appearance
>on OS X; several of the CMUCL developers, at least, have acquired Macs
>with OS X, and I know of someone who is interested in having SBCL there

other Lisps on OSX seem to be:

CLisp, XLisp 3.3, scsh, Emacs Lisp, ThinLisp, ECL, DrScheme, Bigloo,
Gauche, ...

> > - CLIM (the real CLIM, not FreeCLIM) based on Cocoa/Quartz
>As far as I am aware, "FreeCLIM" aka "McCLIM" is an implementation of
>the CLIM specification... what do you mean by "real" here?

A port of the original CLIM implementation, also sold by Digitool
for MCL.

> > - investigation where Altivec could be used to speed up the
>>   Lisp kernel or compiled Lisp code
>I've been interested in this (well, coming from sbcl/x86-land, the
>analogous question of how SSE can help SBCL :-), and the conclusion that
>I came to was that first the compiler needs to understand loops
>properly. I don't know offhand what understanding the OpenMCL compiler
>has; the CMUCL/SBCL "Python" compiler doesn't do very much at all with
>loops, sadly, so it might be quite some work.

I wonder if there could be a special Lisp construct, or use in
searches, memory moves, GC, ...

>One thing I would be interested in is a slightly nebulous cooperation
>between at the very least the "free" implementors; for instance, in the
>sphere of extensions, it may be that interfaces can sensibly be shared
>across implementations. As a concrete example of this, consider Unicode
>support; work is ongoing to add Unicode to CMUCL; SBCL will probably
>acquire support eventually; Rainer wants support in OpenMCL; CLISP has
>it already, as do ACL and SCL; we might be able to save ourselves (and
>our users, if that's a distinct set) some pain if we hash out the issues
>involved, even if we end up not being 100% compatible in the end...

I think a Wiki for OpenMCL would be fine.

For coordinating efforts on extensions I would
just copy something like


 JSRs: Java Specification Requests

 JSR Overview

 Java Specification Requests (JSRs) are the actual descriptions of proposed
 and final specifications for the Java platform. At any one time there
 are numerous JSRs moving through the review and approval process.

and especially:


 Scheme Requests for Implementation

 The "Scheme Requests for Implementation" (SRFI) process is a new approach
 to helping Scheme users to write portable and yet useful code. It is
 a forum for people interested in coordinating libraries and other
 additions to the Scheme language between implementations.

Rainer Joswig

Openmcl-devel mailing list
Openmcl-devel at clozure.com

More information about the Openmcl-devel mailing list