Re: weird macro params issue

On 2008.05.22., at 2:02, Felix Gnass wrote:

> <#function foo a b=c c="foo" >
>   <#return "a:" + a + " b:" + b + " c:" + c />
> </#function>
>
> ... should throw an exception because "c" is defined after "b" ...

That happens with a single pass evaluation, but a multi pass  
evaluation would succeed on it.

What I did in 2.3 codebase would resolve this too -- it repeatedly  
passes through the argument list until it can't resolve anything more.  
At that point either everything got resolved (success), or something  
didn't (failure). Of course, it's most economic to have only a single  
pass, so if you order your arguments in the definition so that their  
defaults only rely on other symbols defined to their left you'll  
always meet that.

Anyway -- I don't have a problem even if we restrict this behaviour  
completely for 2.4, but leaving it as-is feels bad. We should either  
always fail, or decide on a fully deterministic successful behavior.  
Within that we can also have a single pass or a multi pass approach;  
multi pass doesn't make it more expensive to evaluate calls where a  
single pass is sufficient for evaluation, so it's just additional  
convenience.

Anyway, I started thinking about this because it looks like some users  
would like to have this feature, and while "always fail" is certainly  
quick to implement, to some it might look like an arbitrary  
limitation... It's one of those things that don't really complicate  
the language IMHO, because if you don't use it, you don't even need to  
be aware of it.

Attila.

>
> unless of course a variable "c" was defined in the enclosing  
> namespace:
>
> foo(1) == [ERROR: c is undefined]
>
> <#assign c=2 />
> foo(1) == "a:1 b:2 c:foo"
> foo(1,4,3) == "a:1 b:4 c:3"
>
> Best regards,
> -Felix


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/