TUGboat, Volume 0 (9999), No. 0 draft: September 4, 2019 10:53 901

Quickref: Common Lisp reference

documentation as a stress test for Texinfo

Didier Verna

Abstract

Quickref is a global documentation project for the

Common Lisp ecosystem. It creates reference manu-

als automatically by introspecting libraries and gen-

erating corresponding documentation in Texinfo for-

mat. The Texinfo les may subsequently be con-

verted into PDF or HTML. Quickref is non-intrusive:

software developers do not have anything to do to

get their libraries documented by the system.

Quickref may be used to create a local website

documenting your current, partial, working environ-

ment, but it is also able to document the whole

Common Lisp ecosystem at once. The result is a

website containing almost two thousand reference

manuals. Quickref provides a Docker image for an

easy recreation of this website, but a public version

is also available and actively maintained.

Quickref constitutes an enormous and success-

ful stress test for Texinfo. In this paper, we give

an overview of the design and architecture of the

system, describe the challenges and diculties in

generating valid Texinfo code automatically, and put

some emphasis on the currently remaining problems

and deciencies.

1 Introduction

Lisp is a high level, general purpose, multi-paradigm

programming language created in 1958 by John Mc-

Carthy [

]. We owe to Lisp many of the programming

concepts that are still considered fundamental today

(functional programming, garbage collection, inter-

active development, etc.). Over the years, Lisp has

evolved as a family of dialects (including Scheme,

Racket, and Clojure, to name a few) rather than as a

single language. Another Lisp descendant of notable

importance is Common Lisp, a language targeting

the industry, which was standardized in 1994 [5].

The Lisp family of languages is mostly known

for two of its most prominent (and correlated) char-

acteristics: a minimalist syntax and a very high level

of expressiveness and extensibility. The root of the

latter, right from the early days, is the fact that

code and data are represented in the same way (a

property known as homoiconicity [

]). This makes

meta-programming not only possible but also trivial.

Being a Lisp, Common Lisp not only maintains this

property, but also provides an unprecedented arsenal

of paradigms making it much more expressive and

extensible than its industrial competitors such as

or Java.

Interestingly enough, the technical strengths of

the language bring serious drawbacks to its commu-

nity of programmers (a phenomenon aecting all the

dialects). These problems are known and have been

discussed many times [

]. They may explain, at

least partly, why in spite of its technical potential,

the Lisp family of languages never really took over,

and probably never will. The situation can be sum-

marized as follows: Lisp usually makes it so easy

to “hack” things away that every Lisper ends up de-

veloping his or her own solution, inevitably leading

to a paradox of choice. The result is a plethora of

solutions for every single problem that every single

programmer faces. Most of the time, these solutions

work, but they are either half-baked or targeted

to the author’s specic needs and thus not general

enough. Furthermore, it is dicult to assert their

quality, and they are usually not (well) documented.

As this situation is well known, the commu-

nity has been attempting to “consolidate” itself in

various ways. Several websites aggregate resources

related to the language or its usage (books, tuto-

rials, implementations, development environments,

applications, etc.). The Common Lisp Foundation

(

cl-foundation.org

) provides technical, sometimes

even nancial, support and infrastructure for project

authors. Once a year, the European Lisp Sympo-

sium (

european-lisp-symposium.org

) gathers the

international community, open equally to researchers

and practitioners, newcomers and experts.

From a more technical standpoint, solving the

paradox of choice, that is, deciding on ocial solu-

tions for doing this or that, is much more problem-

atic — there is no such thing as an ocial authority

in the community. On the other hand, some libraries

do impose themselves as de facto standards. Two of

them are worth mentioning here. Most non-trivial

Common Lisp packages today use ASDF for structur-

ing themselves (g.1 has an example). ASDF allows

you to dene your package architecture in terms of

source les and directories, dependencies and other

metadata. It automates the process of compiling and

loading (dependencies included). The second one is

Quicklisp (

quicklisp.org

). Quicklisp is both a cen-

tral repository for Common Lisp libraries (not unlike

CTAN) and a programmatic interface for it. With

Quicklisp, downloading, installing, compiling and

loading a specic package on your machine (again, de-

pendencies included) essentially becomes a one-liner.

One remaining problem is that of documenta-

tion. Of course, it is impossible to force a library

author to properly document his or her work. One

Quickref: Common Lisp reference documentation as a stress test for Texinfo

902 draft: September 4, 2019 10:53 TUGboat, Volume 0 (9999), No. 0

(asdf:defsystem :net.didierverna.declt

:long-name "Documentation Extractor from Common Lisp to Texinfo"

:description "A reference manual generator for Common Lisp libraries"

:author "Didier Verna"

:mailto "didier@didierverna.net"

:homepage "http://www.lrde.epita.fr/~didier/software/lisp/"

:source-control "https://github.com/didierverna/declt"

:license "BSD"

...)

Figure 1: ASDF system denition excerpt

could consider writing the manuals they miss for the

third-party libraries they use, but this never happens

in practice. There is still something that we can do to

mitigate the issue, however. Because Common Lisp

is highly reexive, it is relatively straightforward to

retrieve the information necessary to automatically

create and typeset reference manuals (as opposed to

user manuals). Several such projects exist already

(remember the paradox of choice). In this paper

we present our own, probably the most complete

Common Lisp documentation generator to date.

Enter Quickref…

2 Overview

Quickref is a global documentation project for the

Common Lisp ecosystem. It generates reference man-

uals for libraries available in Quicklisp automatically.

Quickref is non-intrusive, in the sense that software

developers do not have anything to do to get their li-

braries documented by the system: mere availability

in Quicklisp is the only requirement. In this sec-

tion, we provide a general overview of the system’s

features, design, and implementation.

2.1 Features

Quickref may be used to create a local website docu-

menting your current, partial, working environment,

but it is also able to document the whole Quicklisp

world at once, which means that almost two thousand

reference manuals are generated. Creating a local

documentation website can be done in two dierent

ways: either by using the provided Docker image

(the most convenient solution for an exhaustive web-

site), or directly via the programmatic interface, from

within a running Lisp environment (when only the

documentation for the local, partial, installation is

required). If you don’t want to run Quickref yourself,

a public website is also provided and actively main-

tained at

quickref.common-lisp.net

. It always

contains the result of a full run of the system on the

latest Quicklisp distribution.

2.2 Documentation items

Reference manuals generated by Quickref contain

information collected from various sources. First of

all, many libraries provide a README le of some

sort, which can make for a nice introductory chap-

ter. In addition to source les and dependencies,

ASDF oers ways to specify project-related metadata

in the so-called system denition form. Figure 1

illustrates this. Such information can be easily (pro-

grammatically) retrieved and used. Next, Lisp itself

has some built-in support for documentation, in the

form of so-called docstrings. As their name suggests,

docstrings are (optional) documentation strings that

may be attached to various language constructs such

as functions, variables, methods and so on. Figure 2

has an example. When available, docstrings greatly

contribute to the completeness of reference manu-

als, and again, may be retrieved programmatically

through a simple standard function call.

(defmacro @defconstant (name &body body)

"Execute BODY within a @defvr Constant.

NAME is escaped for Texinfo prior to rendering.

BODY should render on *standard-output*."

`(@defvr "Constant" ,name ,@body))

Figure 2: Common Lisp docstring example

As for the rest, the solution is less straightfor-

ward. We want our reference manuals to advertise

as many software components as possible (functions,

variables, classes, packages, etc.). In general there

are two main strategies for collecting this informa-

tion.

Code walking.

The rst one, known as code walk-

ing, consists of statically analyzing the source code.

A code walker is usually at least as complicated as

the syntax of the target language, because it requires

a parser for it. Because of Lisp’s minimalist syn-

tax, using a code walker is a very tempting solution.

On the other hand, Lisp is extremely dynamic in

nature, meaning that many of the nal program’s

components may not be directly visible in the source

Didier Verna

TUGboat, Volume 0 (9999), No. 0 draft: September 4, 2019 10:53 903

Quicklisp

foo/

Declt

foo.texi

Makeinfo

foo.html

Figure 3: Quickref pipeline ( Main thread, External Process)

code. On top of that, programs making syntactic

extensions to the language would not be directly

parsable. In short, it is practically impossible to

collect all the required information by code walking

alone. Therefore, we do not use that approach.

Introspection.

Our preferred approach is by in-

trospection. Here, the idea is to actually compile

and load the libraries, and then collect the relevant

information by inspecting memory. As mentioned

before, the high level of reexivity of Lisp makes

introspection rather straightforward. This approach

is not without its own drawbacks however. First,

actually compiling and loading the libraries requires

that all the necessary (possibly foreign) components

and dependencies are available. This can turn out

to be quite heavy, especially when the two thou-

sand or so Quicklisp libraries are involved. Secondly,

some libraries have platform, system, compiler, or

conguration-specic components that may or may

not be compiled and loaded, depending on the exact

conditions. If such a component is skipped by our

system, we won’t see it and hence we won’t docu-

ment it. We think that the simplicity of the approach

by introspection greatly compensates for the risk of

missing a software component here and there. That

is why introspection is our preferred approach.

2.3 Toolchain

Figure 3 depicts the typical manual production pipe-

line used by Quickref, for a library named foo.

Quicklisp is used rst, to make sure the library

is installed, which results in the presence of a

local directory for that library.

Declt (

lrde.epita.fr/~didier/software/

lisp/misc.php#declt

) is then run on that li-

brary to generate the documentation. Declt is

another library of ours, written ve years before

Quickref, but with that kind of application in

mind right from the start. In particular, it is for

that reason that the documentation generated

by Declt is in Texinfo intermediate format.

The Texinfo le is processed into HTML. Tex-

info (

gnu.org/software/texinfo

) is the GNU

ocial documentation format. There are three

main reasons why this format was chosen when

Declt was originally written. First, it is partic-

ularly well suited to technical documentation.

More importantly, it is designed as an abstract,

intermediate format from which human-readable

documentation can in turn be generated in many

dierent forms (notably PDF and HTML). Fi-

nally, it includes very convenient built-in anchor-

ing, cross-referencing, and indexing capabilities.

Quickref essentially runs this pipeline on the

required libraries. Some important remarks need to

be made about this process.

Because Declt works by introspection, it would

be unreasonable to load almost two thousand

libraries in a single Lisp image. For that reason,

Quickref doesn’t actually run Declt directly, but

instead forks it as an external process.

Similarly,

makeinfo

(

texi2any

in fact), the pro-

gram used to convert the Texinfo les to HTML,

is an external program written in Perl (with

some parts in C), not a Lisp library. Thus, here

again, we fork a

makeinfo

process out of the

Quickref Lisp instance in order to run it.

2.4 Performance

Experimental studies have been conducted on the

performance of the system. There are dierent sce-

narios in which Quickref may run, depending on

the exact number of libraries involved, their current

state, and the level of required “isolation” between

them. All the details are provided in [

], but in short,

there is a compromise to be made between the execu-

tion time and the reliability of the result. We found

that for a complete sequential run of the system on

the totality of Quicklisp, the most frequent scenario

takes around two hours on our test machine, whereas

the safest one requires around seven hours.

In order to improve the situation, we recently

added support for parallelism to the system. The

upgraded architecture is depicted in Figure 4. In

this new processing scheme, an adjustable number

of threads is devoted to generating the Texinfo les

in parallel. In a second stage, a likewise adjustable

number of threads is in charge of taking the Texinfo

les as they come, and creating the corresponding

HTML versions. A specic scheduling algorithm (not

unlike that of the

make

program) delivers libraries in

an order, and at a time suitable to parallel processing

by the Declt threads, avoiding any concurrency prob-

lems. With this new architecture in place, we were

able to cut the processing time by a factor of four,

reducing the worst case scenario to 1h45 and the

most frequent one to half an hour. These numbers

Quickref: Common Lisp reference documentation as a stress test for Texinfo

904 draft: September 4, 2019 10:53 TUGboat, Volume 0 (9999), No. 0

Library Pool

Declt

Texinfo les Makeinfo

Makeinfo

HTML les

Figure 4: Quickref parallel processing ( Declt thread, Makeinfo thread)

make it reasonable to run Quickref on one’s local

machine again.

3 Challenges

Quickref is a challenging project in many regards.

Two thousand libraries is a lot to process. Setting up

the environment necessary to properly compile and

run those libraries is not trivial, especially because

many of them have platform or system-specic code

and require foreign dependencies. Finally, Quickref

constitutes a considerable (and successful) stress test

for Texinfo. The Texinfo le sizes range from 7KB

to 15MB (double that for the generated HTML ones).

The number of lines of Texinfo code in those les

extends from 364 to

285 020

, the indexes may contain

between 14 and

44 500

entries, and the processing

times vary from 0.3s to 1m 38s per le.

Challenges related to the project scalability and

performance have been described previously [

]. This

section focuses on more general or typesetting/Tex-

info issues.

3.1 Metadata format underspecication

One diculty in collecting metadata is that their

format is often underspecied, or not specied at all,

as is the case with ASDF system items. To give just

one example, Figure 5 lists several of the possible

values we found for the author metadata. As you can

see, most programmers use strings, but the actual

contents vary greatly (single or multiple names, email

addresses, middle letter, nicknames, etc.), and so

does the formatting. For the anecdote, we found

one attempt at pretty printing the contents of the

string with a history of authors, and one developer

even went as far as concealing his email address by

inserting Lisp code into the string itself…

It would be unreasonable to even try to under-

stand all these formats (what others will we discover

in the future?), so we remain somewhat strict in

what we recognize — in this particular case, strings

either in the form

"author"

"author <email>"

(as in either:

"Didier Verna"

"Didier Verna <didier@lrde.epita.fr>"

respectively), or a list of these. The Declt user man-

ual has a Guidelines section with some advice for

library authors that would like to be friendlier with

our tool. We cannot force anyone to honor our guide-

lines however.

"Didier Verna"

"Didier Verna <didier@lrde.epita.fr>"

"Didier Verna didier@lrde.epita.fr"

"didier@lrde.epita.fr"

"<didier@lrde.epita.fr>"

"Didier Verna and Antoine Martin"

"Didier Verna, Antoine Martin"

"Didier Verna Antoine Martin"

"D. Verna Antoine E Martin"

"D. Verna Antoine \"Joe Cool\" Martin"

("Didier Verna" "Antoine Martin")

Original Authors:

Salvi Péter,

Naganuma Shigeta,

Tada Masashi,

Abe Yusuke,

Jianshi Huang,

Fujii Ryo,

Abe Seika,

Kuroda Hisao

Author Post MSI CLML Contribution:

Mike Maul <maul.mike@gmail.com>"

"(let ((n \"Christoph-Simon Senjak\"))

(format nil \"~A <~C~C~C~C~A>\"

n (elt n 0) (elt n 10) (elt n 16)

#\\@ \"uxul.de\"))"

Figure 5: ASDF author metadata variations

On the other hand, Quickref has an interesting

social eect that we particularly noticed the rst

time the public website was released. In general,

people don’t like our documentation for their work

to look bad, especially when it is publicly available.

In the rst few days following the initial release and

announcement of Quickref, we literally got dozens of

reports related to typesetting glitches. Programmers

rushed to the website in order to see what their

library looked like. If the bugs were not on our side,

many of the concerned authors were hence willing

Didier Verna

TUGboat, Volume 0 (9999), No. 0 draft: September 4, 2019 10:53 905

to slightly bend their own coding style, in order for

our documentation to look better. We still count on

that social eect.

3.2 Denitions grouping

Rather than just providing a somewhat boring list

of functions, variables, and other denitions, as ref-

erence manuals do, Declt attempts to improve the

presentation in dierent ways. In particular, it tries

to group related denitions together when possible.

A typical example of this is when we need to

document accessors (readers and writers to the same

information). It makes sense to group these deni-

tions together, provided that their respective doc-

strings are either nonexistent, or exactly the same

(this is one of the incentives given to library authors

in the Declt guidelines). This is exemplied in Fig-

ure 6. Another typical example consists in listing

methods (in the object-oriented sense) within the

corresponding generic function’s entry.

context-hyperlinksp CONTEXT [Function]

(setf context-hyperlinksp) BOOL CONTEXT [Function]

Access CONTEXT’s hyperlinksp ag.

Package [net.didierverna.declt], page 29,

Source [doc.lisp], page 24, (le)

Figure 6: Accessors denitions grouping

Texinfo provides convenient macros for den-

ing usual programming language constructs (

@defun

@defvar

, etc.), and “extended” versions for adding

sub-denitions (

@defunx

@defvarx

, etc.). Unfortu-

nately, denitions grouping prevents us from using

them, for several reasons.

Nesting

@def...

calls would lead to undesirable

indentation.

Heterogeneous nesting is prohibited. For exam-

ple, it is not possible use

@defvarx

within a call

@defun

(surprising as it may sound, this kind

of heterogeneous grouping makes sense in Lisp).

On the other hand, that kind of thing is possible

with the lower-level (more generic) macros, as hetero-

geneous categories become simple macro arguments.

One can, for example use the following (which we

frequently do):

@deffn {Function} ...

@deffnx {Compiler Macro} ...

...

@end deffn

This is why we stick to those lower-level macros, at

the expense of re-inventing some of the higher-level

built-in functionality.

Even with this workaround, some remaining

limitations still get in our way.

There are only nine canonical categories and it

is not possible to add new ones (at least not

without hacking Texinfo’s internals).

Although we understand the technical reasons

for it (parsing problems, probably), some of the

canonical categories are arguable. For example,

the distinction between typed and untyped func-

tions makes little sense in Common Lisp which

has optional static typing. We would prefer

to have a single function denition entry point

handling optional types.

Heterogeneous mixing of the lower-level macros

is still prohibited. For example, it remains im-

possible to write the following (still making sense

in Lisp):

@deffn {Function} ...

@defvrx {Symbol Macro} ...

...

@end deffn

3.3 Pretty printing

Pretty printing is probably the biggest challenge

in typesetting Lisp code, because of the language’s

exibility. In particular, it is very dicult to nd

the right balance between readability and precision.

Identiers.

In Lisp, identiers can be basically

anything. When identiers contain characters that

are normally not usable (e.g. blanks or parentheses),

the identier must be escaped with pipes. In order

to improve the display of such identiers, we use

several heuristics.

•

A symbol containing blank characters is nor-

mally escaped like this:

|my identifier|

. Be-

cause the escaping syntax doesn’t look very nice

in documentation, we replace blank characters

with more explicit Unicode ones, for instance

my identifier

. We call this technique “reveal-

ing”. Of course, if one identier happens to

contain one of our revealing characters already,

the typesetting will be ambiguous. This case is

essentially nonexistent in practice, however.

•

On the other hand, in some situations it is better

to not reveal the blank characters. The so-called

setf (setter / writer) functions are such an ex-

ample. Here, the identier is in fact composed

of several symbols, such as in

(setf this)

. Re-

vealing the whitespace character would only clut-

ter the output, so we leave it alone.

•

Finally, some unusual identiers that are nor-

mally escaped in Lisp, such as

|argument(s)|

Quickref: Common Lisp reference documentation as a stress test for Texinfo

906 draft: September 4, 2019 10:53 TUGboat, Volume 0 (9999), No. 0

do not pose any readability problems in docu-

mentation, so we just typeset them without the

escaping syntax.

Qualication.

Another issue is symbol qualica-

tion. With one exception, symbols in Lisp belong

to a package (more or less the equivalent of a name-

space). Many Lispers use Java-style package names,

which can end up being quite long. Typesetting a

fully qualied symbol would give something like this:

my.long.package.name:symbol

. Lisp libraries usu-

ally come with their own very few packages, so type-

setting a reference manual with thousands of symbols

fully qualied with the same package name would

look pretty bad. Because of that, we avoid typeset-

ting the package names in general. Unfortunately, if

dierent packages contain eponymous symbols, this

leads to confusing output. Currently, we don’t have

a satisfactory answer to this problem.

Docstrings.

The question of how to typeset doc-

strings is also not trivial. People tend to use varying

degrees of plain-text formatting in them, with all

kinds of line lengths, etc. Currently, we use only a

very basic heuristic to determine whether an end of

line in a docstring is really wanted here, or just a con-

sequence of reaching the “right margin”. We are also

considering providing an option to simply display

the docstrings verbatim. In the long term, we plan

to support markup languages such as Markdown.

References.

A Texinfo-related problem we have

is that links are displayed dierently, depending on

the output format, and with some rather undesirable

DWIM behavior. Table 1 shows the output of a

call to

@ref{anchor, , label}

in various formats

(

anchor

is the link’s internal name,

label

is the

desired output).

Table 1

: Texinfo links formatting in various output

formats

HTML label

PDF [label], page 12,

Info *note label: anchor.

Emacs Info mode See label.

In PDF, the presence of the trailing comma

is context dependent. In Info, both the label and

the actual anchor name are typeset, which is very

problematic for us (see Section 3.4). In Emacs Info

mode, the casing of “See” seems to vary. In general,

we would prefer to have more consistent output across

the dierent formats, or at least, more control over it.

3.4 Anchoring

The nal Texinfo challenge we want to address here

is that of anchoring. In Texinfo, anchor names have

severe limitations: dots, commas, colons, and paren-

theses are explicitly forbidden (due to the nal dis-

play syntax in Info). This is very unfortunate be-

cause those characters are extremely common in Lisp

(parentheses of course, but also dots and colons in

the package qualication syntax).

Note that formats other than Info are not af-

fected by this problem. There is an Info-specic

workaround documented in Appendix G.1 of the

Texinfo user manual. In short, a suciently recent

version can automatically “protect” problematic node

names by surrounding them with a special marker in

the resulting Info les. Unfortunately, neither older

Info readers, nor the current Emacs mode are aware

of this feature. Besides, the latest stable release of

Texinfo still has problems with it (menus do not work

correctly). Consequently, this workaround is not a

viable solution for us (yet).

Our original (and still current) solution is to

replace those characters by a sequence such as

<dot>

Of course, this makes anchor names particularly ugly,

but we didn’t think that was a problem because we

have nicer labels to point to them in the output (in

fact, labels have a less limited syntax, although this

is not well documented). However, we later realized

that anchor names still appear in the HTML output

and also in pure Info. Consequently, we are now

considering changing our escaping policy, perhaps by

using Unicode characters as replacements, just as we

already do on identiers (see Section 3.3).

The second anchoring problem we have is that

of Texinfo nodes, the fundamental document struc-

turing construct. In addition to the aforementioned

restrictions related to anchoring, nodes have two very

strong limitations: their names must be unique and

there is no control over the way they are displayed in

the output. This is a serious problem for us because

Lisp has a lot of dierent namespaces. A symbol

may refer to a variable, a function, a class, and

many other things at the same time. Consequently,

when nodes are associated with Lisp symbols, we

need to mangle their names in a way that makes

them barely human readable. Because of that, our

use of nodes remains rather limited, which is some-

what paradoxical, given the importance of nodes in

Texinfo. Apart from general, high level sectioning,

the only nodes associated with Lisp symbols are for

ASDF components and packages, probably already

a bit too much. It is our hope that one day, the

node names uniqueness constraint in Texinfo might

be relaxed, perhaps disambiguating by using their

hierarchical organization.

Didier Verna

TUGboat, Volume 0 (9999), No. 0 draft: September 4, 2019 10:53 907

4 Conclusion and perspectives

Although a relatively young project, Quickref is al-

ready quite successful. It is able to document almost

two thousand Common Lisp libraries without any

showstoppers. Less than 2% of the Quicklisp libraries

still pose problems and some of the related bugs have

already been identied. The Common Lisp commu-

nity seems generally grateful for this project.

Quickref also constitutes an enormous, and suc-

cessful, stress test for Texinfo. Given the gures

involved, it was not obvious how

makeinfo

would

handle the workload, but it turned out to be very

reliable and scalable. Although the design of Texinfo

sometimes gets in our way, we still consider it a good

choice for this project, in particular given the diver-

sity of its output formats and its built-in indexing

capabilities.

In addition to solving the problems described

in this paper, the project also has much room for

improvement left. In particular, the following are at

the top level of our TODO list.

The casing problem needs to be addressed. Tra-

ditional Lisp is case-insensitive but internally

upcases every symbol name (except for escaped

ones). Several modern Lisps oer alternative

policies with respect to casing. Quickref doesn’t

currently address casing problems at all (not

even that of escaped symbols).

Our indexing policy could be improved. Cur-

rently, we only use the built-in Texinfo indexes

(Functions, Variables, etc.) but we also provide

one level of sub-indexing. For instance, macros

appear in the function index, but they are listed

twice: once as top level entries, and once under

a Macro sub-category. The question of which

amount of sub-indexing we want, and whether

to create and use new kinds of indexes is under

consideration.

Although our reference manuals are already

stued with cross-references, we plan to add

more. Because Declt was originally designed to

generate one reference manual at a time, only

internal cross-references are available. The exis-

tence of Quickref now raises the need for exter-

nal cross-references (that is, between dierent

manuals).

Many aspects of the pretty printing could be

improved, notably that of so-called “unreadable”

objects and lambda lists.

In addition to HTML, we plan to provide PDF

as well as Info les on the website, since they

are readily available.

We intend to integrate Quickref with Emacs

and Slime (a de facto standard Emacs-based

development environment for Common Lisp).

In particular, we want to give Emacs the abil-

ity to browse the Info reference manuals online

or locally if possible, and provide Slime with

commands for opening the Quickref documenta-

tion directly from Lisp source code displayed in

Emacs buers.

Finally, we are working on providing new in-

dex pages for the website. Currently, we have a

library index and an author index. We are work-

ing on providing keyword and category indexes

as well.

References

[1]

A. C. Kay. The Reactive Engine. PhD thesis,

University of Utah, 1969.

[2]

J. McCarthy. Recursive functions of symbolic

expressions and their computation by

machine, part I. Communications of the ACM

3(4):184–195, Apr. 1960.

doi:10.1145/367177.367199

[3]

M. D. McIlroy. Macro instruction extensions

of compiler languages. Communications of

the ACM 3:214–220, Apr. 1960.

doi:10.1145/367177.367223

[4]

M. Tarver. The bipolar Lisp programmer.

marktarver.com/bipolar.html, 2007.

[5]

Ansi. American National Standard:

Programming Language — Common Lisp.

ANSI X3.226:1994 (R1999), 1994.

[6]

D. Verna. Parallelizing Quickref.

In 12th European Lisp Symposium, pp.

89–96, Genova, Italy, Apr. 2019.

doi:10.5281/zenodo.2632534

[7]

R. Winestock. The Lisp curse, Apr. 2011.

winestockwebdesign.com/Essays/Lisp_

Curse.html

 Didier Verna

14-16 rue Voltaire

94276 Le Kremlin-Bicêtre

France

didier (at) lrde dot epita dot fr

http://www.didierverna.info

Quickref: Common Lisp reference documentation as a stress test for Texinfo