The example below is given in Paul Grahams ANSI Common Lisp as an example of doing encapsulation:
(defpackage "CTR"
(:use "COMMON-LISP")
(:export "COUNTER" "INCREMENT" "CLEAR"))
(in-package ctr)
;function definitions here
However in Peter Seibels Practical Common Lisp, link here, he says:
Because packages are used by the reader, a package must be defined
before you can LOAD or COMPILE-FILE a file that contains an IN-PACKAGE
expression switching to that package. Packages also must be defined
before other DEFPACKAGE forms can refer to them...
The best first step toward making sure packages exist when they need
to is to put all your DEFPACKAGEs in files separate from the code that
needs to be read in those packages
So he recommends creating two files for every package, one for the defpackage and one for the code. The files containing defpackages should start with (in-package "COMMON-LISP-USER").
To me it seems like putting the defpackage in the same file, before the in-package and code, is a good way to ensure that the package is defined before used. So the first method, collecting everything into one file seems easier. Are there any problems with using this method for package creation?
I think that using a separate file for defpackage is a good habit
because:
You don't « pollute » your files with defpackage.
It makes it easier to find the exported/shadowed/... symbols, you
know you just have to look at package.lisp.
You don't have to worry about the order when you use ASDF.
(defsystem :your-system
:components ((:file "package")
... the rest ...))`
Peter Seibel says so ;)
EDIT:
I forgot to mention quickproject which facilitates the creation of
new CL projects.
REPL> (quickproject:make-project "~/src/lisp/my-wonderful-project/"
:depends-on '(drakma cl-ppcre local-time))`
This command will create a directory "~/src/lisp/my-wonderful-project/"
and the following files:
package.lisp
my-wonderful-project.asd (filled)
my-wonderful-project.lisp
README.txt
And thus, I think it's good to use the same convention.
I tend to use multiple source code files, a single "packages.lisp" file and a singe "project.asd" system definition file for most of my projects. If the project requires multiple packages, they're all defined in "packages.lisp", with the relevant exports in place exported.
There is this reason for putting DEFPACKAGE in its own file: if you have a large package, then you might have several groups of related functions, and you might want to have separate source files per function group. Then all the source files would have their own IN-PACKAGE at the top, but they would all "share" the external DEFPACKAGE. Then as long as you get the DEFPACKAGE loaded first, it doesn't matter the order you load the other source files.
An example I'm currently working on has multiple classes in the package, and the source files are broken up to be per class, each having a class definition and the related generic function and method definitions.
Related
In Common Lisp with ASDF what is the difference between the define-package in uiop/package and the defpackage macro?
UIOP's one has more clauses.
https://common-lisp.net/project/asdf/uiop.html#UIOP_002fPACKAGE
define-package supports the following keywords: use, shadow, shadowing-import-from, import-from, export, intern -- as per cl:defpackage.
those are the same ones. But the rest of the docstring introduces more of them: recycle, mix, reexport…
I have used reexport which makes the following easier: you don't want to fully use package A (for example, Alexandria). You want to import a couple symbols (easy, with import-from), and you also want to export them (easy too, with export). But in doing so, you had to write the symbols twice. reexport saves duplication.
I heard some complains that defpackage would fail to reload a package in some situations, and define-package worked fine, but I didn't encounter this situation.
(edit): another difference: let's say you ":use" a package in your defpackage definition. Now you erase that line and you compile the package definition again. Your Lisp gives you a warning, telling that your package "also uses the following packages" and lists the one you removed from the definition. You removed the line, but the package still "uses" what you wanted to remove. You can check with (describe (find-package :my-package)).
Do the same with UIOP's define-package: you don't have warnings and your package doesn't "use" the one you removed from the definition anymore, as expected.
I am currently trying to wrap my head around packages, systems & co.
I now have read Packages, systems, modules, libraries - WTF? a few times, and I think I'm still having difficulties to get it right.
If I simply want to split a Lisp source file into two files, where one shall "use" the other - how do I do that? Do I need to build a system for this? Should I use a module? …? I'm coming from a Node.js background, and there you can simply say
var foo = require('./foo');
to get a reference to what's exported in file foo.js. What is the closest equivalent to this in Lisp?
I understand that ASDF is for systems, and that it is bundled as part of Quicklisp, at least according to its documentation:
ASDF comes bundled with all recent releases of active Common Lisp implementations as well as with quicklisp […]
Okay, Quicklisp is for libraries, but what is their relationship? Is Quicklisp something such as a "package manager" in other languages? And if so, then what exactly does ASDF provide?
Sorry for these many questions, but I think it just shows the trouble I have to understand how to structure Lisp applications. Any help would be greatly appreciated :-)
System
For structuring large system use a system management tool. A 'free' one is ASDF.
You would need a system declaration, which lists the parts of you library or application. Typically it goes into an own file. Then you load a system or compile a system. There should be tutorials how to do that.
A simple Lisp system might have the following files:
a system file describing the system, its parts and whatever other stuff is needed (other systems)
a package file which describes the namespaces used
a basic tools file (for examples functions used by the macro)
a macro file which lists the macros (used so that they get compiled/loaded before the rest of the software)
one or more other files with functionality.
Quicklisp is independent of that. It's a software distribution tool.
Quick hack to compile and load files
But you can also compile and load files the old fashioned way without a system tool:
(defparameter *files*
'("/yourdir/foo.lisp" "/yourdir/bar.lisp"))
(defun compile-foobar ()
(mapc #'compile-file *files*))
(defun load-foobar ()
(mapc #'load *files*))
(defun compile-and-load ()
(mapc (lambda (file)
(load (compile-file file)))
*files*))
In reality there might be more to it, but often it's enough. It should be easy to write your own building tool. A typical system tool will provide many more features for building more complex software in a structured way. Many of the ideas for these tools reach back at least 35 years. See for example the Lisp Machine manual, here the edition from 1984, chapter Maintaining Large Systems.
The role of files
Note that in plain Common Lisp the role of files and its semantics are not very complex.
A file is not a namespace, it is not associated with a class/subclass or an object, it is not a module. You mix Lisp constructs in a file like you want. Files can be arbitrary large (for example one complex library has a version where it is delivered as single source file with 30000 lines). The only real place in the standard semantics where a file plays a role is when compiling a file. What side effects has compiling a file? What optimizations can a compiler do?
Other than that it is assumed that the development environment provides services like load and compiling groups of files aka systems, provide overviews of compilation errors, record source locations of definitions, can locate definitions and more. A tool like ASDF handles the system part.
There is a require function in Common Lisp, but it deprecated. If you simply want to split your code in one or more pieces, to use it interactively in the REPL, you can put the code in different files and then load each of them. If instead you want to write a full lisp project, I have found very useful the quickproject package, that provides a simple starting point for the creation of new packages.
For example, standard libraries in C/C++ are used very often, and it's very inefficient to go to the web browser, search for the code example how to use a library component, copy the source code and modify to suit your need; a few month later, you need to use that library component again but forgot how to use it, and you have to repeat the whole process again!
This process is not very productive for me because after we learn something the first time, we do not need to fully study the same thing again; just part of it can help us recall how to use it. I want my written code or example code copied from the web site to be stored for later reference and modification.
Emacs macro is an option, but I think you have to type the whole source code to make a desired template. What if I found a well written code, and I want to store that code segment for future reference? Macro won't be productive because I have to type the whole thing.
Is there Emacs plugin for doing this?
I wouldn't recommend snippets for the task that you described.
Snippets are meant to be repeated often. You can't have a lot of them.
What you need is something that you use rarely, but can have a lot of.
I'm using org-mode for this task. With org-mode you can:
Organize your knowledge by language/library etc.
Include small code snippets directly via babel.
Attach any number of files to any heading.
This way you get the overview/description via the headings,
and the actual code via code blocks / attachments.
Another advantage is that you can easily grep your org-file / your attachments.
Other advantages are timestamps, TODOs and all kinds of export that org-mode provides.
UPD
Just to give you a sample of what it can do (open in in emacs, otherwise it looks ugly):
https://gist.github.com/abo-abo/6040382/raw/1be55e30a9ed8d81cc1b2b752b7d498d05e72978/hyper.org
There is quite a list on the EmacsWiki: Templates.
Personally I know TempoMode and Yasnippets. I prefer Yasnippets. The snippets are very easy to write and have support for variable fields which you enter on snippet insertion.
This should provide a command inserting the last item of current kill-ring.
(defun my-code ()
(interactive "*")
(insert "(defun ")
(save-excursion (insert (concat "()
(interactive \"*\")
(insert \"" (car kill-ring) "\"))"))))
Remains to specify the name of the command when done - and installing it.
In the past I have used Else-Mode to do just that sort of thing, especially when the project I was working on had a very rigid and long, required function header comments.
You can look to SRecode from CEDET package. Besides standard templates, like yasnippet, etc., it also provides support for content-aware templating, like some templates could be expanded only inside the classes, some only as top-level declaration, etc.
Following this clisp basic website tutorial it asks me to define a package to persist the code:
(defpackage :retro-games
(:use :cl :cl-who :hunchentoot :parenscript))
However, I cannot work out where my code is being persisted. Where are the files?
NB: I have only one day's experience with lisp!
Where are the files? They are where you want them.
Create a new file anywhere you want.
Put the definitions into the file.
Done
Lisp can LOAD files and you can use COMPILE-FILE.
In Common Lisp there no connections between files, the location of a file and a package. The package definition just defines a namespace to symbols. But this is not necessarily connected to a file. Some tools help maintain something called a system, which is a collection of files, which can be compiled and loaded together.
To get a basic understanding how to use Common Lisp I recommend reading Practical Common Lisp by Peter Seibel.
This is I suspect, a matter of style and/or personal taste but I thought I'd ask anyway.
I have been in the habit of defining packages thus:
(defpackage :wibble
(:use :cl :drakma)
(:export :main))
Once I have executed IN-PACKAGE (:wibble, in this case), I can then use the symbols in DRAKMA unadorned:
(http-request ...
Then I recently read that seasoned Lisp hackers would rather not :use but:
(drakma:http-request ...
Just wondered what the consensus of opinion was on here and whether there were any pros or cons (not that type of CONS :) ) either way?
Cheers,
Peter
When you use a package, there are a couple subtle ways things might go wrong if the used package changes.
First, the package might export more symbols in the future. If, for example, the package exports a new symbol library:rhombus and you're already using that myapp::rhombus to name something, you are suddenly using the inherited symbol, with all possible attachments (e.g. classes, defuns, macros, etc), with sometimes strange results. If you use qualified symbol names, you will not get any more or any less than the symbols you want.
Second, the package might stop exporting symbols in the future. So if, for example, library:with-rhombus disappears, your call to (with-rhombus (42 42 42) ...) will suddenly get an error for an invalid function call (42 ...) rather than something that points directly to the source of the problem, the "missing" symbol. If you use qualified symbol names, you will get an error along the lines of Symbol WITH-RHOMBUS is not exported from the LIBRARY package which is clearer.
Importing symbols (with :import-from or :shadowing-import-from or import) is not without its own trouble. Importing works on any symbol, regardless of whether it's external or not. So it could be the case that the symbol is now library::rhombus, i.e. not intended for public consumption any more, but importing will still work with no errors.
Which option you use depends on your comfort level with the source package. Do you control it, and you will not make any conflicting changes without thorough testing? Go ahead and import or use to your heart's content. Otherwise, be careful about checking for unintended side-effects as library package interfaces change.
This is more a style issue, so it's impossible to categorize it in black and white, but here are the pros and cons:
Using package-qualified symbols.
Avoids symbol conflicts.
Allows to clearly distinguish foreign symbols.
Allows to easily search, replace, copy,... uses of a certain symbol from the external library (for refactoring, extracting the code to some other place etc.)
Makes code uglier, but only when library names are too long. (For example, I add a nickname re to cl-pprce, and now the code using it is even better, than w/o qualification: think re:scan)
Importing the whole package
Basically, the opposite of the previous case. But I tend to use it with utility libraries, because using qualified names often beats their whole purpose of making code more concise and clear :)
:import-from package symbol
This is one option you've forgotten to mention. I think it may be useful, when you use one or too very distinct symbols from a certain package very frequently. It also allows to import unexported symbols.
Good answers so far.
Another view is that a package and its symbols make up a language. If you think a symbol should be a part of this language, then you should make it available without the need to qualify it with another package - when programming in this language.
For example in the CLIM implementation there is a CLIM-LISP package which sets up the implementation language. It is a variant of the COMMON-LISP package. Then there are packages like CLIM-SYS (resources, processes, locks, ...), CLIM-UTILS (various utilities and extensions of Common Lisp) and CLIM itself. Now in a new package SILICA (an abstract window system) these four packages are used. The implementation of Silica thus is implemented in a language which is built as a union of two languages (the Common Lisp variant CLIM-LISP and the UI commands of CLIM) plus two utility packages which extend CLIM-LISP with some facilities.
In above example it makes sense to use the packages, since they are extending each other to form a new language and the implementation in that new package makes heavy use of those.
If you had a package which needs conflicting packages, then it would not make sense to use them. For example a package could use drawing commands tailored to a GUI and for Postscript output. They would have similar names. Using them both would lead to conflicts. You also want to make clear in the source code for the human reader from where these symbols are coming. Is it a line-drawing command from a postscript or a GTK+ library? Would be great if you can find it out easily - even though the function names are the same.
As a rule of thumb, I :use packages that extend the general language, but use qualified symbols for packages that have some special application. For example, I'd always :use alexandria, but refer fully qualified to symbols from Hunchentoot. When in doubt, I use qualified names.