This is quick-n-dirty conversion of Christophe Rhodes and Eric Marsden's attempt to clean up the old comp.lang.lisp FAQ. (Last updated: 2008-09-23T22:00:56+7:00)
FLET?Copying an arbitrary structure or object needs context to determine what is the correct copy.
For instance, consider a queue data structure, most easily implemented as a pair of pointers, one pointing to the head of the queue and another to the tail
See Kent Pitman's article on the nature of equality.
This depends on your implementation; you will need to consult your vendor's documentation.
With ECL and GCL, the standard compilation process will produce a native executable.
With LispWorks, see the Delivery User's Guide section of the documentation.
With Allegro Common Lisp, see the Delivery section of the manual.
However, the classical way of interacting with Common Lisp programs does not involve standalone executables. Let's consider this during two phases of the development process: programming and delivery.
Programming phase: Common Lisp development has more of an incremental feel than is common in batch-oriented languages, where an edit-compile-link cycle is common. A CL developer will run simple tests and transient interactions with the environment at the REPL (or Read-Eval-Print-Loop, also known as the listener). Source code is saved in files, and the build/load dependencies between source files are recorded in a system-description facility such as ASDF (which plays a similar role to make in edit-compile-link systems). The system-description facility provides commands for building a system (and only recompiling files whose dependencies have changed since the last build), and for loading a system into memory.
Most Common Lisp implementations also provide a "save-world" mechanism that makes it possible to save a snapshot of the current lisp image, in a form which can later be restarted. A Common Lisp environment generally consists of a relatively small executable runtime, and a larger image file that contains the state of the lisp world. A common use of this facility is to dump a customized image containing all the build tools and libraries that are used on a given project, in order to reduce startup time. For instance, this facility is available under the name EXT:SAVE-LISP in CMUCL, SB-EXT:SAVE-LISP-AND-DIE in SBCL, EXT:SAVEINITMEM in CLISP, and CCL:SAVE-APPLICATION in OpenMCL. The
Application delivery: rather than generating a single executable
file for an application, Lisp developers generally save an image
containing their application, and deliver it to clients together with
the runtime and possibly a shell-script wrapper that invokes the
runtime with the application image. On Windows platforms this can be
hidden from the user by using a click-o-matic
FLET?This question is usually motivated by the existence of LABELS,
which is a similar form for binding functions, but also allows mutual
recursion between the functions being bound. Given this, it is perhaps
natural to question the utility of FLET.
However, there are two reasons for using flet: one idiomatic and one programmatic. The idiomatic reason is that flet can be useful to signal to the reader of the code that it is not expected that the functions will be mutually recursive; in other words, it is part of the documentation of the system, so that a subsequent programmer can see by inspection the purpose of binding the functions.
More usefully, though, flet can be useful to locally modify the behaviour of functions, for instance (a contrived example due to Kent Pitman):
(defun square (x) (* x x))
(flet ((square (x) (make-instance 'square :area (squarex)))) ...)
This is actually a subtle question; not in the respect of computing "Hello, World!", obviously, but because of what being a "Hello, World!" programme actually means.
At its simplest, you can simply type "Hello, World!" at the REPL, to find that the `P' part of that will print "Hello, World!" back to you. However, this won't do what you want if this is in a file, as return values aren't printed unless they are at the REPL.
Something which is closer to the canonical "Hello, World!" attempt is
There is no direct equivalent of COMPILE-FILE binds the special variables
*COMPILE-FILE-TRUENAME* and *COMPILE-FILE-PATHNAME*.
(defun foo () (break "Stopped inside ~S" (the-function-i-am-in)))
(setf (symbol-function 'bar) (symbol-function 'foo))
(bar)
Are you in a breakpoint in FOO or in BAR?
Most probably, one of your structure slots is called `p'. The accessor
for this slot will clash with the default predicate that defstruct
defines for your structure; so if you have (defstruct bar (p 1)
(q 2)), you could easily see (make-bar) return #S(bar :p
t :q 2).
To avoid this, use the :predicate defstruct option to eliminate or rename the predicate function, or else use a different slot name.
Generally, you don't.
IMPLODE and EXPLODE were functions in old lisps where there was no string data type, so that symbols were the only way of manipulating text. Then (explode 'foo) would give you (F O O); you could then do (implode (cdr (explode 'crash))) to give you back the symbol RASH
If you are taught today about implode/explode in a lisp programming class for anything other than historical context, complain loudly to your lecturer.
This code is probably part of the source to a lisp compiler, which knows how to open-code calls to CAR. However, the interpreter also needs to know how to call CAR, which is what the above defun is doing. This is not recommended in user code...
The charter at ftp://ftp.uu.net/usenet/control/comp/comp.lang.lisp states that the purpose of comp.lang.lisp is "Discussion about LISP". It is somewhat in the nature of things that newsgroups' purposes evolve, as do names. Firstly, the newsgroup has evolved such that the main topic of discussion is ANSI Common Lisp, though discussion about other lisp variants is welcome within reasonable bounds. Secondly, the spelling "LISP" is passé; while it does reflect the initial abbreviation, it no longer reflects the actual language, so "Lisp" is the preferred capitalization.
Questions about Scheme, Emacs Lisp and AutoLisp tend not to be terribly welcome, as they have their own fora in the comp.lang.scheme, comp.emacs and comp.cad.autocad newsgroups.
Discussion of the language defined by the ANSI Common Lisp standard is definitely on-topic on comp.lang.lisp. Unlike comp.lang.c, we do not restrict our discussions to the standard, but also actively discuss the differences between implementations and implementation-specific extensions.
Since the Lisp community is remarkably long-lived, discussion of the history and evolution of Lisp tends also to be welcomed, or at least tolerated; discussion of non-standard lisps (though generally not Scheme or Emacs Lisp) is also accepted. Though CLOS (the Common Lisp Object System) has its own newsgroup it is also part of ANSI CL, and so is a valid topic for discussion.
But of course!
However, we will need the e-mail address of your lecturer or teaching instructor to best aid you; for it is only fair that if we do the homework we should get the course credits. Alternatively, should you wish to hire a consultant from the group, competitive rates can be arranged.
Post the assignment, and your attempt so far; state explicitly that it is homework. You may find a kind soul on the group to explain some point that you are missing; this is more likely the more visible your own work is. Posts of the form "my assignment is due tomorrow please hlep!" are unlikely to engender much sympathy.