From: verec
Subject: Experience with both LispWorks and OpenMCL ObjC bindings?
Date: 
Message-ID: <45183a80$0$627$5a6aecb4@news.aaisp.net.uk>
I'm finding it difficult to commit to either because I lack
proper experience in both cases. Anyone would want to offer
pointers/advice?

So far my list reads as follows

o LispWors
  + better IDE
  - clumsy "invoke" to ObjC land (could write a custom defmacro job?)
  - clumsy string arguments for all of method, class or argument names
  - No unification of ObjC heap and Lisp heap (manual ref-counting
    required)
  - Current status looks like "set in stone"
  + LispWorks 5.0 works on intel-Macs today though the free
    personal edition is still not there

o OpenMCL
  - Non existent IDE
  + Natural "Lisp-like" syntax to ObjC land
  + Uses Lisp :keywords as standin for ObjC keywords:
  - No unification of ObjC heap and Lisp heap (manual ref-counting
    required)
  + OpenMCL seems to want to unify Cocoa and CLOS "whatever that may
    mean" in some not too distant future
  - OpenMCL only works on PPC macs today. Though there seems to be
    some comittement to an intel-Mac version, no date is given that
    I am aware of.

This last point is not too important right now because I still
develop on a PBG4, but, I need to get some feel for the likely
future of both re the intel-Mac side.

The rationale for all this is that the whole app is Lisp for the
server side, and whatever I want for the OSX client. I've done one
too many Java Swing based app already, and I really don't fancy getting
even lower (level) to ObjC with XCode.

Many Thanks
--
JFB

From: Raffael Cavallaro
Subject: Re: Experience with both LispWorks and OpenMCL ObjC bindings?
Date: 
Message-ID: <2006092701314875249-raffaelcavallaro@pasdespamsilvousplaitmaccom>
On 2006-09-25 16:22:24 -0400, verec <·····@mac.com> said:

> o LispWors
>   + better IDE
>   - clumsy "invoke" to ObjC land (could write a custom defmacro job?)

clumsy syntax can be remedied with macros as you note

>   - clumsy string arguments for all of method, class or argument names

you could construct these strings from keywords or quoted symbols if 
you prefer.

>   - No unification of ObjC heap and Lisp heap (manual ref-counting
>     required)

This is an inherent limitation of the Objective-C runtime - it has no 
real garbage collection. It's supposed to get it next year, so this 
problem may be lessened simply by waiting for Leopard and deploying on 
that only. Otherwise, you have to follow the standard retain/release 
disciple. The Apple docs on the subject are at:

<http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html>

The 

bottom line for lisp is that the lisp runtime cannot know how to deal 
with a particular allocation because it cannot always know who "owns" 
that particular object.

>   - Current status looks like "set in stone"

what does this mean?

>   + LispWorks 5.0 works on intel-Macs today though the free
>     personal edition is still not there

This is a key feature for me - remember, the future for macs will be 
increasingly intel, and increasing irrelevancy of ppc. any lisp that 
isn't intel native at this point looks like a poor bet for the future.

> 
> o OpenMCL
>   - Non existent IDE
>   + Natural "Lisp-like" syntax to ObjC land
>   + Uses Lisp :keywords as standin for ObjC keywords:
>   - No unification of ObjC heap and Lisp heap (manual ref-counting
>     required)
>   + OpenMCL seems to want to unify Cocoa and CLOS "whatever that may
>     mean" in some not too distant future

this has been the plan for a couple of years now but it hasn't happened 
yet (I wouldn't hold my breath)

>   - OpenMCL only works on PPC macs today. Though there seems to be
>     some comittement to an intel-Mac version, no date is given that
>     I am aware of.

talk on the openmcl-dev list indicates that 32 bit intel machines will 
*never* be supported, which makes this a non-starter if you want to 
support, for example, currently shipping MacBooks, MacBook Pros, iMacs 
...

LispWorks is far from perfect, but it is a supported product that 
already runs on Macs - both intel and ppc, as well as Windows and 
Linux. OpenMCL is, right now, a ppc-only lisp. Gary Byers is a great 
guy, and very receptive and responsive to user ideas, comments and 
requests, but at the end of the day he has distinctly limited time so 
unless you can pay him a serious chunk of change he's going to take 
OpenMCL in the directions that he thinks best at the pace allowed by 
his free time to do so. Therefore, if I were you, I would subscribe to 
the mailing list and/or read the archives to get a feel for where and 
how quickly OpenMCL is going and see whether this will ultimately suit 
your needs.
From: ······@corporate-world.lisp.de
Subject: Re: Experience with both LispWorks and OpenMCL ObjC bindings?
Date: 
Message-ID: <1159369888.224455.270260@e3g2000cwe.googlegroups.com>
Raffael Cavallaro wrote:
> On 2006-09-25 16:22:24 -0400, verec <·····@mac.com> said:
>
> > o LispWors
> >   + better IDE
> >   - clumsy "invoke" to ObjC land (could write a custom defmacro job?)
>
> clumsy syntax can be remedied with macros as you note
>
> >   - clumsy string arguments for all of method, class or argument names
>
> you could construct these strings from keywords or quoted symbols if
> you prefer.
>
> >   - No unification of ObjC heap and Lisp heap (manual ref-counting
> >     required)
>
> This is an inherent limitation of the Objective-C runtime - it has no
> real garbage collection. It's supposed to get it next year, so this
> problem may be lessened simply by waiting for Leopard and deploying on
> that only. Otherwise, you have to follow the standard retain/release
> disciple. The Apple docs on the subject are at:
>
> <http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html>
>
> The
>
> bottom line for lisp is that the lisp runtime cannot know how to deal
> with a particular allocation because it cannot always know who "owns"
> that particular object.
>
> >   - Current status looks like "set in stone"
>
> what does this mean?
>
> >   + LispWorks 5.0 works on intel-Macs today though the free
> >     personal edition is still not there
>
> This is a key feature for me - remember, the future for macs will be
> increasingly intel, and increasing irrelevancy of ppc. any lisp that
> isn't intel native at this point looks like a poor bet for the future.
>
> >
> > o OpenMCL
> >   - Non existent IDE
> >   + Natural "Lisp-like" syntax to ObjC land
> >   + Uses Lisp :keywords as standin for ObjC keywords:
> >   - No unification of ObjC heap and Lisp heap (manual ref-counting
> >     required)
> >   + OpenMCL seems to want to unify Cocoa and CLOS "whatever that may
> >     mean" in some not too distant future
>
> this has been the plan for a couple of years now but it hasn't happened
> yet (I wouldn't hold my breath)
>
> >   - OpenMCL only works on PPC macs today. Though there seems to be
> >     some comittement to an intel-Mac version, no date is given that
> >     I am aware of.
>
> talk on the openmcl-dev list indicates that 32 bit intel machines will
> *never* be supported, which makes this a non-starter if you want to
> support, for example, currently shipping MacBooks, MacBook Pros, iMacs
> ...
>
> LispWorks is far from perfect, but it is a supported product that
> already runs on Macs - both intel and ppc, as well as Windows and
> Linux. OpenMCL is, right now, a ppc-only lisp. Gary Byers is a great
> guy, and very receptive and responsive to user ideas, comments and
> requests, but at the end of the day he has distinctly limited time so
> unless you can pay him a serious chunk of change he's going to take
> OpenMCL in the directions that he thinks best at the pace allowed by
> his free time to do so. Therefore, if I were you, I would subscribe to
> the mailing list and/or read the archives to get a feel for where and
> how quickly OpenMCL is going and see whether this will ultimately suit
> your needs.

There is a experimental openmcl-darwinx8664-snapshot-060826.tar.gz .

I don't care much about current 32bit Intel machines. Probably all
machines will be 64bit Intel (Core 2 and above) in the near future
(iMacs and MacPro are already 64bit Intel). If there is any
64bit Macbook, I'll sell my 32bit Macbook immediately.

As much as I like these Lisps, I think there is a massive opportunity
for
a (new) Lisp which has a Cocoa-based IDE and Cocoa-based libraries.
Just like MCL with the old Mac OS.  The LispWorks IDE is a bit
old-fashioned
and not really Mac-like. OpenMCL's IDE is just a sketch. But OpenMCL
could
be the underlying base Lisp for such an IDE.
From: verec
Subject: Re: Experience with both LispWorks and OpenMCL ObjC bindings?
Date: 
Message-ID: <451c3639$0$624$5a6aecb4@news.aaisp.net.uk>
On 2006-09-27 16:11:28 +0100, ·······@corporate-world.lisp.de" 
<······@corporate-world.lisp.de> said:

> As much as I like these Lisps, I think there is a massive opportunity
> for a (new) Lisp which has a Cocoa-based IDE and Cocoa-based libraries.
> Just like MCL with the old Mac OS.  The LispWorks IDE is a bit
> old-fashioned and not really Mac-like. OpenMCL's IDE is just a sketch.
> But OpenMCL could be the underlying base Lisp for such an IDE.

I too have been considering an "OS X Like Lisp IDE" for a while, but
I'm just put off by the amount of work.

One possible route, though, could be to consider an existing
open source OSX "text editor" and adapt Slime to connect to
a regular CLI Lisp.

I have looked at Smultron, http://smultron.sourceforge.net/
as a possible starting point...
--
JFB