[Prev][Next][Index][Thread]
Re: Some inquiries about Dylan tutorials and documentation
Neel Krishnaswami wrote:
> I don't think this is the most efficient possible implementation of
> expand-template, though, since the time it takes is linear in the
> number of entries in symbol-table -- can anyone think of a better one
> off-hand, including a suggestion to use xformat?
I went through this in a different (nasty 4GL non-oop lacking even basic
data structures) language and eventually dealt with it by "chunkifying"
all templates once at startup. That way expansion became, essentially,
linear in the number of variables in each template. (I say essentially
because I implemented conditionals so that the branch not taken does not
add to expansion time, and loops where of course each iteration adds to
expansion time.)
This dramatically increased performance for longer templates by greatly
reducing the repetitive scanning of the template for variable
occurences, even completely eliminating scanning of the plain HTML
portions.
The data structure was simple:
An array of texts, odd entries containing plain HTML and even ones
containing variables (or "commands" in the little language). (With rare
empty entries to keep things in synch.) This allows the expansion to
walk down the array alternating between copying the HTML out and looking
up the variable and copying out its value (or starting a branch or
loop).
A corresponding array of ints where for any text entry that was a
command that marked the beginning of a block, the int array contained
the index of the entry that ended the block. This allows both for
directly skipping over unsatisfied conditionals without walking through
their contents looking for the close of the block, and for easy
implementation of loops by recursively calling the expand procedure on
the subset of the arrays that form the loop body.
> Plus when your template language grows into a full
> programming language (and this always happens -- witness PHP), you'll
> be in a better position to write an interpreter with comprehensible
> behavior.
Might as well plan from the start on having it happen. In my case I
think it took me well under an hour to realize that I was going to need
a dinky language rather than just text substitutions. (It's pretty
obvious. You need iteration to display a selection from a database. And
you need branching. And you need formatting options.)
In a more full-feature language like Dylan, what I'd do to the templates
would at least be a true tokenizing, probably more like a full parse.
Instead of just chunking the template into texts and variable names,
resolve variable names to as direct as possible of a reference to the
values, resolve commands to references to methods and parse their
arguments. Instead of a flat pair of arrays, a parse tree structure.
Of course, I'd try to avoid adding "eval" to my language ;-)
Follow-Ups:
References: