Re: [Webmacro-devel] Revised #macro stack overflow test code

[Brian G. <br...@qu...>]

>OK Brian, thanks for explaining this fully. I completely understand now. 
>However I am sure I will not be the last person to make this mistake - 
>it's certainly unintuitive if you don't have a deep understanding of the 
>way it is written.

That's probably true.  I agree 100% it could be documented better.  I think 
that just saying "its like C #define" goes a long way towards helping make 
it clear what's going on, at least to programmers.

You make some good arguments about how subtle #macro is.  Its true that if 
you don't understand the distinction between compile time and execution 
time (and few folks do, because it all happens dynamically), it is 
confusing.  I think these arguments actually supports _removing_ #macro -- 
because its too complicated and too easy to make mistakes.  Our goal was to 
keep the language butt-simple.

>I really think that WM -must- have some kind of runtime-evaluated callable 
>(and recursable) block mechanism otherwise we are really going to have 
>huge problems with any kind of tree traversal.

You're taking it as a given that WM is designed for traversing dynamic 
structures like trees, and I'm not sure you'd get 100% agreement from 
everyone on that.  This is a pretty big step beyond what most people are 
doing with WM.

Compare it to #foreach.  #foreach was added to allow iteration over linear 
collections (array, vectors, etc.)  The language didn't have a concept for 
looping or indexing (by design), so we added a facility for interating over 
lists.

Tree traversal is, conceptually, like list iteration.  Perhaps a directive 
for "iterating" over trees would solve the problem?  You could still use 
macros in the body, just use the directive to do the iteration.  I think 
the problem is that you're using the #macro for both expansion 
(presentation) and iteration (structure.)

You could even adapt #foreach to handle tree traversal relatively easily by 
defining an iterator to traverse the tree in the desired order, and write a 
context tool to take a tree and return such an interator, so you could 
traverse it with #foreach.  Since your example simply flattens the tree and 
visits each node, that would work, with no language changes, just a new 
"tree flattening" context tool.

>I really think webdesigners (not programmers) will have trouble 
>understanding the "limitations" of #macro so we should find a way to make 
>it abundantly clear what it cannot be used for. However, I would wager 
>that most web designers would still think "Well why the hell is that, 
>that's a real pain".

I think it takes a pretty big leap before this would occur to a web 
designer.  I think that most web designers would not even think to try and 
build recursive macros to traverse tree structures.  Most web designers 
would thing "cool, I don't have to type the same thing over and 
over."  That's really what it was for anyway -- a simple substitution 
mechanism, not a programming language construct.

>Here's an idea: Can we make #macro work out if it is being used "badly" 
>i.e. calling other #macros?

We certainly could.  But does calling other macros constitute "bad" 
usage?  I could easily see a macro for "table" which in turn uses a "row" 
macro in a #foreach.  That was part of the design intention.

Since this is a compile time error, it can be caught earlier with the 
CheckTemplates tool, for which there is an ANT task.  If you run that over 
your templates at build time, you can find out that you've got a problem 
before you deploy it.

>If so we should definitely trap this. BETTER still make it work in two 
>modes have an extra parameter #macro static MyMacro { } or #macro dynamic 
>$MyMacro { }, so that dynamic macros are evaluated at runtime instead, 
>static ones at build time?

I wouldn't call that better -- look how many people balked at having to 
distinguish between #include as (text|template|macro).

I think that what's needed is to step back and see what is the underlying 
problem here, if any -- and then decide if that's something that WM should 
do.  The downside of trying to make WM all things to all people is that you 
end up with JSP :(

Still, there are some good ideas that have been batted around here -- 
definable functions, inline templates, representing hashmaps -- all of 
which could help.



--
Brian Goetz
Quiotix Corporation
br...@qu...           Tel: 650-843-1300            Fax: 650-324-8032

http://www.quiotix.com