How to organize source files
Thomas Gagne
What is the idiom for LISP sources files? I'm playing with LispWorks (OK for
a beginner?) and am wondering,
o what goes into each file?
o how do you start a LISP program?
o how does LISP know which files it needs to read?
o does it use files at all or is it more like Smalltalk's image development?
o do packages provide a namespace?
As a test I'm trying to build a LISP interface to my open-source middleware
isectd (http://isectd.sourceforge.net/). I'm thinking the functions could
either be isd-funcname or isd:funcname. Separate question but part of the
same learning experience...
Pascal Bourguignon
> Every beginner has to go through this with every language...
>
> What is the idiom for LISP sources files? I'm playing with LispWorks
> (OK for a beginner?) and am wondering,
>
> o what goes into each file?
Whatever you want.
I usually put one package per file, and usually one class per file,
but I'm starting to feel the limits of this way I inherited from my
Modula-2/Objective-C/C++ days. In particular, I don't find it
convenient to multiply the number of packages in an application as
much (for a library, it's different).
The usual wisdom is to put the DEFPACKAGE statements in one file, the
macros in another, separate from the rest, to ease the dependencies
and usage of defsystem or asdf.
I don't feel it's good to do it as systematically. For example if you
have important macrology, your macro will depend on some of your
functions too so it won't be as simple to resolve the dependencies at
compilation and/or load time and you'll have to handle it with
EVAL-WHEN statements, etc.
So I'd advise to start with an organical division of the sources (put
together what's logically stand together), and get some experience
before starting to split and slice files.
> o how do you start a LISP program?
Lisp programs are functions. Assuming it's called P, you start it typing:
(P) RETURN
or perhaps you'll want to add some arguments, eg:
(P :display "myworkstation:0.0") RETURN
Now, if what you want is to start a lisp program from the shell
instead of starting it from the REPL, it will depend on your
implementation. Typically, something like:
#!/bin/sh
exec ${LISP} ${some_options[@]} \
${option_to_tell_it_to_load} ${PROGRAM}.lisp \
${option_to_tell_it_to_execute} '(P)'
Sometimes, you'll rather dump an image, then instead of loading the
program, you'll just have to tell it to load the image, and depending
on how the image was dumped and the posibilities of your
implementation, the program will be started automatically or you'll
add the option to tell it to execute and the function to call.
People knowing LispWorks will tell you the details for this implementation.
> o how does LISP know which files it needs to read?
YOU tell it.
Either you put LOAD (and possibly COMPILE) statements in a file and
you LOAD it when you want to load the program, or you describe the
dependencies between your source files in a system description and
invoke the system building function of your choosen system building
package: either defsystem or asdf. asdf is more recent and modern and
should probably be selected for new developments.
> o does it use files at all or is it more like Smalltalk's image development?
Given that images are implementation and _version_ dependant, and that
the Common-Lisp standard does not mandate the preservation of the
source sexp or documentation strings, we prefer to keep the sources in
files.
One could develop a development environment for lisp images where the
sources and documentation are kept in the image, something like
OpenGenera I guess, but it does not exist for free implementations and
I don't think it exists either in commercial implementations.
> o do packages provide a namespace?
Yes. But they provide only that.
> As a test I'm trying to build a LISP interface to my open-source
> middleware isectd (http://isectd.sourceforge.net/). I'm thinking the
> functions could either be isd-funcname or isd:funcname. Separate
> question but part of the same learning experience...
I'd go for: isd:funcname
Now, it depends. If you plan to keep a short name for the package and
to always use it this way, good.
But sometimes a package "X" exports an interface that could be
implemented by a different package "Y" in which case you'd want to be
able to switch package with a mere (:use "X") or (:use "Y") in the
current DEFPACKAGE, so you'd prefer to write q-funcname, which could
refer either x:q-funcname or y:q-funcname. Note that you would not
write x-funcname. Eg, I've got several package implementing sets with
various performance characteristics. bvset, bset, iset, etc. Of
course, the functions are not named bvset-intersection or
iset-intersection, but merely bvset:intersection and
iset:intersection, and they're used just as intersection, with the
adequate (:use "BVSET") or (:use "ISET"), etc, as needed in the
DEFPACKAGE of the client package.
If you use isd:funcname, you can still have it use one implementation
package or anothery, playing tricks with the nicknames, (renaming the
packages) but it's really designed for this (nicknames are _global_
attributes of the packages).
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
Peder O. Klingenberg
> I'm playing with LispWorks (OK for a beginner?)
Yes, in my opinion LispWorks in an excellent environment.
> o what goes into each file?
Whatever logically belongs together. I know that's kind of a
non-answer, but it really is up to you. There's no fixed rules like
Cs separation of header files and source files, or Javas one class per
file. It's up to you. Some people like to separate package
definitions from the implementation file(s), or put macros in separate
files.
> o how do you start a LISP program?
Usually, by invoking a function name from the REPL. Sometimes, by
invoking the lisp environment with a command line parameter (-init on
LispWorks). If/when you get to the point that you want to deliver
"standalone" executables, you specify the initial function your image
should run when started.
> o how does LISP know which files it needs to read?
You tell it. Either via basic operations like the function LOAD, or
via system definition utilities (basically the Lisp counterparts of
the classic unix utility 'make'), commonly referred to as defsystem
utilities. ASDF <http://www.cliki.net/asdf> seems to be popular these
days, but LispWorks also comes with its own defsystem
<http://www.lispworks.com/documentation/lw44/LWUG/html/lwuser-168.htm>.
> o does it use files at all or is it more like Smalltalk's image development?
I must admit that Smalltalk is still on my todo-list, so I can't
comment on its similarity to Lisp, but I use files all the time in
Lisp development.
The interface to the running Lisp image, the Read-Eval-Print-Loop, or
REPL for short, is only a keypress away in my editor, and I use it
constantly for running small utilities, testing newly written
functions, inspecting variables, etc. It's a handy database shell as
well.
However, anything less trivial than a simple function call, I type
into an editor buffer that is backed by a file. The image I talk to
on a daily basis is merely a development image. Whenever I build
anything for production use, I start a fresh image with a build script
as the value of the -init parameter.
> o do packages provide a namespace?
Yes, that is their purpose.
> I'm thinking the functions could either be isd-funcname or
> isd:funcname.
If it were me, I'd define the package ISD and put my functions there,
ie your second option above. Remember to export the symbols of your
public API.
The isd-funcname scheme looks like an attempt to use name mangling to
establish a private namespace, which is really no point, considering
that that's exactly what a package will give you.
...Peder...
--
No .sig for you.
John Thingstad
Perters book "Practical Common Lisp" explains this quite well in chapter
22:
http://www.gigamonkeys.com/book/programming-in-the-large-packages-and-symbols.html
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/