Lisp on Mac OS X
in [Lisp]
|
From: Pascal J. Bourguignon on 13 Feb 2010 13:58 Duke Normandin <dukeofperl(a)nospam.net> writes: > On 2010-02-13, Aleksandr Vinokurov <aleksandr.vin(a)gmail.com> wrote: >> Duke Normandin <dukeofperl(a)nospam.net> writes: >> >>> On 2010-02-13, Paul Donnelly <paul-donnelly(a)sbcglobal.net> wrote: >>>> Duke Normandin <dukeofperl(a)nospam.net> writes: >>>> >>>>> I was leaning toward sbcl, but I think that it's a VM-based >>>>> implementation - >>>>> everything in an image! I like file-based... >>>> >>>> SBCL works like every other CL. >>> >>> Meaning? That it is VM-based like all others? or file-based like all others? >>> Remember - I don't know squat about CL! Just started the other day. ;) >> >> What did you mean 'file-based' and 'VM-based'? Complied into byte code >> and then interpretting it in VM vs. compiling into native processor >> code -- right? > > Some weeks ago, I took a look at Smalltalk, via Squeak and GNU Smalltalk. > Enough said about _that_, other than to say that in Squeak, you loaded a VM, > then an "image" that contained _all_ the Smalltalk language, plus the code > that you wrote. You then saved the image with a unique name, and that was > what you distributed (I guess). OTOH, GNU Smalltalk, was file-based, in that > you saved your work to a file, and loaded the file(s) into the VM for > hacking. I preferred the latter, but GNU Smalltalk had issues with OS X - > and I with OOP ;) Common Lisp implementations usually are less "image based" than Squeak and Smalltalk in general. But notice that you can very well edit Smalltalk code in your favorite editor, save a file, and load it in Squeak (or any other Smalltalk implementation), thus implementing a file-based workflow. By the same token, it is not too hard to implement a seamingly image based workflow with Common Lisp implementations, using emacs and slime (or just inferior-lisp), or even to implement a purely image based development work flow, but implementing the needed tools yourself (after all, slime is also a custom made package, somebody needed to do it himself). Have a look at: http://www.informatimago.com/develop/lisp/small-cl-pgms/ibcl/index.html Notice however that the development workflow is orthogonal to the implementation of the language. It happens that most Common Lisp implementations use an "image", because lisp objects are, at least theorically, tagged with type, so it's easier to implement a lisp specific heap of lisp objects (the "image"). But this is not a characterizing feature any more than any other unix process which works in its own virtual memory space. Only that in most cases, lisp implementations provide a feature to save and load their virtual memory space (the "image"), while normal unix processes written in C or other programming languages (but notably Smalltalk) don't benefit from this nice feature. > So in starting my journey into CL, I'm looking for an implementation that > will allow me to write as portable code as possible; code that doesn't > suffer from massive bloat; with a simple, easy to use console-based > interface. Problem with GUIs for me is that I have to spend as much time > fiddle-farting around learning to use the GUI, as I have learning the > language. ;) So, initially, I zero-in on KISS setups. When I get to the > point that I'm comfortable with the language, then I can focus on "slick > tools". Then you would be happy with clisp, I guess. > That being said, others on this NG have set me straight on this VM vs > file-based matter. -- __Pascal Bourguignon__
From: Pascal J. Bourguignon on 13 Feb 2010 13:59 Raffael Cavallaro <raffaelcavallaro(a)pas.espam.s.il.vous.plait.mac.com> writes: > On 2010-02-11 23:16:29 -0500, Duke Normandin said: > >> @Raffael >> Sure OS X is GUI intensive, but I do _a lot_ of work from the terminal. My >> newsreader is `slrn' ;) Thanks for the input! > > You miss the point here: > > If you choose a common lisp that can't access Cocoa, you and any Mac > OS X users of common lisp programs you write are stuck without a Mac > OS X GUI. You cannot do that. AFAIK, all CL implementations have a C FFI, and the Objective-C runtime is written in C. Fron any CL implementation, you will be able to call objc_msgSend. The rest, is only matter of writting the right macros and reader macros to be able to write in your lisp sources: [object doSomethingWith:anotherObject and:42]; This can be written as a portable objc library, and I guess you could steal that of ccl for your implementation. > The reverse is *not* the case; if you choose a Cocoa capable common > lisp, you are *not* stuck in the GUI. You are still free to use CCL or > LispWorks from a terminal, via slime, as a web server, remotely, etc. > > All of us, as programmers, "do _a lot_ of work from the terminal." The > point is, you don't want your users or yourself to be stuck there. If > you really live in a terminal 24/7/365, go back to linux where you > belong (ha ha, only serious). If you're a fan of open source but > understand the uses and advantages of a Cocoa GUI, use CCL. If you're > wise enough, or experienced enough to have learned that you rarely get > what you don't pay for, use LispWorks for Macintosh. Otherwise, I don't deny that ccl is a fine implementation for MacOSX development, and also for other targets. -- __Pascal Bourguignon__
From: Pascal J. Bourguignon on 13 Feb 2010 14:22 Duke Normandin <dukeofperl(a)nospam.net> writes: > Seems to me - from my admittedly limited understanding of things - that > between the various available Lisps, there should be an implementation > suitable for most needs/problems. Is that a fair statement? Since Common Lisp is a general high level algorithmic programming language, it can indeed be used to implement any algorithm you may envision. But if your problem is to re-use a java library, it would be easier to use ABCL than clisp or sbcl (on the other hand, if easy is not an objective of your project, you can as well implement a java-to-lisp translator, or a java-to-clisp-byte-code compiler, or all sort of things to reuse your java library in some way). -- __Pascal Bourguignon__
From: Raffael Cavallaro on 13 Feb 2010 15:59 On 2010-02-13 13:59:06 -0500, Pascal J. Bourguignon said: > You cannot do that. AFAIK, all CL implementations have a C FFI, and > the Objective-C runtime is written in C. Fron any CL implementation, > you will be able to call objc_msgSend. > > > The rest, is only matter of writting the right macros and reader macros > to be able to write in your lisp sources: > > [object doSomethingWith:anotherObject and:42]; > > > This can be written as a portable objc library, and I guess you could > steal that of ccl for your implementation. The SMOP argument does not hold water. For a negative existence proof, look at cl-objc for sbcl. (i.e., it doesn't work) The reality is, interfacing to Objective-C is *not* simply a matter of calling objc_msgSend. 1. For starters, you need to distinguish among messages that return id/void (objc_msgSend) vs those that return structs (objc_MsgSend_stret), and those that return floats (objc_msgSend_fpret). 2. To use Cocoa, you need to subclass, which means you need to define objective-c classes. This involves, among other things, ensuring that all of your ivar definitions have the right alignment for the abi you're interfacing with. 3. Then there's error handling and recovery. 4. Then there's all the issues related to sending data back and forth from lisp to the Cocoa runtime and how you handle garbage collection and cocoa memory management (e.g., your hybrid objects with some lisp slots and some objective-c slots are garbage collected how?) This isn't even an exhaustive list - iirc, there are issues relating to application launch and app bundles. There's a reason why there are only 2 functioning objective-c bridges from common lisp, and both were written by professional lisp developers with decades of experience interfacing lisp to c. Doing it right is a lot of work, and involves getting a number of details correct. warmest regards, Ralph -- Raffael Cavallaro
From: Pascal J. Bourguignon on 13 Feb 2010 16:38
Raffael Cavallaro <raffaelcavallaro(a)pas.espam.s.il.vous.plait.mac.com> writes: > On 2010-02-13 13:59:06 -0500, Pascal J. Bourguignon said: > >> You cannot do that. AFAIK, all CL implementations have a C FFI, and >> the Objective-C runtime is written in C. Fron any CL implementation, >> you will be able to call objc_msgSend. >> >> >> The rest, is only matter of writting the right macros and reader macros >> to be able to write in your lisp sources: >> >> [object doSomethingWith:anotherObject and:42]; >> >> >> This can be written as a portable objc library, and I guess you could >> steal that of ccl for your implementation. > > The SMOP argument does not hold water. For a negative existence proof, > look at cl-objc for sbcl. (i.e., it doesn't work) > > The reality is, interfacing to Objective-C is *not* simply a matter of > calling objc_msgSend. > > 1. For starters, you need to distinguish among messages that return > id/void (objc_msgSend) vs those that return structs > (objc_MsgSend_stret), and those that return floats > (objc_msgSend_fpret). > > 2. To use Cocoa, you need to subclass, which means you need to define > objective-c classes. This involves, among other things, ensuring that > all of your ivar definitions have the right alignment for the abi > you're interfacing with. > > 3. Then there's error handling and recovery. > > 4. Then there's all the issues related to sending data back and forth > from lisp to the Cocoa runtime and how you handle garbage collection > and cocoa memory management (e.g., your hybrid objects with some lisp > slots and some objective-c slots are garbage collected how?) > > This isn't even an exhaustive list - iirc, there are issues relating > to application launch and app bundles. > > There's a reason why there are only 2 functioning objective-c bridges > from common lisp, and both were written by professional lisp > developers with decades of experience interfacing lisp to c. Doing it > right is a lot of work, and involves getting a number of details > correct. > > warmest regards, > > Ralph I didn't say it was easy. :-) -- __Pascal Bourguignon__ |