Slashdot Mirror

but at thesame time why don't we have a math lib that supports it all? rounding support for financial institutes, fast math until it overflow the 32 bits, double where precision is not defined and arbitrary precision when you tell it to.

We have, it's called Common Lisp - at least in some implementations. I never understood why Common Lisp and Scheme are the only languages with sane numeric types and operations.

Alright, I understand that "Eclispse" doesn't suck, but can someone enlighten me as to what it is? Sounds like a good name for an IDE for CLISP.

http://clisp.cons.org/

Considering that Emacs is a lot of folks' LISP engine of choice, the standalone GNU implementation seemed a legitimate choice.

I am not sure why this is marked funny, it is a good point. Lisp can be compiled http://www.cons.org/cmucl/ and does not enforce types in function prototypes. The downside is that types are either atoms or lists, but it shows that this is not impossible.

They fixed the whitespace problem in a fork:

http://clisp.cons.org/

CMU CLis a Common Lisp compiler/interpreter (written in cl). Its code is just beautiful - after about 1-2 months since my first contact with lisp I understand nearly everything at first glance. (SBCL also have very nice code). OpenBSD's code (written in C) is also very clear and pretty.

you should see the source for CLISP; the light-weight and super-fast Common Lisp implementation, now part of GNU.

Scheme/Lisp/Erlang/others. Every one of these I've looked at has one fatal flaw: It's not JIT'ed, or compiled. Erlang can be compiled, but then you lose one killer feature: even if they're just bytecode-compiled, compiled functions cannot be replaced at runtime, the way other Erlang functions can.

• CMUCL
• SBCL
• ABCL (compiles to Java bytecode)
• CLISP (compiles to bytecode)

I know that in all of these you can replace a compiled function at runtime with another compiled function, both from personal experience and because the ANSI standard says so.

You seem to have made a mistake many people do: confusing Common Lisp with Scheme. Scheme is a useful language, but it's primarily a teaching language, and it's extremely limited. The simplicity of Scheme makes it useful as well as a simple base for embedded languages. However Common Lisp is far more useful as a language for developing large robust systems, because it doesn't force you to implement everything from scratch and much much more is standardized between implementations.

I don't want to be the cliché of the Lisp programmer saying "Lisp had it first", but I am amused when people find dynamic compilation new and exciting, or an integrated object system, or bemoan the lack of certification by a standards body.

Scheme/Lisp/Erlang/others. Every one of these I've looked at has one fatal flaw: It's not JIT'ed, or compiled. Erlang can be compiled, but then you lose one killer feature: even if they're just bytecode-compiled, compiled functions cannot be replaced at runtime, the way other Erlang functions can.

• CMUCL
• SBCL
• ABCL (compiles to Java bytecode)
• CLISP (compiles to bytecode)

I know that in all of these you can replace a compiled function at runtime with another compiled function, both from personal experience and because the ANSI standard says so.

You seem to have made a mistake many people do: confusing Common Lisp with Scheme. Scheme is a useful language, but it's primarily a teaching language, and it's extremely limited. The simplicity of Scheme makes it useful as well as a simple base for embedded languages. However Common Lisp is far more useful as a language for developing large robust systems, because it doesn't force you to implement everything from scratch and much much more is standardized between implementations.

I don't want to be the cliché of the Lisp programmer saying "Lisp had it first", but I am amused when people find dynamic compilation new and exciting, or an integrated object system, or bemoan the lack of certification by a standards body.

1. Lisp is interactive.

This is about the only statement you got 100% right. Lisp is interactive and it is a plus, IMO. It's nice that a drops back to a REPL when condition (execptions in Java/C++) is signaled. I can query the environment state, inspect variables, or provide restarts. But, it does not have to be.

2. Therefore, Lisp is interpreted.

Not necessarily. Most Common Lisp implementations can either interpret their code or have their code compiled.

3. Therefore, Lisp uses non-native code.

Most Common Lisp implementations can be compiled into native fast-loading files (FAS) or byte code. Some implementation can even create stand-alone executables.

4. Therefore, Lisp runs in a virtual machine.

Not really. Common Lisp run in an environment and executes either native code or byte code, depending on the implementation. CLISP is the only major Common Lisp implementation that I know of that does not compile to native code. Hey, it was good enough for Paul Graham when developing Viaweb. I was even shocked by that.

5. Therefore, Lisp is incapable of direct memory addressing or interrupt handling.

Not sure. There are some people creating Lisp operating system, it might be possible, right?

6. Therefore, Lisp can't be used to create an operating system!

Hmmm. I guess creating a Lisp machine in hardware is not enough, huh?

While there is an extensive (yet old) specification for the core language, the CLisp folks just didn't consider that standardizing a 'standard library' would be a good idea, and as a result each and every implementation features it's very own implementation of threads, networking, GUI, ... completely incompatible with the implementation next door (and sometimes within an implementation from one platform to the other).

[BTW: CLISP is just an implementation of Common Lisp, please don't confuse it with the language itself] Yes, this is a problem, but it isn't as bad as it may seem. Do we have standard threads/networking/GUI in C? C++? (POSIX doesn't count - a lot of C/C++ code is written for Win32) What about 'standard' threads/GUI in Perl? Yet these languages are quite widespread.

And the worst, I think, is that the Lisp community doesn't seem to see how some kind of standard library (as in, including the batteries in Clisp) would be useful to bring people new to the language in, or keep them there.

Not true. Look here.

Then again, actually reading comp.lang.lisp (or -- god forbid -- asking a question there) is sadly more than enough to drive you very far from trying to code in lisp ever again.

cll does indeed attract some number of strange trolls. Also, Lisp newbies in initial stages of their enlightenment do post some strange stuff sometimes. (When one begins to 'get it', things may seem much more cool than they are in reality for some time. It's important to learn the language a bit instead of inventing 'perpetuum mobiles' after learning a few nice features). But overall I was never insulted by anyone there though I did post some thoughts. And I don't think anyone will get flamed by cll old-timers unless he/she posts something implying that everyone else on the newsgroup is an idiot.

• The syntax, which you can adapt to, given a good editor with auto-indent and syntax highlight.
• The fact the standard libraries, despite providing a wealth of datastructures, are lame or non-existant for doing anything actually useful (heavy duty I/O, sockets, GUI, etc). Compare this with C, where nothing is standard per ANSI C, but there are libraries which do everything for free bundled in the OS.
• There is no really good free and multi-platform implementation. For C you have GCC. It works on basically everything you may care about (from ARM PDAs to s390 Mainframes). For Java you have Sun's JDK, which despite not really being open source, is a free (as in beer) download and allows you to develop payware without paying a dime to Sun. The following is a couple years old info, but I am guessing things have not changed much yet: Emacs LISP isn't does not compile into native binaries and is not Common LISP compatible. CLISP does not compile into native binaries and is not 100% Common LISP compatible (almost). CMUCL is buggy, used to have an incredibly lame garbage collector which made you twiddle your thumbs every 5 minutes, and a had poor user interface to boot, GCL is not Common LISP compliant by a longshot. The good tools are payola like Allegro. Contrast this with Sun Java JDK + Eclipse. There is no contest... Even Microsoft is handing out at the moment Visual C# Express for $0 which can be used for commercial use.

• The syntax, which you can adapt to, given a good editor with auto-indent and syntax highlight.
• The fact the standard libraries, despite providing a wealth of datastructures, are lame or non-existant for doing anything actually useful (heavy duty I/O, sockets, GUI, etc). Compare this with C, where nothing is standard per ANSI C, but there are libraries which do everything for free bundled in the OS.
• There is no really good free and multi-platform implementation. For C you have GCC. It works on basically everything you may care about (from ARM PDAs to s390 Mainframes). For Java you have Sun's JDK, which despite not really being open source, is a free (as in beer) download and allows you to develop payware without paying a dime to Sun. The following is a couple years old info, but I am guessing things have not changed much yet: Emacs LISP isn't does not compile into native binaries and is not Common LISP compatible. CLISP does not compile into native binaries and is not 100% Common LISP compatible (almost). CMUCL is buggy, used to have an incredibly lame garbage collector which made you twiddle your thumbs every 5 minutes, and a had poor user interface to boot, GCL is not Common LISP compliant by a longshot. The good tools are payola like Allegro. Contrast this with Sun Java JDK + Eclipse. There is no contest... Even Microsoft is handing out at the moment Visual C# Express for $0 which can be used for commercial use.

see CLISP module syscalls

By the way: CLISP is just one implementation of Common Lisp. A common abbreviation for Common Lisp is CL.

Paul Graham's book, On Lisp, is the single best book on programming I have ever read. You can get it as a PDF from his website, for free.

You will also want to read his essay, Revenge of the Nerds, for some serious insight into why Lisp is just so darn good.

If you're just starting on Lisp, the best place to start is with GNU CLISP, although you will find yourself wanting to use Emacs with SLIME to interact with your Common Lisp environment. I use SBCL, but CMUCL and CLISP are also acceptable. On my Powerbook, I use SLIME with OpenMCL.

The problem with dynamic languages, like Python, is that they can't be easily compiled to native code and optimized.

Ok, so all the highly- optimizing Common Lisp compilers are fakes?

Or maybe you have no idea what you're talking about? I'm guessing the latter.

Cliki, a wiki directory of "Links to and resources for free software implemented in Common Lisp and available on Unix-like systems."
CLOCC - the Common Lisp Open Code Collection"
common-lisp.net, providing hosting and remote repositories to dozens of Free Software Common Lisp applications.

This doesn't even touch SourceForge (which hosts another two dozen or so Lisp projects I'm aware of). When you consider how small the Lisp community is compared to the number of Perl hackers (easily in the range of 1000:1), and the number and quality of the code on just those repositories to CPAN, the productivity advantage of Lisp really does seem closer to 50x. According to your argument, all those Perl hackers should not have had any trouble in coming up with an efficient implementation by now. Yet, with less that a dozen regular hackers between them, the CMUCL and SBCL projects have produced compilers that outperform g++. At the very least, the Perl folks should not have had any trouble producing an efficient regular expression library, but here again, Lisp has them beat.

Of course, the above links point to software written in only one dialect of Lisp, Common Lisp. When you consider the software produced in other dialects, like Scheme, NewLisp, LUSH, XLISP, and Isis, the difference becomes even more apparent. To say nothing of commercial software, where none of the languages you mention can even boast a fraction of the number of large, successful systems delivered in Lisp.

Personally, I've used Macintosh Common Lisp (now from Digitool) since it was available from Apple, but I've tried Lispworks (since that's what I use on a Linux box at work), and CLISP of course. Most of the other versions, including Franz's, I've used in the past on other platforms (Sun) since I lost my beloved Symbolics box. MCL was by far the best experience under OS9 and prior, though the user interface elements haven't completely tracked the change to OS X, though I usually use CLIM anyway for code portability so we're really just talking look and feel issues. The Xanalys product is very nice, the demo is pretty unrestricted (just the continuous time to use it, and inability to dump images so you need to load up your system after you start - pretty reasonable for what you get), and the full unrestricted version isn't too expensive.

If you're just starting out and want to poke around, I'd have to recommend Xanalys personal as the best bang for the buck, since you get a pretty nice IDE with it (though Digitool's might be easier to learn if you're used to OS 9). Once you get to the point of needing to dump applications, you can either spend the money to upgrade to professional, or use one of the free lisps to dump images. Your main limitation in these alternatives will be the user interface, as that is generally unique to the implementation unless you use CLIM (and CLIM is not free) or something like Garnet, neither of which will give you something very mac-like.

Personally, I've used (now from Digitool) since it was available from Apple, but I've tried Lispworks (since that's what I use on a Linux box at work), and CLISP of course. Most of the other versions, including Franz's, I've used in the past on other platforms (Sun) since I lost my beloved box. MCL was by far the best experience under OS9 and prior, though the user interface elements haven't completely tracked the change to OS X, though I usually use CLIM anyway for code portability so we're really just talking look and feel issues. The Xanalys product is very nice, the demo is pretty unrestricted (just the continuous time to use it, and inability to dump images so you need to load up your system after you start - pretty reasonable for what you get), and the full unrestricted version isn't too expensive.

If you're just starting out and want to poke around, I'd have to recommend Xanalys personal as the best bang for the buck, since you get a pretty nice IDE with it (though Digitool's might be easier to learn if you're used to OS 9). Once you get to the point of needing to dump applications, you can either spend the money to upgrade to professional, or use one of the free lisps to dump images. Your main limitation in these alternatives will be the user interface, as that is generally unique to the implementation unless you use CLIM (and CLIM is not free) or something like Garnet, neither of which will give you something very mac-like.

As it happens, there already exists a class of languages that are strong at manipulating syntax trees, and at writing parsers. Several of them also support dynamic compilation, meaning that your language implementation can choose when to stop dicking with the syntax tree and instead compile it to native code.

One such language is Steel Bank Common Lisp. SBCL runs on a number of platforms, chiefly Linux. It is a native-code compiler -- contrary to the usual myth about Lisps, SBCL doesn't even contain a Lisp interpreter; it compiles all expressions to native machine code. If that doesn't suit, consider CMUCL, from which SBCL is derived; it includes both an interpreter and compiler.

Common Lisp is designed to be extended. You can customize the compiler by writing compiler-macros, which specify optimizations or special cases for compiled code. You can write your own parser, or extend the built-in syntax with read-macros -- so you can use a mix of built-in syntax and your own, or gradually move from the former to the latter while having a working code base at every step.

If all software was free, why would anyone bother developing it?

Gee, I can't think of anyone who would develop software without getting paid for it...

But seriously, there are several reasons people would write software whose price is 0:

• People want better software to do $WHATEVER (for values of $WHATEVER that make money, which is most of them), so they write it
• People want to get a job as a programmer so they write a software package to prove they aren't total code monkeys
• People like fame; they like being admired and appreciated
• An industry consortium decides they need an open, standard, free way to do $WHATEVER
• Some people have a political motivation to undermine proprietary software (we may not have that same motivation; but it is a real driving force for some people)
• Some people like to help others (ditto)
• Your company might want to make your product universally (or nearly so) used in order to be able to charge money for training, certification, etc.
• I mentioned 15 high-profile products that are competitive with best-of-breed and are available for $0 (and not all of it is Free as in speech). All of them were written because one of the above bullet points (or one I forgot) applied.

There are lots of motivations for people's actions besides money.

My partner on the project plans on full compilation without a C back-end, but also that it will take time, so I can't promise you guys a darned thing yet - don't hold your breath! (He's a talented guy, and great to work with, but things like this take time to develop.)

Likewise, if you use a Common Lisp script in a program that you distribute, then you make the Common Lisp interpreter a dependency, and not all programs' circumstances can accept this. Particularly, for license reasons, the BSD operating systems don't want to make a GPL'd 'clisp' interpreter a dependency.

Still, you'll like this.

Lisp community, OTOH, seems to think that only commercial implementations are worthwhile.

Twist it any way you want, one standard open source implementation would guarantee better library and tool support.

Lisp community, OTOH, seems to think that only commercial implementations are worthwhile.

Twist it any way you want, one standard open source implementation would guarantee better library and tool support.

One thing that shouldn't be missed is that object-oriented exception handling, as popularized by Java, was invented in MIT Lisp Machine Lisp. This simplified and regularized error handling tremendously, to the point where today hooks into the deepest aspects of a typical implementation of Common Lisps' debugger are reduced to about a page's worth of code to deal with stack handling. I did a little work on the CLISP backend for SLIME, and this really surprised me.

No, that's how Lithp and Thcheme programmers pronounce it.

You could complain about C all day, the problem is, it's the best thing we have right now.
Hardly.

One of the problem with modern languages is, you can't write an operating system in them.
Sure you can, with little more ASM code than is required for a C-based operating system. Heck, lots of OSs have been written in things like Lisp. Actually, C is a terrible language for writing operating systems. Because its not safe, you have to have an MMU to protect programs from each other. This sucks for performance. Not only do you have the hit of memory protection, but you have to have bounderies between userspace and kernelspace, and between programs. That's why it takes 600(!) clock cycles on my P4 to do something trivially simple like gettimeofday()! If you use a safe language, you don't need memory protection, or even a kernel/userspace boundry for that matter. You get completely fine-grained protection for all objects. See this SF project for an OS written in a safe language.

One of the problems is half the new languages are scripting perl/python like langauges and the rest compile to byte code.
I don't know what's the current fetish with VMs, but most of the really advanced languages (Lisp, ML) compile to well-optimized native code. Look at the recent comp.lang.lisp thread where they ported Almabench to CMUCL, and got within a few percent the performance of C.

Maybe C would go away if there was a compiled langauge that wasn't largely controlled by one company that produced fast code and was portable.
Common Lisp
Another Common Lisp
Ocaml
Scheme
Dylan
Another Dylan

We have lots of languages that are much more powerful than C (hell, they're much more powerful than Java/C#), safer than C, and very close in performance. It is merely a failure of programmers and the software industry that we have not been able to utilize them.

The Hotspot Java VM can optimize based on how the code is currently being used, undo an optimization if it starts slowing things down, and use processor specific instructions!

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.

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.

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.

• 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

I'm not talking about Python. Python is positioned as a scripting language, and hence doesn't have a powerful compilation infrastructure. Although, Pysco does some very cool dynamic optimizations for Python.

In contrast, there are many high-level languages like Common Lisp, Dylan, Scheme, ML, Ocaml, etc, that have very powerful native compilers. They do optimizations that C/C++ compilers simply cannot do, because of the low-level C memory model. Literally decades of research has gone into making these compilers, and they have optimizations that (while not quite magical) are very impressive.

Variously:

- There are type-inference optimizations that eliminate the overhead of dynamic dispatch.
- There are heap-analysis optimizations that stack-allocate objects whenever possible, to avoid heap allocation.
- There are analysis that avoid heap-allocating closures.
- There are analysis that eliminate type checking and array bounds checking.
- There are analysis that perform large-scale optimization of class heirarchies, to eliminate the over head of OOP.
- There are memory allocation analysis that reduce the overhead of garbage collection (region inference).
- They do method specialization, allowing the C++ template advantage of generic functions optimized for a given type, without actually having to deal with explicit type parameters.

Some useful pointers:

Apple Dylan Wiki
Lisp vs Java vs C/C++ performane
Bigloo Scheme Compiler
Gwydion Dylan compiler
CMU Common Lisp Compiler
UW Vortex Compiler
MLKit ML Compiler
Ocaml Compiler

they'd have the sense not to override the default behaviour of the damn language, which would be to go to bignum if necessary. It would take effort to write a declaration to actually deliberately override the behaviour, and would be A Seriously Stupid Thing To Do. Doesn't mean that somebody, somewhere wouldn't do it, of course

"... and of course, CL transparently uses bignums when a numeric quantity exceeds the range of machine words, so we don't get overflow problems"

* (decode-universal-time (+ (* 86400 365 50) (get-universal-time)))
debugger invoked on condition of type TYPE-ERROR:
The value 2635786389 is not of type (SIGNED-BYTE 32).

This is because I didn't specify a timezone, so it asks unix for the default timezone and DST settings, and unix needs a time_t, which is 32 bits on this box.
Dan Barlow, SBCL and the Y2038 problem

This is the fevered dream of a romantic, but I'd pay money to see a Lisp-based PDA. An actualy Lisp Processer isn't necessarily what I mean; a powerful commercial or a free and powerful Lisp interpreted for x86 (or any von Neumann) processor would be okay. What I want is for it do have a Genera-like OS that can be re-written in real-time. Man, that would rule.

Ain't gunna happen, though. Unless someone wants to pay me to write it for the PDA of their choice.

Also, it should have a Canesta projection keyboard. I saw them at siggraph, they rock!

njord, Lisp sympathizer

You mean something like this?

I'm referring to type inference the compiler optimization. The jargon seems to be confused on this issue (although it is not surprising, since both techniques basically do the same thing, albeit one is weaker).

> You are right that there is no good free
> cross-platform implementation of Common Lisp

GNU CLISP Unix, DOS, OS/2, Windows, Amiga, Acorn, Mac platforms.

From the site:


CLISP includes an interpreter, a compiler, almost all of CLOS, a foreign language interface and a socket interface. An X11 interface is available through CLX and Garnet. Command line editing is provided by readline.

CLISP runs on microcomputers (OS/2, Windows 95/98/2000/NT, Amiga 500-4000, Acorn RISC PC) as well as on Unix workstations (GNU/Linux, BSD, SVR4, Sun4, DEC Alpha OSF, HP-UX, NeXTstep, SGI, AIX, Sun3 and others) and needs only 2 MB of RAM.

CLISP is Free Software and may be distributed under the terms of GNU GPL. You may distribute commercial applications compiled with CLISP, see file COPYRIGHT in the CLISP distribution.

The user interface comes in German, English, French, Spanish, Dutch and Russian, and can be changed at run time.

No. They're copyright their various authors. It is that copyright which enables those authors to place the programs under the BSD|GPL|some other licence. CMUCL is an example of a program in the public domain: it ISN'T licenced.

I think your point could have been that ideas are free to all, or not free at all. Good point.

"the implementors choose not to be fully ANSI-compliant. You won't notice it at first, but if you get into advanced object-system hacking CLISP will become unsuitable."

"Also, it's a byte-code interpreter system. This severely affects performance (except in bignums, due to some numerical methods magic), but it does have a smaller memory footprint. And it's widely ported."

"I use libraries like AllegroServe (HTTP server)"

"You can investigate GCL or ECLS, which compile to C and may work under mingw."

"Well, most Scheme implementations aren't anywhere near the same quality as the CL ones (with a few notable exceptions) and they all have to implement incompatible supersets of the language (because R5RS defines approximately nothing)."

CLISP is a fairly well-established implementation but due to some reason I cannot fathom, the implementors choose not to be fully ANSI-compliant. You won't notice it at first, but if you get into advanced object-system hacking CLISP will become unsuitable. Also, it's a byte-code interpreter system. This severely affects performance (except in bignums, due to some numerical methods magic), but it does have a smaller memory footprint. And it's widely ported.

CMUCL does purport to be a complete ANSI-conforming implementation, and it has a high-performance native-code compiler. But it's not ported very much (some ports have gone unmaintained) and only to Unixy systems. The current maintainers are interested mostly in features and speed, whereas...

SBCL is a fork of CMUCL, with the goal of being more easily maintained, cleaner, and conforming. It's also more widely ported now, having resurrected some of the old CMUCL ports and added some new ones (someone is working on OS X now). SBCL has been adding features back that were dropped, sometimes improving, for example, kernel-threads recently (vs user-threads in CMUCL).

Lately they've been driving the development of each other, since many patches can be cross-ported easily. This is all the better for the users :-).

I use CMUCL for most of my work, which involves database-driven web-app development, and it works fine. Though I am thinking about switching to SBCL soon, with nice features like kernel-threads coming around. Well, presumably I would be able to use either. I use libraries like AllegroServe (HTTP server), UncommonSQL (RDBMS OO interface), and IMHO (web apps w/Apache).

Neither work on Windows (yet) so there you would need to look into Allegro, LispWorks, or Corman Lisp (which I forgot to list in the previous post). All these are native compilers that can produce Windows applications. There are no free compilers for Windows which produce native code, afaik. You can investigate GCL or ECLS, which compile to C and may work under mingw. The commercial compilers all have GUI toolkits or bindings to the Windows API. Allegro is probably out of your price range, LispWorks is ~$900 and Corman is ~$150. All have free personal editions to play with.

Why do I say Scheme isn't as practical? Well, most Scheme implementations aren't anywhere near the same quality as the CL ones (with a few notable exceptions) and they all have to implement incompatible supersets of the language (because R5RS defines approximately nothing). Personally I think the design of Scheme itself works against practical usage and implementation, but there are those who disagree. In universities they teach Scheme, but as I was saying, as an academic exercise and not something to be used in industry. Which is a real shame.

Anyway, if you want a learning environment, I recommend the LispWorks personal edition IDE (Linux, Windows, Unix, and soon OS X). This will get you started with a minimum of fuss. Later on, you can setup Emacs with the ILISP package and interface with your CL implementation; this is a popular way. Or you may find some other IDE. The minimum needed really is parenthesis-matching and auto-indentation. After that you might like interactive features such as shortcuts to compile code-fragments, documentation at a keystroke, easy access to a Lisp listener, inspector, debugger, etc.

There are many books, such as Paul Graham's ANSI Common Lisp, Peter Norvig's Paradigms of AI Programming, online tutorial Successful Lisp, and sites such as CLiki with lots of pointers to resources.

CMUCL
SBCL
LispWorks
Corman Lisp

Have you looked at CMUCL (Carnegie Mellon University Common Lisp)? I believe it has what you want.

> Personally, I love LISP.

Amen to that.

> If only there were good UNIX API bindings for it,
> and a good graphical toolkit...

Lisp has good UNIX API and good GUI toolkits. [PUBLIC DOMAIN LICENSE, Native compiler with kickass code-generator.]

Lisp has good UNIX API and good GUI toolkits. [Commercial, free personal use, great IDE and GUI editor, kickass code generator, database, object system, etc, etc. This is the stuff dreams are made of, best development environment I have ever had the pleasure to use.]

Lisp has good UNIX API and good GUI toolkist. [Commercial, free for personal use, relatively affordable, best GUI toolkit (native look and feel on all supported platforms.)

If that isn't enough for you. GNU Clisp runs on more platforms than a flaming wazooka. Don't be bothered by the interpreter (most Lisps are compiled btw, and NOT interpreted as legend has it.) Clisp is FASTER than the stuff you find in your /usr/bin (Python, Perl, TCL or whatnot.) Clisp has a C interface (like most other Lisps, including the ones above) which lets you link to any shared/static library which has a C interface (almost all Unix software.)

There is also Corman Lisp which is strictly Windows for now. This beast has direct access to Win32 API and COM objects.

- Kumade Khawi

> Personally, I love LISP.

Amen to that.

> If only there were good UNIX API bindings for it,
> and a good graphical toolkit...

Lisp has good UNIX API and good GUI toolkits. [PUBLIC DOMAIN LICENSE, Native compiler with kickass code-generator.]

Lisp has good UNIX API and good GUI toolkits. [Commercial, free personal use, great IDE and GUI editor, kickass code generator, database, object system, etc, etc. This is the stuff dreams are made of, best development environment I have ever had the pleasure to use.]

Lisp has good UNIX API and good GUI toolkist. [Commercial, free for personal use, relatively affordable, best GUI toolkit (native look and feel on all supported platforms.)

If that isn't enough for you. GNU Clisp runs on more platforms than a flaming wazooka. Don't be bothered by the interpreter (most Lisps are compiled btw, and NOT interpreted as legend has it.) Clisp is FASTER than the stuff you find in your /usr/bin (Python, Perl, TCL or whatnot.) Clisp has a C interface (like most other Lisps, including the ones above) which lets you link to any shared/static library which has a C interface (almost all Unix software.)

There is also Corman Lisp which is strictly Windows for now. This beast has direct access to Win32 API and COM objects.

- Kumade Khawi

> Personally, I love LISP.

Amen to that.

> If only there were good UNIX API bindings for it,
> and a good graphical toolkit...

Lisp has good UNIX API and good GUI toolkits. [PUBLIC DOMAIN LICENSE, Native compiler with kickass code-generator.]

Lisp has good UNIX API and good GUI toolkits. [Commercial, free personal use, great IDE and GUI editor, kickass code generator, database, object system, etc, etc. This is the stuff dreams are made of, best development environment I have ever had the pleasure to use.]

Lisp has good UNIX API and good GUI toolkist. [Commercial, free for personal use, relatively affordable, best GUI toolkit (native look and feel on all supported platforms.)

If that isn't enough for you. GNU Clisp runs on more platforms than a flaming wazooka. Don't be bothered by the interpreter (most Lisps are compiled btw, and NOT interpreted as legend has it.) Clisp is FASTER than the stuff you find in your /usr/bin (Python, Perl, TCL or whatnot.) Clisp has a C interface (like most other Lisps, including the ones above) which lets you link to any shared/static library which has a C interface (almost all Unix software.)

There is also Corman Lisp which is strictly Windows for now. This beast has direct access to Win32 API and COM objects.

- Kumade Khawi

> Personally, I love LISP.

Amen to that.

> If only there were good UNIX API bindings for it,
> and a good graphical toolkit...

Lisp has good UNIX API and good GUI toolkits. [PUBLIC DOMAIN LICENSE, Native compiler with kickass code-generator.]

Lisp has good UNIX API and good GUI toolkits. [Commercial, free personal use, great IDE and GUI editor, kickass code generator, database, object system, etc, etc. This is the stuff dreams are made of, best development environment I have ever had the pleasure to use.]

Lisp has good UNIX API and good GUI toolkist. [Commercial, free for personal use, relatively affordable, best GUI toolkit (native look and feel on all supported platforms.)

If that isn't enough for you. GNU Clisp runs on more platforms than a flaming wazooka. Don't be bothered by the interpreter (most Lisps are compiled btw, and NOT interpreted as legend has it.) Clisp is FASTER than the stuff you find in your /usr/bin (Python, Perl, TCL or whatnot.) Clisp has a C interface (like most other Lisps, including the ones above) which lets you link to any shared/static library which has a C interface (almost all Unix software.)

There is also Corman Lisp which is strictly Windows for now. This beast has direct access to Win32 API and COM objects.

- Kumade Khawi

When I was talking about late-bound VMs, it was largely the ideal case VM, in which all the functions and data are nicely boxed and type-checking is done at every reference. This is of course not the case, especially for Common Lisp (but from what I know of the original Smalltalk VMs and Squeak they come pretty close to the ideal - if you know someone who knows Smalltalk, it would be interesting to see how well this attack will work against the latter).

Strictly speaking, there is really no Common Lisp implementation entirely contained inside a VM (mostly for speed reasons, but Clisp does come close - it's memory footprint is less than 2mb, and I think it also makes a good candidate to see how well this exploit works against late-bound VMs). Most implementations are native-code compilers - so this exploit certainly applies here, especially since the compilers inline heavily and will make use of optional type specifiers and inference.

Besides the reliance on native code by the VM and the inlining, I think there are two areas where this exploit might work. First is the way dynamic type information is encoded. I don't think anyone uses a whole extra word for that anymore. There are two popular strategies, one being the BIBOP (Big Bag of Pages) scheme, where certain pages are reserved for specific types, and the other is to encode the type information in the upper bits of a word (Clisp does this), and I've heard that the two are used in together in some combination. Second, conservative GCs make passes fairly often - I suspect there may be a small chance to exploit the garbage collector.

So it is entirely possible to exploit late-binding VMs with your method of attack, but I am guessing the success rate will be much lower. This may depend on how much external code is used and other factors (it would be interesting to see how well Python stands up compared to the JVM). This is really starting to pique my curiosity. Maybe if I have some time this summer I will perform a similar experiment on one of the CL systems.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

Scripter, programmer what's the difference?

I too am rather confused by the distinction.
You could probably even write a macro to translate most perl scripts into C. Any takers?

The thought process is the same whether you are using cshell, java, assembler or any other programming tool.

The end result is the same, but the thought process is entirely dependent on the tools you choose to use (or someone else chooses for you). How do you compare the design processes between functional and object orientented programming? Any problem can be solved either way, but the planning processes are radically different.

This is like saying that speaking another language will make a difference in mathematics.

However, programming languages are not all necessarily mathematically equivolent. The power to generate functions on the fly is limited to only a few languages (LISP for one) can handle, and is an essential component to higher level mathematics.

Besides, your conception of mathematics is highly dependent on your primary language. In Russian, they have words that are better suited for set theory than their English translations.