Re: So confused with scheme options

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.