TUGboat, Volume 0 (9999), No. 0 1001

TiCL: the Prototype

Didier Verna

Abstract

While T

X is unanimously praised for its typesetting

capabilities, it is also regularly blamed for its poor

programmatic oﬀerings. Several solutions have been

proposed to modernize T

X on the programming

side. All of them currently involve a heterogeneous

approach in which T

X is mixed with a full-blown pro-

gramming language. This paper advocates another,

homogeneous approach in which the Common Lisp

language is used to implement a T

X-like typesetting

system. The underlying implementation language

serves both at the core of the program and at the

scripting level, hence removing the need for program-

matic macros on top of typesetting commands. A

prototype implementation is presented.

1 Introduction

Last year at TUG 2012, we presented some ideas

about using one of the oldest programming lan-

guages (Common Lisp [

]), in order to modernize

one of the oldest typesetting systems (T

X). The

idea behind the term “modernization” here is to re-

tain the quality of T

X’s output (the typesetting

part) while providing a more consistent and power-

ful programmatic API. This idea is not new and

has led to several attempts at mixing T

X with

a full blown programming language, such as with

eval4tex

and sT

Xme

(Scheme), PerlT

X [

]

(Perl) and QaT

X/PyT

X [3] (Python).

While these approaches to modernization are

useful for the end-user who wishes to write his own

set of macros in a more practical way, there is more

to modernization than just the programmatic API.

Another room for improvement lies in the design and

ﬂexibility (or lack thereof) of T

X’s internals. T

is an old program written in a way that doesn’t meet

today’s standards. For example, it’s full of corner

case optimization that could arguably be considered

obsolete on modern architectures, it lacks a potential

Object Oriented design that would make it easier to

extend it or even modify it, for example in order to

experiment with alternative typesetting algorithms.

Approaches such as LuaT

attempt to address

both aspects of modernization: mixing Lua with T

provides both a scripting language on the surface

layer, and access to T

X’s internals at the same time.

http://www.ccs.neu.edu/home/dorai/eval4tex/

http://stexme.sourceforge.net/

http://www.luatex.org

In our opinion, this approach still suﬀers from the

following drawbacks.

Lua is not a full-blown, industrial scale program-

ming language. It’s a scripting language with a

limited set of programming paradigms.

The resulting system is heterogeneous. It’s a

complex mixture of two diﬀerent languages pro-

viding some limited level of introspection / in-

tercession. Put diﬀerently, accessing T

X’s in-

ternals from Lua requires manual plumbing.

Even with a suﬃcient amount of introspection

/ intercession, what you end up with still is

“good ol’T

X”, with its lack of modern software

engineering concerns.

Last year at TUG 2012, we advocated the use

of Common Lisp as a better alternative for all these

aspects of “modernization”. We explained that Com-

mon Lisp is both a full-blown industrial language

suitable for a rewrite of T

X, and a scripting lan-

guage suitable as a replacement for T

X macros. We

then demonstrated the beneﬁts of this homogeneous

approach, in which a single programming language is

involved: a re-implementation of T

X with modern

software engineering in mind, in a fully reﬂexive lan-

guage such as Common Lisp, would provide a system

very convenient for extension and / or modiﬁcation

(hence experimentation). For more information, the

reader is referred to [8].

The purpose of the present paper is to apply the

ideas expressed last year in an actual prototype, in

order to assert the validity of the proposed approach.

Section 2 presents a general overview of the proto-

type. Section 3 on the next page gradually builds the

prototype’s programmatic layer, that is, the interface

that an author could use in order to actually program

a document. Section 4 on page 1005 presents an ad-

ditional layer on top of the programmatic one, called

the “textual layer”, in which plain text constitutes

the main entry, and calls to the programmatic layer

need to be escaped. Finally, section 5 on page 1006

illustrates the advantages of the proposed approach

in terms of extensibility, by enriching the prototype

with a rivers detection feature in a non-intrusive way.

The code for the prototype itself, along with all

the examples presented in this paper is available on

GitHub

2 Overview

One (obvious) conclusion from last year was that

re-implementing a complete T

X-like typesetting sys-

tem is a huge task. In particular, even for just a

https://github.com/didierverna/ticl-for-TUG2013

TiCL: the Prototype

1002 TUGboat, Volume 0 (9999), No. 0

Figure 1: TiCL current architecture

prototype with basic typesetting features and actual

output, an important question is: “where to start”.

It so happens that a Common Lisp typeset-

ting system already exists. This system, called

cl-typesetting

provides a fair amount of features,

including the obligatory paragraph and page break-

ing algorithms, and also PDF output thanks to a

back-end called

cl-pdf

, from Marc Battyani, the

same author.

cl-typesetting is very diﬀerent from T

X, in

ways that we will see later on, but nevertheless pro-

vides a convenient starting point for a T

X-like pro-

totype. We would even go as far as claiming that

it is even more interesting to start from something

completely diﬀerent from T

X, precisely because

“bending” the system towards a T

X-like engine will

illustrate the ﬂexibility of the proposed approach.

Figure 1 depicts the current architecture of the

prototype. TiCL is built on top of the existing type-

setting system in order to reuse its core algorithms

and its PDF output capabilities. Please note that

at the time of this writing, it is unclear whether

cl-typesetting

would be retained in a real prod-

uct.

The ﬁrst TiCL layer, called the “programmatic

layer”, provides a set of commands mimicking some

core L

X functionality such as

\documentclass

http://www.fractalconcept.com/asp/cl-typesetting

http://www.fractalconcept.com/asp/cl-pdf

\maketitle

, sectioning commands etc. The purpose

here is to have just enough features to be able to pro-

duce minimal documents such as basic articles. This

layer will be described in more detail in section 3.

The second TiCL layer is called the “textual

layer”. When using this layer, a document author

is provided with a text-oriented interface: the main

input at that layer is the actual text to be typeset

(this is exactly what T

X does). In order to execute

commands, one can access the programmatic layer

via an escape character (similar to category code 0

in T

X). This layer will be described in more detail

in section 4 on page 1005.

As shown in ﬁgure 1, the particularity of this

architecture is that it is possible to create a document

directly at the programmatic layer, that is, without

using the textual layer at all. The reasons why

we think this is an interesting feature, and why it

is possible at all will be explained at the end of

section 3.

3 Programmatic Layer

Listing 1 presents a typical

cl-typesetting

Hello

World program.

1 ( defun h e l l o (&key ( f i l e "/tmp/ outp ut . pd f " ) )

2 ( t t : with− document ( )

3 ( l e t ( ( c o n ten t ( t t : comp il e− tex t ( )

4 ( t t : p ar ag raph ( )

5 "Some t e x t . . . " ) ) ) )

6 ( t t : draw− pages c o n te n t )

7 (when pd f : ∗ page ∗

8 ( t t : f i n a l i z e − p a g e p df : ∗ page ∗ ) )

9 ( t t : write− document f i l e ) ) ) )

Listing 1: cl-typesetting’s Hello World

As you can see, we are quite far from the world

of T

X. The details are unimportant, but there are

a couple of interesting things to note.

•

The most important one is that in order to

create a document, you need to write an actual

Lisp program, or at least a function which does

so.

•

Everything happens within a call to a macro

called

with-document

(line 2), which bears some

resemblance with L

X’s

document

environment.

•

Lines 6 to 9 contain some boilerplate ﬁlling pages

and writing the result to a ﬁle.

•

Finally, the only textual content in this docu-

ment is provided as a Lisp string (line 5) to a

macro called paragraph.

3.1 Basic L

X functionality

The ﬁrst thing we are going to do is provide some

basic L

X-like functionality. To do that, we create

Didier Verna

TUGboat, Volume 0 (9999), No. 0 1003

some global variables for storing the title, author

etc. Following the Lisp convention, these variables

will be called

*title*

*author*

and so on. Then,

we create several functions such as

document-class

make-title

table-of-contents

etc., the purpose

of which should be obvious. Next, we provide a

with-document

macro taking care of the boilerplate

mentioned previously, and several sectioning macros,

among which

with-section

and

with-subsection

and

with-par

. Finally, just for the fun of it, we add

two functions,

textbf

and

textit

, the purpose of

which should also be obvious. With this infrastruc-

ture in place, we are able to create a basic article as

depicted in listing 2.

1 ( d ocu men t− class : a r t i c l e

2 : p aper : l e t t e r : pt 1 2)

4 ( se t q ∗ t i t l e ∗ "An A r t i c l e " )

5 ( se t q ∗ au tho r ∗ " D i d i e r Verna " )

7 ( with− document

9 ( m ak e− tit le )

10 ( t a bl e − of − co n ten t s )

12 ( w i th− s ect i o n " Lorem Ipsum "

13 ( w i th − sub s ec t ion " S i t Amet"

14 ( with− par " Lorem " ( t e x t b f " ipsum " ) " "

15 ( t e x t i t " d o l o r " ) " s i t amet , . . . " )

16 ( with− par " Lorem " ( t e x t b f " ipsum " ) " "

17 ( t e x t i t " d o l o r " ) " s i t amet , . . . " ) ) )

20 ; ; o the r s e c t i o n s . . . )

Listing 2: A basic article

Note that this document is in fact a Lisp pro-

gram. In order to generate the corresponding PDF,

you need to execute (evaluate) this program. In

Common Lisp, one can simply evaluate expressions

at the REPL (the “Read Eval Print Loop”), or store

programs in ﬁles and

load

them. By convention,

we will store this document in a ﬁle with extension

ticl

. The current prototype allows you to compile

your documents interactively at the REPL, but also

provides a standalone command-line executable for

creating foo.pdf automatically from foo.ticl.

This program is full of Lisp idioms, and of course

very far from what a casual L

X user would be

willing to type in an alternate typesetting system.

One ﬁrst, very simple improvement is to wrap global

variables access into function calls, so that we can use

(title "An Article")

instead of

(setq *title*

"An Article")

. The

title

function looks like a

getter instead of a setter, so it is not very lispy, but

that is the way L

X does it. In the remainder of

this section, we gradually move away from the Lisp

Way

and get closer the L

X one.

3.2 Lisp macros for symbolic options

The next thing we can do is to make command ar-

guments look a little better. Consider again our

equivalent to \documentclass:

(document-class :article

:paper :letter :pt 12)

This function takes one mandatory argument, and

a list of optional, named ones. Symbols of the form

:name

in Lisp are called “keywords” and are used

for naming optional arguments to functions. They

also have the property that they evaluate to them-

selves, which makes them a good choice for denoting

symbolic constants. This, however, would proba-

bly confuse a casual user. For example,

:article

is an option, but

:paper

is an option’s name, and

:letter

is its value. We can arrange this by creating

a Lisp wrapper macro on top of the

document-class

function. Lisp macros look like functions but don’t

evaluate their arguments unless you require so. This

allows us to write something like this:

(documentclass article

:paper letter :pt 12)

The

documentclass

macro will prevent the evalu-

ation of the symbols

article

and

letter

, which

would otherwise be interpreted as (unknown) vari-

able names.

3.3 Symbol macros for 0-ary functions

In Lisp,

(foo)

is a function call whereas

foo

is a vari-

able call. This syntactic diﬀerence doesn’t exists in

X, which is a macro expansion system. The actual

behavior of

\foo

simply depends on how the macro

is deﬁned. We can get closer to this idea in Lisp by

using so-called symbol macros. A symbol macro is a

symbol which behaves as a macro, that is, which ex-

pands into an arbitrary Lisp form, including function

calls. We can use this facility to deﬁne

maketitle

and

tableofcontents

as symbol macros expanding

(make-title)

and

(table-of-contents)

respec-

tively.

3.4 Less environments, less macros

Listing 2 introduced a number of

with-foo

macros, a

typical Lisp idiom. Such macros usually wrap around

a body of code, doing some pre- and post-processing

around it. This idea is actually quite close to the

concept of “environment” in L

X, but we will get

back to this later.

Even though we think that sectioning environ-

ments are a better approach (for one thing, they are

TiCL: the Prototype

1004 TUGboat, Volume 0 (9999), No. 0

more friendly to PDF), L

X only provides section-

ing commands. Replacing our

with-

macros with

regular functions is not very diﬃcult. Most of the

time, it boils down to getting rid of the macro layer

and just use its expansion directly. We hence provide

regular functions such as

(section ...)

and

(par)

and we also take the opportunity to implement a

par

symbol macro which will expand to the

(par)

function call.

At that point, we are able to rewrite our original

document generating program into a new, intermedi-

ate form, depicted in listing 3. We are getting closer

to L

X, although we’re not quite there yet.

1 ( d ocu men t cl a ss a r t i c l e : p ape r l e t t e r : pt 1 2)

3 ( t i t l e "An A r t i c l e " )

4 ( a ut ho r " D i d i e r Verna " )

6 ( with− document

8 m a k e t i t l e

9 t a b l e o f c o n t e n t s

11 ( s e c t i o n "Lorem Ipsum " )

12 ( s u b s e c t i o n " S i t Amet" )

13 "Lorem " ( t e x t b f " ipsum " ) " "

14 ( t e x t i t " d o l o r " ) " s i t amet , . . . "

15 par

16 "Lorem " ( t e x t b f " ipsum " ) " "

17 ( t e x t i t " d o l o r " ) " s i t amet , . . . "

20 ; ; o the r s e c t i o n s . . . )

Listing 3: Intermediate program state

3.5 OO hot-patching for empty lines

One very convenient syntactic trick in T

X, and one

of its rare concessions to the WYSIWYG approach,

is its treatment of empty lines as calls to

\par

. Doing

the same thing in TiCL would be nice, but is less

straightforward than what we’ve done until now,

because strings are processed by

cl-typesetting

directly. We hence need to modify it instead of just

build on top of it.

This, however, turns out to be not so diﬃcult,

which is in fact the whole point of this article. The

two key factors in making this modiﬁcation trivial

are the facts that 1.

cl-typesetting

is designed

on top of CLOS, the Common Lisp Object System

[2, 4], and that 2. Lisp is a dynamic language.

1 ( defmethod t t : : i n s e r t − s t u f f ( ( o bj s tr in g ) )

2 ‘ ( p u t− s tri n g , o bj ) )

Listing 4: A method for typesetting strings

Listing 4 shows how

cl-typesetting

handles

regular strings of text. There is a global generic

function called

insert-stuff

in charge of typeset-

ting all sorts of Lisp objects (strings, glues, boxes

etc.). This function has a diﬀerent method (in the

object-oriented sense) for every kind of typesettable

object.

As a consequence, what we need to do is simply

to override the method for strings with our own, and

also provide our own version of

put-string

, dealing

with consecutive newlines. This new function can

also reuse the original one for strings containing only

one paragraph. Needless to say, the simplicity of this

approach comes from the fact that

cl-typesetting

is an object-oriented library, and as such, our mod-

iﬁcations are localized and contained only in very

speciﬁc software components.

Another important thing here is the fact that

Lisp is a dynamic language. Consider for a minute

the equivalent problem in a language such as C++.

One would need to get the source code of the original

library, modify it, recompile it, and ship the modiﬁed

version along with the new system (in either source or

executable form). In the case of a dynamic language,

the required modiﬁcations can be done at run-time,

when the system loads-up. The original library is

not needed (not even in source form) in order to

implement the modiﬁcations to it. One just overrides

one of its components on the ﬂy, pretty much like

any T

X macro can be rewritten at any time.

At that point, we are able to rewrite our docu-

ment generating program into yet another interme-

diate form, depicted in listing 5. Note the string

starting on line 14 and ending on line 16. It contains

an implicit paragraph.

1 ( d ocu men t cl a ss a r t i c l e : p ape r l e t t e r : pt 1 2)

3 ( t i t l e "An A r t i c l e " )

4 ( a ut ho r " D i d i e r Verna " )

6 ( with− document

8 m a k e t i t l e

9 t a b l e o f c o n t e n t s

11 ( s e c t i o n "Lorem Ipsum " )

12 ( s u b s e c t i o n " S i t Amet" )

13 "Lorem " ( t e x t b f " ipsum " ) " "

14 ( t e x t i t " d o l o r " ) " s i t amet , . . .

16 Lorem " ( t e x t b f " ipsum " ) " "

17 ( t e x t i t " d o l o r " ) " s i t amet , . . . "

20 ; ; o the r s e c t i o n s . . . )

Listing 5: Another intermediate program state

Didier Verna

TUGboat, Volume 0 (9999), No. 0 1005

3.6 Syntax extension with macro-characters

The ﬁnal problem we need to address is that of the

document

environment. For technical reasons that

are too complex to explain here, it is not possible,

or at least, it would be very diﬃcult to get rid of the

macro

with-document

and replace it with commands

begin-document

and

end-document

. However,

we would still like to have something closer to L

X’s

environment syntax.

Fortunately, Lisp oﬀers a way out via syntax

extension. The syntax of Lisp code is governed by so-

called readtables. A readtable deﬁnes the syntactic

status of every character the parser can encounter.

It is possible to modify or extend the standard Lisp

syntax by providing a custom readtable. You can

then make any character syntactically “active” by

turning it into a so-called macro-character. Every

time the Lisp reader encounters such a character,

a user-provided routine (called a “reader macro”)

takes over parsing, and returns a new syntactic form

modiﬁed at will.

The resemblance of this with T

X’s notion of

category codes should be striking. We can use this

facility to solve our problem as follows: we will make

the brace characters (

{

and

}

) active, and let them

read forms such as

{begin env}

and

{end env}

Our reader macro will then read the environment’s

contents, and wrap it inside a call to the correspond-

ing

with-env

macro. Essentially, we are turning

this:

{begin env} ... {end env}

into this:

(with-env ...)

And again, note that this is done during the parsing

phase, so this really is some kind of source-to-source

transformation. One drawback of this approach is

that it makes the syntax a little bit more compli-

cated, less regular. Another slightly more intrusive

possibility is to modify the original reader macro

for the left parenthesis character, in order to recog-

nize forms like

(begin env)

and

(end env)

. This

requires modifying the Lisp engine itself with the

exact same technique, but we now know we can do

that.

At that point, we are able to rewrite our docu-

ment generating program into its ﬁnal form, depicted

in listing 6. Whether we use our speciﬁc brace syn-

tax or modify the standard parenthesis one will only

aﬀect lines 6 and 20.

If we wanted to get even closer to T

X, we could

also use the same reader technique to change the

comment character from ; (standard Lisp) to % . . .

1 ( d ocu men t cl a ss a r t i c l e : p ape r l e t t e r : pt 1 2)

3 ( t i t l e "An A r t i c l e " )

4 ( a ut ho r " D i d i e r Verna " )

6 { b e g in document } ; ; or ( b e g in document )

7 m a k e t i t l e

8 t a b l e o f c o n t e n t s

10 ( s e c t i o n "Lorem Ipsum " )

11 ( s u b s e c t i o n " S i t Amet" )

12 "Lorem " ( t e x t b f " ipsum " ) " "

13 ( t e x t i t " d o l o r " ) " s i t amet , . . .

15 Lorem " ( t e x t b f " ipsum " ) " "

16 ( t e x t i t " d o l o r " ) " s i t amet , . . . "

19 ; ; o the r s e c t i o n s . . .

20 {end document } ; ; or ( end document )

Listing 6: Final programmatic form

3.7 Wrap-up

Listing 6 is probably the closest we can get to a L

X-

looking program, while maintaining a conventional

and reasonably regular Lisp syntax. Of course, it

is doubtful that non-programmers (let alone non-

lispers) would ever want to use a system like that.

There are nevertheless some interesting points to be

made here.

First, the fact that this document really is a

program brings a lot of perspectives in terms of

automation. One can envision all sorts of typesetting

applications made easy, such as reference manual

generators or database dumpers, in which instead of

hand-typing all strings of text manually, you program

the extraction of the text to be typeset.

Next, and still because we’re in front of a Lisp

program, we can reuse the standard Lisp tool-chain

on this document. For example, generating the ac-

tual PDF is a simple matter of calling the function

load

on the document’s source ﬁle. But we can also

do more. We can also

compile

the code and even

generate a standalone executable out of it, that we

can distribute. Relate this to the idea of creating a

X document that people could actually typeset

without having to install L

X locally. . .

4 Textual Layer

Section 3 described the programmatic layer of TiCL.

In this section, we present the textual layer, that

is, the layer which an end-user would use to create

documents. In this layer, just as in T

X, text is the

main component, and access to the programmatic

layer needs to be escaped. The idea is actually quite

TiCL: the Prototype

1006 TUGboat, Volume 0 (9999), No. 0

simple and requires only a 42 lines long function in

the TiCL prototype.

•

convert

function reads a textual source ﬁle

(extension

ltic

, for “literate TiCL”) character

by character.

•

Every time a backslash is encountered, the sub-

sequent expression is read in as a piece of Lisp

code (presumably accessing the programmatic

layer). Note that we don’t have to write any

code for reading Lisp source, as Lisp itself al-

ready provides the required API.

• When the expression in question is of the form

(begin ...)

, we turn that into

(with-...

. When

it is of the form

(end ...)

, we turn that into

a closing parenthesis.

•

In any other case, the characters are accumu-

lated as Lisp strings.

That is basically it. This function allows us to rewrite

our document as depicted in listing 7.

1 \( d ocu men tcl a ss a r t i c l e : pape r l e t t e r : pt 1 2)

3 \( t i t l e "An A r t i c l e " )

4 \( aut ho r " D i d i e r Verna " )

6 \( b e gi n document )

7 \ m a k e t i t l e

8 \ t a b l e o f c o n t e n t s

10 \( s e c t i o n "Lorem Ipsum " )

11 \( s u b s e c t i o n " S i t Amet" )

12 Lorem \ ( t e x t b f " ipsum " )

13 \( t e x t i t " d o l o r " ) s i t amet , . . .

15 Lorem \ ( t e x t b f " ipsum " )

16 \( t e x t i t " d o l o r " ) s i t amet , . . .

19 %% o t her s e c t i o n s . . .

20 \( end document )

Listing 7: The textual form

Given the simplicity of the syntax, we believe

it would be easy for a casual L

X user to adapt to

this new surface. Note in particular that thanks to

symbol macros (section 3.3 on page 1003), calls like

\maketitle

look exactly the same in TiCL and in

5 Extensibility

One last thing we want to illustrate here is the

virtues of Lisp for extensibility. As an example of

this, our prototype extends the original system with

a rivers detection feature in less than 75 lines of

code. The reader interested in the technical details

may look at the example ﬁles called

rivers.ticl

rivers.ltic

in the distribution. In this article, we

only provide an outline of the implementation.

As we have already seen,

cl-typesetting

pro-

vides diﬀerent kinds of typesettable objects (strings,

glues etc.). One such kind of objects is the

vbox

(vertical box). Our idea is to provide a speciﬁc kind

of vertical box on which to perform rivers detection.

In order to do that, we deﬁne a new class of typeset-

table object called

riversbox

, which we implement

as a subclass of

cl-typesetting

’s

vbox

class (again,

we see here the importance of the OO design):

(defclass riversbox (tt::vbox) ())

Next, we implement a macro called

with-rivers

which collects all of its content and puts it inside a

fresh riversbox. This automatically makes it possi-

ble to use the corresponding

rivers

environment as

follows:

\(begin rivers)

Paragraph material...

\(end rivers)

The next thing we want to do is to draw rivers

in red in this environment (in addition to drawing

the content as usual).

cl-typesetting

draws its

material thanks to a generic function called

stroke

There is a speciﬁc method for vertical boxes that

riversboxes will automatically inherit, as they are

a subclass of vertical boxes. Hence, we don’t have

anything to do in this regard.

What we have to do is actually draw the rivers

on top of the regular text. We can plug this into the

typesetting engine easily, thanks to CLOS’s notion

of before method: methods that are called before the

primary ones, in addition to them:

(defmethod tt::stroke :before

((box riversbox) x y)

(draw-rivers box x y))

Finally, the additional function

draw-rivers

introspects the contents of the riversbox, collects the

spaces and draws red lines where appropriate in 33

lines of code.

Again, the important thing here is that this

extension is hot-plugged into the system, in a non

intrusive way, thanks to the dynamic nature of the

underlying language. In fact, in the prototype’s

distribution, this extension is not implemented in

the typesetting system, but directly in the preamble

of one of the sample documents!

6 Conclusion

Last year at TUG 2012, we presented some ideas

about using one of the oldest programming languages

(Common Lisp), in order to modernize one of the

oldest typesetting systems (T

X), the idea being to

Didier Verna

TUGboat, Volume 0 (9999), No. 0 1007

retain the quality of T

X’s output (the typesetting

part) while providing a more consistent and powerful

programmatic API.

We advocated the use of Common Lisp as a

better alternative for all aspects of modernization:

Common Lisp is both a full-blown industrial lan-

guage suitable for a rewrite of T

X, and a scripting

language suitable as a replacement for T

X macros.

The use of a single language allows to design an im-

plement a homogeneous system: a re-implementation

of T

X with modern software engineering in mind, in

a fully reﬂexive way, providing easy extension and /

or modiﬁcation capabilities (hence experimentation).

Our purpose this year was to validate the pro-

posed approach by implementing a working proto-

type, which we did. TiCL has a simple syntax making

the transition from regular T

X easy. It lets you use

the whole Lisp language for programming. It can be

accessed both at the programmatic and at the textual

layer, depending on the kind of practical application

you have in mind. Finally, it is inherently extensible,

due to the dynamic and reﬂexive nature of Lisp, as

demonstrated in section 5 on the preceding page.

We ﬁnd those results encouraging, and we deﬁ-

nitely want to continue investigating in that direc-

tion.

References

[1]

Common Lisp. American National Standard:

Programming Language. ANSI X3.226:1994

(R1999), 1994.

[2]

Daniel G. Bobrow, Linda G. DeMichiel, Richard P.

Gabriel, Sonya E. Keene, Gregor Kiczales, and

David A. Moon. Common Lisp Object System

speciﬁcation. ACM SIGPLAN Notices, 23(SI):1–142,

1988.

[3]

Jonathan Fine. T

X forever! In Proceedings

EuroT

X, pages 140–149, Pont-à-Mousson, France,

2005. DANTE e.V.

[4]

Sonya E. Keene. Object-Oriented Programming in

Common Lisp: A Programmer’s Guide to CLOS.

Addison-Wesley, 1989.

[5]

John MacCarthy. Recursive functions of symbolic

expressions and their computation by machine,

part I. Communications of the ACM, 3:184–195,

1960. Online version at

http://www-formal.

stanford.edu/jmc/recursive.html.

[6]

Andrew Mertz and William Slough. Programming

with PerlT

X. TUGboat, 28(3):354–362, 2007.

[7]

Scott Pakin. PerlT

X: Deﬁning L

X macros using

Perl. TUGboat, 25(2):150–159, 2004.

[8]

Didier Verna. Star T

X: the next generation. In

Barbara Beeton and Karl Berry, editors, TUGboat,

volume 33. T

X Users Group, 2012.

 Didier Verna

EPITA / LRDE

14-16 rue Voltaire

94276 Le Kremlin-Bicêtre Cedex

France

didier (at) lrde dot epita dot fr

http://www.lrde.epita.fr/~didier

TiCL: the Prototype