[ There now follows a scratch area for braindump/work-in-progress: if you have feedback (which is welcome) please add comments at the end or using italics to distinguish them from the original text, so that I can easily tell what they are ]
The ANSI standard. Install the Hyperspec or our yet-to-be-written free equivalent, and get used to finding your way around it.
CLTL2 is _not_ a reference document and doesn't describe ANSI CL. By all means use it as an aid to learning, but don't try appealing to its authority, because it has none.
Historically on Unix the user interface was the shell command line. More recently, it has become common if not usual to add a graphical interface to programs.
In cirCLe we don't care too much about the unix shell command line: instead of doing our work in 'sh' or 'bash', we interact with the Lisp environment at the repl. So, don't think in terms of writing a "standalone program" that takes "command line arguments": instead, write a Lisp function (or a package full of them) that takes parameters and returns values.
As for graphical user interfaces: it's nice to have a well-designed user interface, but if the job that your software does is reasonably general, people will find ways they want to use it that you can't anticipate: if you provide a well-designed API, they can add new features and new ways of controlling it themselves, instead of needing you to do it for them. At this point in the life of cirCLe, API is more important than UI
More advice needed here on what to do if you do want a GUI, but someone with CLIM experience should write it
Where the standard offers a reasonable way to do something, do it that way instead of using an unportable alternative. For example, you should usually prefer using pathnames over namestrings.
Where there is a widely-accepted extension to the standard (such as Gray Streams, the MOP, or Series) that does what you need, and it is available for cirCLe, use that in preference to writing your own.
Where you need functionality that differs between Lisp implementations for which there is no good de-facto standard (such as network socket support or threads), cirCLe is not itself particularly interested in portability: if you must run on more than one platform, please feel free to introduce a portability layer, but it's not a priority for us. Provided that your code is cleanly factored, it should be easy for users of other Lisps to make the necessary changes for their environment and send you back the patches, so there is little point (for cirCLe; you might have different priorities) in doing the porting upfront when you could instead be adding functionality. However, we recommend against using feature conditionals (#+ and #- clauses) in the main body of the code itself, as this rapidly becomes unmaintainable and often gets out of sync with reality when new versions of Lisp implementations are released. See http://www-jcsu.jesus.cam.ac.uk/~csr21/papers/features.pdf for more on this subject.
This page is linked from: cirCLe
CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively