Slashdot Mirror
Domain: clozure.com
Stories and comments across the archive that link to clozure.com.
Comments · 15
-
Re:Sparc
Not the most widely used software maybe, but SBCL is taking its time porting to ARM, Clozure CL doesn't have a port I'm aware of, nor does CLISP. The only Common Lisp implemantation I know of that works on ARM is ECL.
-
Closure/Clojure/closures/Clozure
Good grief. Homophone insanity. We've got Clojure [...] "closures" [...] And now Google jumps in with "Closure"
It's worse than that; there's also Clozure Common Lisp.
-
Re:Vendor Support?
Open source stuff, installs, usually without any reboot,
Unless, of course, it doesn't.
While things are getting better, the number of times a configure; make; make install run works properly is still far too low. Adding to this are the far too high number of packages that toss an "oh yeah... you also need to download and install packages X, Y, Z, and libSnood first, then alter Makefile.in appropriately," at the installer (who may have no clue what the appropriate changes to make are). Admittedly, a lot of this is made better via package management systems, but they aren't exactly foolproof either. There was an entry over at Mac DevCenter about the subversion packages being broken for both Fink and DarwinPorts. That's the kind of stuff that's truly maddening.
If I do need help there is usually better documentation than the commercial stuff provides
Wow. What kind of crap products are you buying? Documentation is the single biggest annoyance that I have when it comes to OSS. People just don't want to take the time to write something that is both complete and clear to a newcomer. Again, things are a bit nicer now that a developer can throw up a wiki and rely on his userbase to write the documentation for him, but it's still no great shakes.
The most annoying example of this that I had lately? Trying to figure out how to use OpenMCL to compile some code as a standalone, native app. The ability to do this is listed as one of its features, but I'll be damned if I can find that information in the "documentation". This is covered (albeit in a less than stellar manner) in e.g. the Franz-Allegro documentation.
and practical help is much easier to get if I should need it.
Well, here you're pretty much right. There are an awful lot of mailing lists, newsgroups, etc. out there where you can get help in a jiffy. Some of them still suffer from the RTFM disease, but this is getting much better. -
Re:I don't understand
"Dream?" Fantasize is more like it. If "recompiling" was all it takes, there would be no differences between what is available under OS X from anything else. Recompiling of C or C++ code (so long as it doesn't need to interact with Quartz/Aqua) targeting PPC has been available since Day One for OS X.
There probably shouldn't be much difference in how Common Lisp looks from one implementation or platform to another. Or at least that's the portability argument. I'll deal with this first, then return to whether this looks "satisfactory".
Several Common Lisp implementations on POSIX systems are highly portable in terms of functionality; many more are not. Portabiilty is at the Lisp level, performance is in the implementation. So, it really is a question of "recompiling" your portable Lisp source. Your interaction with Quartz/Aqua/The Mac in General can be mediated by e.g. CLUI or by CLX+X11 or some combination, and look and behave pretty much exactly the same as on a host Windows or Linux or NetBSD system.
Moreover, modern CL compilers target several ISAs, and modern runtimes can cope with the performance tradeoffs among various architectures, although with varying performance and possible extension gaps from one host system to another. Consequently, non-standard libraries made available by a portable implementation can also be used cross-platform.
However, that said, there are useful non-standard libraries which aren't (yet) portably cross-platform. Many of these are experimental. One in particular is the OpenMCL Cocoa programming environment, which is obviously Mac OS X centric.While it is one thing to run faceless software that can connect to the BSD guts of OS X, once it needs to talk to the user it will have to interact with the Cocoa (Objective C) GUI layer, or be retricted to running from the Terminal window or X11 or maybe use a Java presentation layer -- none of which are completely satisfactory (assuming there is a significant amount of user interaction).
The Mac OS X "way" is cooperating processes. A GUI front ends for scripted or compiled programs, exchanging data with it via XML, text or binary streams, or even shared memory/CoreData storage. Most apps that you'd find on VersionTracker for example, are exactly like this. Some of the apps are trivial GUIs for Apple-provided "command line tools" and the like. Many more are a mix of GUI and backend. Few are completely integrated within the same single program.
There is no particular reason why a bundle could not contain one or more fat binaries supporting x86 and PPC, some ruby or python scripts, and multiple GUIs -- one native Aqua/Quartz, one X11 (useful for remote X servers), one that runs an HTML server... The binaries could be standalone compiled Lisp code.
The code base that generates this would make delivery to a platform that is only X11 and x86 pretty easy... you just make new binaries (scripts and resources probably stay the same) and omit the Mac-specific stuff.Windozers apparently need not apply.
There are CL implementations for Windows that would gladly compile the Lisp backends without significant change to the source. The work would be in building the Windows-like GUI frontend.
Personally, I also far prefer the high-end G5 to any x86-derived implementation. However, I don't write Lisp (or Scheme or Python or shell scripts) specifically targetting the G5 or PPC... Most people writing Objective-C, C++ or even C probably aren't really writing non-portable code. So, having two Mac OS X platforms is probably not going to be as big a bear as supporting code for Mac OS X and any other platform, in some cases even including Linux/PPC.
Aggressive cross-platform thinking is a good move; abstracting away the pro -
Re:I don't understand
SBCL w/ Threading on OS X!? Dare I dream!?!?
What are you writiing in Common Lisp that is processor-dependent?
Okay, implementation-dependent things happen, so you might find yourself tied to Steel Bench for some reason... but if you can also target OpenMCL you'll find it has a kick-ass compiler as well as a fully preemptive thread scheduling model. ("[as of 0.14], lisp threads are native threads and all scheduling decisions involving them are made by the OS kernel. (Those decisions might involve scheduling multiple lisp threads simultaneously on multiple processors on SMP systems.)"
In fact, I'd almost reverse your wish and dream for cross-platform OpenMCL Cocoa Programming support.
But then again, I'm one of those evil Schemers...
I think my wish is a little more likely, despite little things like the register model and other implementational "details" that are compiler-specific. There have been enough good x86-targetting Lisp compilers to borrow ideas from that I don't think the compiler itself is the critical path.
As I understand it, SBCL's PPC implementation's blocking issue on native threading is a combination of the heap model, the existing stop-and-copy garbage collector, and fundamental differences in the dynamic linking of Mach-O and ELF (and COFF and a.out) binary formats. In particular, the x86 format and FFI and the ISA's small supply of registers to allow for register-to-register tagging and detagging, have driven a conservative collector.
While the free CL developer community is small and gets along reasonably well, and ideas (and people) seem to leak back and forth among the various projects, I think OpenMCL has it a bit easier because of the familiarity with SBCL and its antecedents and their compilers to Gary Byers and company, as well as being able to do a port with knowledge of how to use modern x86 chips' register handling. Starting with a thread-safe accurate generational collector makes many aspects of a CL implementation much easier, and not targeting the most primitive 386 ISA will also help with performance.
Underlining my thinking here is that according to the SBCL wiki PPC-port threading is wating on the port of the conservative collector. This is probably the shortest path to threading, but when you could use register-to-register tagging, boxing, mask-and-match against most-common-values, and other goodies that having lots of registers support, it doesn't seem anything like the optimal path.
However, since we're talking about programming Lisp rather than implementing it, surely the important thing to do is to start writing maximally-portable Common Lisp, get everything to work, and then optimize sections for various implementations and platforms?
If the peculiarities of SBCL favoured its use for a performance-sensitive application, I'd use it under that app. (This could happen easily enough... lots of non-consing/non-recursive arithmetic on |big| integers, for example, would obviously favour implementations where |big| is fixnum over implementations that robbed bits from fixnums to provide an accurate rather than conservative GC). If another CL implementation ran it faster or better, and it mattered, I'd use that under the app. -
Re:I don't understand
SBCL w/ Threading on OS X!? Dare I dream!?!?
What are you writiing in Common Lisp that is processor-dependent?
Okay, implementation-dependent things happen, so you might find yourself tied to Steel Bench for some reason... but if you can also target OpenMCL you'll find it has a kick-ass compiler as well as a fully preemptive thread scheduling model. ("[as of 0.14], lisp threads are native threads and all scheduling decisions involving them are made by the OS kernel. (Those decisions might involve scheduling multiple lisp threads simultaneously on multiple processors on SMP systems.)"
In fact, I'd almost reverse your wish and dream for cross-platform OpenMCL Cocoa Programming support.
But then again, I'm one of those evil Schemers...
I think my wish is a little more likely, despite little things like the register model and other implementational "details" that are compiler-specific. There have been enough good x86-targetting Lisp compilers to borrow ideas from that I don't think the compiler itself is the critical path.
As I understand it, SBCL's PPC implementation's blocking issue on native threading is a combination of the heap model, the existing stop-and-copy garbage collector, and fundamental differences in the dynamic linking of Mach-O and ELF (and COFF and a.out) binary formats. In particular, the x86 format and FFI and the ISA's small supply of registers to allow for register-to-register tagging and detagging, have driven a conservative collector.
While the free CL developer community is small and gets along reasonably well, and ideas (and people) seem to leak back and forth among the various projects, I think OpenMCL has it a bit easier because of the familiarity with SBCL and its antecedents and their compilers to Gary Byers and company, as well as being able to do a port with knowledge of how to use modern x86 chips' register handling. Starting with a thread-safe accurate generational collector makes many aspects of a CL implementation much easier, and not targeting the most primitive 386 ISA will also help with performance.
Underlining my thinking here is that according to the SBCL wiki PPC-port threading is wating on the port of the conservative collector. This is probably the shortest path to threading, but when you could use register-to-register tagging, boxing, mask-and-match against most-common-values, and other goodies that having lots of registers support, it doesn't seem anything like the optimal path.
However, since we're talking about programming Lisp rather than implementing it, surely the important thing to do is to start writing maximally-portable Common Lisp, get everything to work, and then optimize sections for various implementations and platforms?
If the peculiarities of SBCL favoured its use for a performance-sensitive application, I'd use it under that app. (This could happen easily enough... lots of non-consing/non-recursive arithmetic on |big| integers, for example, would obviously favour implementations where |big| is fixnum over implementations that robbed bits from fixnums to provide an accurate rather than conservative GC). If another CL implementation ran it faster or better, and it mattered, I'd use that under the app. -
Re:I don't understand
SBCL w/ Threading on OS X!? Dare I dream!?!?
What are you writiing in Common Lisp that is processor-dependent?
Okay, implementation-dependent things happen, so you might find yourself tied to Steel Bench for some reason... but if you can also target OpenMCL you'll find it has a kick-ass compiler as well as a fully preemptive thread scheduling model. ("[as of 0.14], lisp threads are native threads and all scheduling decisions involving them are made by the OS kernel. (Those decisions might involve scheduling multiple lisp threads simultaneously on multiple processors on SMP systems.)"
In fact, I'd almost reverse your wish and dream for cross-platform OpenMCL Cocoa Programming support.
But then again, I'm one of those evil Schemers...
I think my wish is a little more likely, despite little things like the register model and other implementational "details" that are compiler-specific. There have been enough good x86-targetting Lisp compilers to borrow ideas from that I don't think the compiler itself is the critical path.
As I understand it, SBCL's PPC implementation's blocking issue on native threading is a combination of the heap model, the existing stop-and-copy garbage collector, and fundamental differences in the dynamic linking of Mach-O and ELF (and COFF and a.out) binary formats. In particular, the x86 format and FFI and the ISA's small supply of registers to allow for register-to-register tagging and detagging, have driven a conservative collector.
While the free CL developer community is small and gets along reasonably well, and ideas (and people) seem to leak back and forth among the various projects, I think OpenMCL has it a bit easier because of the familiarity with SBCL and its antecedents and their compilers to Gary Byers and company, as well as being able to do a port with knowledge of how to use modern x86 chips' register handling. Starting with a thread-safe accurate generational collector makes many aspects of a CL implementation much easier, and not targeting the most primitive 386 ISA will also help with performance.
Underlining my thinking here is that according to the SBCL wiki PPC-port threading is wating on the port of the conservative collector. This is probably the shortest path to threading, but when you could use register-to-register tagging, boxing, mask-and-match against most-common-values, and other goodies that having lots of registers support, it doesn't seem anything like the optimal path.
However, since we're talking about programming Lisp rather than implementing it, surely the important thing to do is to start writing maximally-portable Common Lisp, get everything to work, and then optimize sections for various implementations and platforms?
If the peculiarities of SBCL favoured its use for a performance-sensitive application, I'd use it under that app. (This could happen easily enough... lots of non-consing/non-recursive arithmetic on |big| integers, for example, would obviously favour implementations where |big| is fixnum over implementations that robbed bits from fixnums to provide an accurate rather than conservative GC). If another CL implementation ran it faster or better, and it mattered, I'd use that under the app. -
Re:I don't understand
SBCL w/ Threading on OS X!? Dare I dream!?!?
What are you writiing in Common Lisp that is processor-dependent?
Okay, implementation-dependent things happen, so you might find yourself tied to Steel Bench for some reason... but if you can also target OpenMCL you'll find it has a kick-ass compiler as well as a fully preemptive thread scheduling model. ("[as of 0.14], lisp threads are native threads and all scheduling decisions involving them are made by the OS kernel. (Those decisions might involve scheduling multiple lisp threads simultaneously on multiple processors on SMP systems.)"
In fact, I'd almost reverse your wish and dream for cross-platform OpenMCL Cocoa Programming support.
But then again, I'm one of those evil Schemers...
I think my wish is a little more likely, despite little things like the register model and other implementational "details" that are compiler-specific. There have been enough good x86-targetting Lisp compilers to borrow ideas from that I don't think the compiler itself is the critical path.
As I understand it, SBCL's PPC implementation's blocking issue on native threading is a combination of the heap model, the existing stop-and-copy garbage collector, and fundamental differences in the dynamic linking of Mach-O and ELF (and COFF and a.out) binary formats. In particular, the x86 format and FFI and the ISA's small supply of registers to allow for register-to-register tagging and detagging, have driven a conservative collector.
While the free CL developer community is small and gets along reasonably well, and ideas (and people) seem to leak back and forth among the various projects, I think OpenMCL has it a bit easier because of the familiarity with SBCL and its antecedents and their compilers to Gary Byers and company, as well as being able to do a port with knowledge of how to use modern x86 chips' register handling. Starting with a thread-safe accurate generational collector makes many aspects of a CL implementation much easier, and not targeting the most primitive 386 ISA will also help with performance.
Underlining my thinking here is that according to the SBCL wiki PPC-port threading is wating on the port of the conservative collector. This is probably the shortest path to threading, but when you could use register-to-register tagging, boxing, mask-and-match against most-common-values, and other goodies that having lots of registers support, it doesn't seem anything like the optimal path.
However, since we're talking about programming Lisp rather than implementing it, surely the important thing to do is to start writing maximally-portable Common Lisp, get everything to work, and then optimize sections for various implementations and platforms?
If the peculiarities of SBCL favoured its use for a performance-sensitive application, I'd use it under that app. (This could happen easily enough... lots of non-consing/non-recursive arithmetic on |big| integers, for example, would obviously favour implementations where |big| is fixnum over implementations that robbed bits from fixnums to provide an accurate rather than conservative GC). If another CL implementation ran it faster or better, and it mattered, I'd use that under the app. -
Re:Somebody had to say it...
Wow... 12 years. Lots has changed since in far fewer years than that!
Maybe you should check out PLT Scheme, a modern scheme interpreter and compiler and IDE, with several "Teachpacks" which help one come up to speed in doing clever things with Scheme. DrScheme is the thing to download, for various platforms.
There are plenty of other Scheme implementations out there, interpreted and compiled.
Personally I do a lot in SCSH, the Scheme Shell which is handy for writing scripts and tools close to the metal on on UNIX/POSIX systems, however PLT and other environments are incorporating more and more of SCSH-like goodies into their libraries, and write stuff that needs to be fast in Chicken or Gambit, which compile Scheme to C. On the Common Lisp front, on a Mac, there is also OpenMCL, which compiles to *particularly fast* native PowerPC code and has a straightforward way of communicating with Cocoa and a number of other Mac-development-friendly features. In fact, all of these implementations have foreign-function-interface abilities which let you call e.g. C functions from Scheme/Lisp, or vice-versa, so you can write performance-critical sections in a low-level language of your choice, and use higher-level languages to develop "smarts". -
Lisps for the Macintosh
There are a few Common Lisp implementations as well
Open Source:
Open MCL
SBCL
Commercial:
Macintosh Common Lisp
Allegro Common Lisp
Xanalys Lispworks
-
Re:Lisp bad, python good?
Lisp community, OTOH, seems to think that only commercial implementations are worthwhile.
CMUCL and SBCL and OpenMCL and CLISP aren't exactly chopped liver. Steel Bank Common Lisp might be of particular interest to you, since it runs on most modern architectures and pretty much anything Unix-ish, and a Windows port is limping (see here for details). Or maybe CLISP - it compiles to byte codes, like Python, so it runs everywhere, at about Python speed.
Twist it any way you want, one standard open source implementation would guarantee better library and tool support.
You're probably right, but the other languages you mention that have one standard implementation also have a benevolent dictator/gatekeeper that "owns" that implementation, and by extension the standard for the language. They can evolve faster than Common Lisp or Scheme, which are defined by published specifications that aren't owned by one person, but that one person becomes a single point of failure for the language. None of them has yet had to survive the loss of their gatekeeper, and it's not clear to me that they can do so. All of them have problems that might have been avoided with a slower, spec-based evolution (rant - all of them do variable scoping wrong).
Being defined by a reference implementaton also holds languages back - the language is defined by the reference implementaton, warts and all. Take Python speed - CPython is slow compared to Lisps that compile to native code. Python compilers help, but as long as CPython is the reference, everything else (including compilers) will be non-"standard", and Python the language will still be thought of as slow. The Lisp community can't coalesce around one portable implementation like CLISP, because they'd have to give up the high-performance high ground.
Lisp turns 46 this year. It's behind the curve in recent protocols and libraries, but it's still here, and will likely still be around 46 years from now. -
Re:Not sure this is what we need
Sure.
Common Lisp
ANSI Common Lisp standard (X3.226-1994)
Popular commercial implementations:
Allegro Common Lisp
Xanalys Lispworks
Macintosh Common Lisp
Corman Common Lisp
Popular free implementations:
CMUCL
CLISP
Open MCL
SBCL
GCL
All of these implement the Standard, some better than others. All have interesting extensions which are not portable. All bring different elements of interest to the table of developers looking to solve different problems.
Perl and Python haven't for whatever reason needed to be forked to provide a better implementation for a specific market segment. While large applications are being written in these languages, they're obiviously not in environments where the demand on the engines is high enough to warrant someone funding a fork and a port. (say, Perl for Palm, or Embedded Python, or Enterprise Ruby, whatever -- there is no complete "Python Compiler", for example, that I'm aware of at least). Though ActivePerl et al should be acknowlegded.
BEA has JRockit which is its own JVM, though it may well ship Suns class library. They felt that they wanted a better JVM to meet their markets needs better than IBM and Sun were.
Put an implementation to work and the market will fork it as necessary. Just ask MS. -
Re:While this may sound... harsh
That's why languages with paradigms that don't translate well onto von Neumann-y notions (eg, LISP or Prolog) are interpreted as a rule.
I don't know much about Prolog, so let's look at current popular Common Lisp implementations:- CMU CL: natively compiled
- SBCL: natively compiled
- MCL: natively compiled
- OpenMCL: natively compiled
- Xanalys LispWorks: natively compiled
- Allegro Common Lisp: natively compiled
- Corman Common Lisp: natively compiled
- Scieneer Common Lisp: natively compiled
- Embeddable Common Lisp: natively compiled, via GCC
- GNU Common Lisp: natively compiled, via GCC
- GNU CLISP: bytecode compiled
- Armed Bear Lisp: Interpreted, only used as an extension language for an unpopular editor
-
Re:Symbolics PDA....Actually what would probably work best is a PowerPC PDA using OpenMCL, a Common Lisp that's optimized for space (4M, depending on the version). Add to this a small X server and a small CLX-based toolkit and you've got the makings of a fine PDA.
(Obligatory Lisp community stuff follows:)
Have you taken the Road to Lisp Survey?
Do you know about CLiki?
Have you ever been to #lisp on freenode? -
A Great Book on a Great Language
Graham's book is the definitive work on Common Lisp's macro facility, itself one of the prime features that make Common Lisp (not Scheme; there's a big difference) the most powerful language on the planet.
If your only exposure to Lisp has been a one-semester course that covered Scheme, you don't know Common Lisp. Try it before you judge it. Open-source versions are CMUCL for most Unix/Linux platforms and OpenMCL for Linux/PPC and Darwin/MacOSX. The full language spec and reference is online.
Now if somebody would just write as good a book for CLOS...