Template and Macro processing

This page discusses two concepts which are only loosely (if at all) related in other languages, but due to EIAS in Tcl they overlap.

EIAS also makes such tools easy to create and very powerful, so a great many have been published.

Syntactic macros

Akin to Lisp macros, these allow the programmer to extend the language with more syntax.

Some of these use Tcl to extend other languages (such as C) .. they should probably be listed separately:

Sugar, by SS
a Lisp-like macro system for Tcl.
knit, by PYK
a macro system that leverages tailcall
Peter Spjuth's Chiselapp
includes "an experminent on compiled macros" with a very small core mod (original patch submission @ sourceforge ). This is interesting for the very simplicity of the approach
Macro Facility for Tcl
a discussion that includes some ideas and examples from RS, jcw, and others
Tmac, by Roy Terry
a general-purpose macro package for expanding and substituting Tcl code.
a C-preprocessor-like macro substitution mechanism for Tcl source code.
A CPP-like preprocessor.
FrontLine, by Koen Van Damme
the author has used Frontline to write a preprocessor based upon Tcl to get more power than provided by the C/C++ preprocessor.
A tool for programmatically generating embedded content within a file, similar to C/C++ preprocessor directives, except that the embedded code is expressed in Tcl.
A drop-in replacement for proc that includes a pre-evaluation hook for each command in the body of the procedure. The result of evaluating the hook is the the command actually evaluated in the procedure.
ycl string expand
A small-but-complete system that provides a concise syntax for streamlining boilerplate code in Tcl scripts. In contrast with textutil::expand, this system iteratively scans the expanded result for further expansions until no more are found. See ycl coro event for an example that uses [$ ... $].

Template systems

Familar to most programmers, template systems are a way to write documents with inline code, or tokens that cause code to run. The canonical template system for Tcl is subst. Some of these simply add more convenient syntax on top of subst, while others are specialised to generating particular kinds of content (such as html).

expand, by William Duquette
A dedicated T/M processor. The core of expand was added to tcllib/textutil.
Subst template expansion helpers
Percent Substitution
Templates and subst
presents substify and applytemplate.
scripted templates
where the template itself is a syntactically valid Tcl script
teaspoon, by xan
a PHP-like templating engine for Tcl, and works particularly well with tanzer
has just two tags, ASP-like, easily expandable, and relatively safe, as it runs in a safe interpreter.
based on a popular Javascript library
based on a popular Javascript library
Web Templating
Open Liquid
is a parsing and rendering engine for the Liquid Markup Language, written in C++ with the goal of being bindable to any scripting language interpreter. Currently, only Tcl is supported through the Tcl C API.
A partial Tcl implementation of the TemplateToolkit :
Django/Jinja/Liquid-style templates in pure Tcl.

Frameworks including Template systems

These pages are more loosely related, often including a template system as a part of a larger project:

not just a game - it is a templating system as well!
TclHttpd, by Brent Welch
a web server that includes a template processor
Kinetic Application Processor, by AsiaInfo
a web server that includes a template processor
Text Clipboard
Tml a component of BrowseX
a template processing system for both dynamic and static content.
Apache Rivet
the successor to mod_dtcl. rivet::parse can be used to create macros
the OpenACS templating system

See Also

Discussions relevant to the above topics, and things that don't quite fit.

Code Generation
emacs package to insert templated code interactively
Tcl Quoting


aspect 2015-11-09: I've tried to rearrange this page to make the important distinction between syntactic macros and textual template systems. While it can be argued that in Tcl they are different sides the same thing, they support quite different goals and specialise in different directions. I found version 51 of this page drew them too close together, and confused things even further with the enormous "See Also" section at the top.

Some of the links could be further categorised into implementations and conceptual discussions. Some of the older stuff and aborted discussions could be beneficially deleted. Most things could be better described. Please dive in and edit where you see an opportunity.