Lisp on Mac OS X
in [Lisp]
|
From: Duke Normandin on 13 Feb 2010 12:37 On 2010-02-13, Raffael Cavallaro <raffaelcavallaro(a)pas.espam.s.il.vous.plait.mac.com> wrote: > 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. Ah! Like Java, e.g.? Making Lisp VM byte-code portable across platforms, given that no implementation-specific extensions are used? > 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. That helps to clear the fog. ;) What about CMUCL? > 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, Sure does! Thanks.. -- Duke *** Tolerance becomes a crime, when applied to evil [Thomas Mann] ***
From: Duke Normandin on 13 Feb 2010 13:02 On 2010-02-13, Tim Bradshaw <tfb(a)tfeb.org> wrote: > 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. So "fasl" code is the byte-code that Raffael was referring to in his post? > 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. You must be talking about compiling to native-code vs to byte-code? Or are you referring to stand-alone executables like those produced by C compilers? > I'm guessing that (almost?) 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. 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? -- Duke *** Tolerance becomes a crime, when applied to evil [Thomas Mann] ***
From: Tamas K Papp on 13 Feb 2010 13:11 On Sat, 13 Feb 2010 16:56:29 +0000, Duke Normandin wrote: > 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 ;) I still don't understand this categorization. Is this about deployment of executables? A CL implementation is free to use a VM based on some sort of bytecode (eg CLISP does), but it is unlikely to affect your life as a Lisp programmer, especially at the newbie level. Also, when you deploy executables, the whole thing is hidden from the user, who doesn't have to care either. > 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 Portability is an entirely orthogonal issue. If you use standard CL, and/or rely on widely available libraries like CFFI, your code will be portable. > doesn't suffer from massive bloat; with a simple, easy to use None of the CL implementations I know of suffer from any kind of "bloat". By today's standards, all of them are quite compact. > 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". Simple is a subjective term. People have invented useful tools, not using them will just make your life harder. > That being said, others on this NG have set me straight on this VM vs > file-based matter. I would hazard a guess that you are getting sidetracked on non-issues. Just use the standard tools and start programming, and stop worrying about these things. Tamas
From: Tamas K Papp on 13 Feb 2010 13:19 On Sat, 13 Feb 2010 17:37:23 +0000, Duke Normandin wrote: > On 2010-02-13, Raffael Cavallaro > <raffaelcavallaro(a)pas.espam.s.il.vous.plait.mac.com> wrote: > >> 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. > > Ah! Like Java, e.g.? Making Lisp VM byte-code portable across platforms, > given that no implementation-specific extensions are used? No, totally unlike Java. The resulting bytecode is not portable across implementations, so whether you use implementation-specific extensions is irrelevant, CLISP bytecode is for CLISP. CLISP bytecode is an implementation mechanism, not an attempt at (cross-implementation) portability. > That helps to clear the fog. ;) What about CMUCL? CMUCL is like SBCL. Tamas
From: Tim Bradshaw on 13 Feb 2010 13:25
On 2010-02-13 18:02:53 +0000, Duke Normandin said: > So "fasl" code is the byte-code that Raffael was referring to in his post? No, fasl files are most commonly (some representation of) object code for the target machine. However, for implementations which target some virtual machine, they would probably be object code for that, commonly called byte code. FASL files are conceptually fairly close to the .o files produced by C compilers on Unix, and somewhat less close to the ..class files Java compilers produce (because Java's class files have all sorts of extra stuff like needing to define a class & so on). > You must be talking about compiling to native-code vs to byte-code? Or are > you referring to stand-alone executables like those produced by C compilers? Yes, to some kind of standalone executable (or, really, an executable which depends only on the facilities the OS provides, since rather few executables are truly standalone). > > 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? I think that's right. |