[asterisk-dev] [Code Review] Add support in AEL for macro return values and direct assignment of them to variables and functions.

[Watkins, Bradley]

> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com 
> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of 
> Steve Murphy
> Sent: Wednesday, December 31, 2008 4:39 PM
> To: Steve Murphy; Asterisk Developers
> Subject: Re: [asterisk-dev] [Code Review] Add support in AEL 
> for macro return values and direct assignment of them to 
> variables and functions.
> 
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.digium.com/r/114/#review294
> -----------------------------------------------------------
> 
> 
> Hmmmm. I see that you are doing substitutions in place when 
> you see a macro call -- even when in an expression;
> I don't think that's going to work very well in more than the 
> simplest cases;
> 
> fred = &macro-with-return(5);
> 
> =>
> 
> Gosub(macro-with-return,s,1,...)
> Set(fred=${GOSUB_RETVAL})
> 
> I just built with the patch and expanded your test case
> a little, and I don't think this approach will fly 
> very well.
> 
> macro test-retval (val1, val2) {
>         local i=5+${val1};
>         i=${i}+10*${val2};
>         return ${i};
> }
> 
> macro test-macro-assignment () {
>         foo=40 * &test-retval(2,3);
>         local bub=&test-retval(3,4);
>         NoOp(foo is ${foo} and bub is ${bub});
>         HASH(foo,bar)=&test-retval(9,7)+&test_retval(10,4);
>         return;
> }
> 
> And I'm getting syntax errors on line 11, the one with HASH().
> 
> In general, it's bad to try to do anything inside an 
> expression in ael.y. It was everything I could do to make the 
> scanner just collect it all and pass it in as a 'word'.
> 
> I think it'd be better to leave the
> ael parser alone, and make the expr parser handle that
> kind of logic in expressions... that way, we still
> pack up the RHS and wrap it in $[] as we have;
> 
> fred = &macro1(x,y) + &macro2(z); 
> =>
> Set(fred,$[&macro1(x,y) + &macro2(z)])
> 
> Right now, if we try to do this above the expression level, 
> you are going to have problems with calling
> multiple macros, having them munge each others return
> values, or limiting the syntax way more than is needful.
> 
> If you do this in main/ast_expr2.{y,fl}, then you have the 
> ability to call the macro (somehow), and collect the 
> result, atomically, and finish evaluating the expression
> with no such problems.
> 
> In ast_expr, we already allow you to call asterisk functions 
> without wrapping them in ${}:
> 
> $[ ${z} + MATH(..) ]
> 
> So, adding a macro shouldn't be impossible.
> 
> $[ &test-retval(9,7)+&test_retval(10,4) ]
> 
> should be parseable and evaluatable.
> 
> So, I propose that you might think along this line, and see 
> what ael.y and ael.flex might do to allow this notation in exprs...
> 
> 
> - Steve
> 
> 


I see what you're saying, and while the patch I posted was never
intended for more complex situations perhaps it should have been (users
are invariably going to try and use it that way, and then somebody will
have to explain that it just doesn't do that.).

I can take a look at the expression parser (and, in fact, spent some
time giving it a cursory glance this afternoon), but I was thinking
about this and came up with another idea (perhaps crazy, you tell me)
for achieving the same result.  What if, instead of adding new syntax to
parse in two places, there were (for lack of a better name at the
moment) a func_macro in the same vein as func_odbc which would generate
first-class Asterisk functions that could be used with the existing
format?

Thoughts?

My primary concern would be that functions just aren't meant to be
interactive, and a macro could readily go off on a tear doing all sorts
of crazy interactivity.  Does that mean we should be generating
applications? :O

That sounds like it would get woolly pretty quickly, but I'm just
throwing some things out while they're bouncing around my cranium.

Anyway, let me know what you think of these various hair-brained schemes
and I'll go from there.

Thanks again for taking the time to look at the code.

Regards,
- Brad