Re: So confused with scheme options

klohmuschel@xxxxxxxx wrote:

Summarize: Common Lisp is no more portable than Scheme when writing
'real world programs'. Could any Lisper clarify on this because if it
were true I could spend my xmass time doing better things (no pun
intended) than start learning Common Lisp.

I'd like to make a serious case here that Common Lisp _is_ more portable, for the following reasons:

+ ANSI Common Lisp defines a package ("module") system that allows you to separate libraries and hide their implementation details from each other. (Some argue it's badly designed, but it's there, and works well in practice even for those who don't like it.)

+ ANSI Common Lisp defines the Common Lisp Object System (CLOS), which is an object-oriented extension that allows you to further divide your libraries into subsystems that hide implementation details from each other. While the package system is very static and should only be used for compile-time separation of libraries, CLOS can be used for runtime separation - the area where traditionally module systems are used in the Scheme world. CLOS is based on generic functions, so doesn't require you to buy into the mainstream message-passing-based OOP nonsense. (One can argue that a module system would be a better fit for a Lisp/Scheme-based language, but CLOS is there, and works well in practice as soon as you forget that it's supposedly OOP and get the hang of generic functions.)

+ ANSI Common Lisp defines separation of phases into read time, compile time, macroexpansion time, load time and runtime. There are well-defined means to clearly state when your own code should be executed when. They are low-level and sometimes a bit tricky to understand, but they effectively allow you to build your own macroexpansion towers. (They are low-level in the sense that locking-based concurrency is low-level - you may wish to have nicer abstractions on top, like a good actor model, but they are there, and work well in practice if you need them. Most of the time you actually don't need them, though.)

+ Finally, there is a de-facto standard system definition facility called asdf that allows you to deliver your libraries and make it easy for users to use them and link them into your own applications. (It's definitely not perfect, but it's there, ... - you get the idea. ;)

Except for the last bullet item, all these ingredients have been part of Common Lisp since 1989, and got their final standardization in 1994. The combination of these ingredients is stable, there is stable experience and knowledge how to use them, there are common idioms and practices how to avoid their pitfalls, and there is no serious fighting about alternatives in the Common Lisp community. (There are people asking for better replacements, but all vendors support them, no vendor dares to deviate from the specified standard, to ensure standard compliance and portability.)

R6RS has only recently standardized on comparable functionality (module system, macroexpansion tower, but no delivery system yet). Different vendors have committed to different degrees to supporting R6RS, with some vendors flat-out refusing to implement certain aspects of R6RS (for what can be considered good reasons). However, these ingredients are important for ensuring portability: Just because you can write code fragments in a language doesn't mean that it's straightforward to use them in combination with other code, an exercise that in contrast doesn't cause any major headaches in Common Lisp.

So I stand by my claim, Common Lisp is a much simpler language.


My website:
Common Lisp Document Repository:
Closer to MOP & ContextL: