[Zope-dev] Conditionals in XML

[Don Hopkins]

Jeffrey P Shell writes:
> You would at the very least need something like:
> <condition>
>  <if>...</if>
>  <elif>...</elif>
>  <else>...</else>
> </condition>
>
> Which would ensure / cut back on needless growth of stacks and/or global
> variables.
>
> Personally, I think the way Page Templates can do it (via a 'not'
> expression) is fine.  When I used it today (and in the past), I never felt
> myself missing 'else', because there's not really an 'if' to begin with.
> Just conditions.  It keeps TAL light, and lets TALES take on the lifting
of
> how to write those conditions.


I've been banging my head against the problem of how to elegantly express
"if/else/ifelse" structures in xml, so this is an interesting discussion!
Any easy sleazy solution (like dtml's approach) that breaks XML syntax or
structure is right out, so it requires a different approach.

I like Jeffrey's idea:
The condition comes first (outside), and the if and else that use it are
nested inside:

<condition expr="...">
  <if> ... </if>
  <elif> [I'm not sure how this clause works: where does its condition go?]
</elif>
  <else> ... </else>
</condition>

It reads easily (with the condition obviously first and up top), and blocks
the code off nicely.
The elif I'm not so clear on. It might have its own expr="..." (or
whatever), which would break the symmetry and imply that "if" could also
contain a conditional expression.

I haven't used TAL yet, so I'm not really qualified to judge. But I'm not
really happy with the attribute based approach.
I'd rather use an XML based macro language with the full capabilities of
Lisp macros (just bound to the Python runtime instead of a Lisp system).
I think Python is a great implementation language for other higher level XML
based languages, like ZPT and others.

I don't like the idea of purposefully crippling a language in the misguided
quest to "separate presentation and logic".
If you have a good enough XML based language, you can use it to express both
presentation and logic, and you can cleanly and easily separate presentation
and logic because you have the power of abstraction, not because you're
forced to.

Any extra incompatible language syntax you're forced to use just add
friction and confusion and interoperability problems. Don't add another
layer unless you have to.
Don't force programmers to drop down into Python because the templating
language is too weak (nothing against Python, but I'm talking about
implementing a higher level language that is more powerful, not purposefully
weaker).
Templates should be structural transformation macros, not string
substitution.
Macros require a full powered programming language, or else they're a waste
of time because their limitations cause maintenance nightmares.
Please do not repeat the mistakes of the miserable C pre-processor macros
(or scandalous C++ templates for that matter).

Settle for nothing less than Lisp macros, and strive for something even
better.
Full power macros make it possible for programmers to implement clean,
simple application specific mini-languages, that can be neatly nested inside
of other templates, data, etc.
There are many wonderful ways of separating presentation and logic, that
Lisp macros make not only possible but also convenient and maintainable.
The standard approach of lobotomizing the presentation language forces you
to separate presentation and logic in the worst possible way (by using
another language), while sacrificing many superior approaches to solving the
problem.
Paul Graham's wonderful book "On Lisp" practically explains Lisp macros with
lots of great examples, and you can download the pdf file and read it for
free:
http://www.paulgraham.com/onlisp.html

Lisp's "cond" seems more elegant than long chains of if/elif/else.
The if/elif/else syntax requires several different keywords with a
particular ordering, so it's harder to rearrange, add and delete clauses;
therefore it's harder to maintain the code over time.
It uses different keywords for different clauses (and in xml they're
repeated twice as begin and end tags) so you have to change both of them to
add or delete additional clauses.

How can the syntax best support maintaining reliable and readable templates
and code? (C's "switch" statement and single statement if/else's without
brackets are horrible counter examples.)
Since "if/else" is more common than if/elif/else, maybe it's better to keep
"if/else" simple, use "cond" for chains, and not to support "elif" (or
"elseif" or however you spell it, which invites mistakes).

Lisp's "cond" is easier to use and more general purpose than C's
"switch/case" syntax (which I would dread to emulate in any other language,
with its horrible limitations and problems (design defects): not supporting
computed case statements, requiring "break", too many ways to make
mistakes).

Paul Graham (the author of "On Lisp") has written some other interesting
stuff about simplifying "cond", in the design of his "ARC" language.
http://www.paulgraham.com/arc.html
http://www.paulgraham.com/arcll1.html

The following is from Paul Graham's web page, telling how Common Lisp
defines cond, compared to ARC. And how ARC defines if in terms of cond. Also
notice how "it" is bound to the result of the test expression inside of
"if".

    -Don

====

cond split into cond + do (progn)


  CL:  (cond ((a x) (princ "!") (b x))
             ((c x) (d x))
             (t (e x)))

  Arc: (cond (a x) (do (pr "!") (b x))
             (c x) (d x)
                   (e x))

- Usually use if, which binds it: (if (a x) (car it))

The core of Arc is much the same as the core of McCarthy's original 1960
Lisp. The operators eval, car, cdr, cons, and quote work the same when
applied to symbols and lists (the only data types in the 1960 paper), except
that car and cdr generate errors when applied to nil.

The one operator we changed is cond. McCarthy, who wanted to keep his axioms
to a minimum, buried progn within cond. That worked for his examples, but
for programming in general you soon find you need a progn separate from the
implicit progn of cond.

Having an implicit progn in cond means every cond clause has to have an
extra pair of parentheses. McCarthy said later that he thought he had gotten
cond wrong, that it used too many parentheses, and this may be what he
meant. Arc's cond doesn't have an implicit progn, and so you don't need the
parentheses around each clause. We also omitted the t in the default clause,
which seemed to be an onion. The example in the slide shows the same code in
Common Lisp and in Arc. (Arc's do is Common Lisp progn, and pr is Common
Lisp princ.)

In Arc, cond is a low-level operator, used mainly in macroexpansions. Most
of the time programmers use if, which is exactly the same, except that
within a successful then-expression, the variable it will be bound to the
result of the test-expression.

====