Lisp on Mac OS X
in [Lisp]
|
From: Duke Normandin on 13 Feb 2010 10:07 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. ;) -- Duke *** Tolerance becomes a crime, when applied to evil [Thomas Mann] ***
From: Aleksandr Vinokurov on 13 Feb 2010 10:54 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? Aleksandr.
From: Raffael Cavallaro on 13 Feb 2010 10:54 On 2010-02-13 10:07:00 -0500, Duke Normandin said: > 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. ;) This is a false choice you're presenting yourself with here. Pretty much all common lisps have the ability to save an image (I think this what you mean by "VM-based" because you say "everything in an image!"). All common lisps, as per the spec, must compile and/or load individual files. In the common lisp community, VM-based means something entirely different than you take it to mean. It means that the implementation compiles to some sort of byte code which is then run on a virtual machine rather than compiling to native code. SBCL has a native compiler - it compiles to native code,(and extremely fast native code at that), not to byte code to be run on a virtual machine. CLISP compiles to byte code which runs on a virtual machine (i.e., the CLISP runtime). CCL - native. LispWorks - native and an interpreter. CCL's compiler is known for its speed of compilation - it compiles so fast that it doesn't need an interpreter. OTOH, SBCL's compiler is known for the speed of the compiled code it generates, though it takes a bit longer to do so. hth, Ralph -- Raffael Cavallaro
From: Tim Bradshaw on 13 Feb 2010 11:25 On 2010-02-13 15:07:00 +0000, Duke Normandin said: > 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. ;) Common Lisp defines how to load files either of Lisp source code, or compiled code (commonly called "FASL" files for historical reasons), and defines an interface to a compiler which can compile both files of source code or compile things in-core. Any CL implementation needs to support those interfaces. What CL *doesn't* define is what you might think of as a "delivery" mechanism - how to create something the OS will think of as an application, which you can run in whatever way is natural for the OS, and which will run your code. Obviously there is just huge variation on what that might mean (for instance a traditional Unix command-line tool needs to look very different to how OSX applications work), which is one reason it is not defined. I'm guessing that (amost?) all implementations do define such a mechanism, but it will vary based on the implementation. This variance is one of the things people (not you!) tend to carp on about when they're looking for an excuse not to use Lisp.
From: Duke Normandin on 13 Feb 2010 11:56
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 ;) 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". That being said, others on this NG have set me straight on this VM vs file-based matter. -- Duke *** Tolerance becomes a crime, when applied to evil [Thomas Mann] *** |