[asterisk-users] Originate with label?

[Mark Murawski]

On 8/29/22 09:30, Antony Stone wrote:
>
> It is, although there are ways I think it can be improved - I'm wondering how
> best to go about proposing these.
>
> The most obvious for now are:
>
>   - please can "a=1;" be converted to use Set() instead of MSet() (especially
> since MSet is officially deprecated)?

Currently being discussed!  We can definitely continue talking about the 
pros and cons of adding an option for this or maybe finding another way 
altogether.

>   - same thing for for (;;)

I see that for (;;) produces an empty MSet().  Definitely this can be 
cleaned up.  Thanks for bringing this up.  In the meantime you can use 
while (1)


>   - please can gosub be added, to convert into Gosub() (matching goto
> converting to Goto())?  The & syntax is completely different from the rest of
> the language, and also creates redundant assignments at the start of the
> subroutine for parsing the parameters.  Now that macros are deprecated in
> favour of subroutines, it makes sense, I think, to make gosub a part of AEL.

I agree that AEL keyword 'gosub' should exist.  That's been one of my 
todo items.  From not only a consistency perspective, but from a syntax 
checking perspective it would benefit from reporting whether or not your 
gosub destination exists or not, just like goto will complain that the 
destination doesn't exist when the context/extension/priority used is 
not valid.

The '&' syntax does use GoSub under the hood, and not the deprecated 
Macro().  And I'm not sure what you mean by redundant parameters?  When 
you use AEL 'macro' to define a '& destination', it uses the positional 
parameters that are passed in as ARG1/ARG2/etc that are inherent in 
using GoSub and converts them to more friendly named-parameters (as 
defined in the macro definition).  This is why there's always a group of 
MSet's generated when using AEL 'macro'.  If you don't want these extra 
MSets, then feel free to define a straight up context to GoSub into and 
you can do your own parameter processing using ARG1/ARG2/etc


>   - it would be great if the redundant NoOp()s which get created by if .. else,
> while ... and for(;;) could be (maybe optionally?) removed from the resultant
> dialplan code - otherwise you end up with lots of added commands such as
> NoOp(Finish if_if_fromTrunk_208_209); in the output.


They aren't redundant specifically, they were left in there (not by me) 
for debugging/tracing purposes.  But for the casual user, I agree they 
are mysterious and not very useful. My idea to address this is to 
instead report on the actual if condition to assist with 
tracing/troubleshooting.

This is a mockup of what the new-style if/else processor would output

                     26. NoOp(AEL IF("\${DIALSTATUS}" == "BUSY") -- 
extensions.ael:1405)
                     27. GotoIf($["${DIALSTATUS}" == "BUSY"]?28:30)
                     28. Set(voiceMailOptions=b)
                     29. Goto(32)
                     30. NoOp(AEL ELSE -- extensions.ael:1409)
                     31. Set(voiceMailOptions=u)
                     31. NoOp(AEL END ELSE -- extensions.ael:1410)
                     32. NoOp(AEL END IF("\${DIALSTATUS}" == "BUSY") -- 
extensions.ael:1411)
                     33. NoOp(DoStuff)


My idea is that the 'if' block would be preceded by outputting the 
logical condition we're about to check, along with the original ael line 
number, and then at the end of the if block, we would get an associated 
END IF with the original ael line number.  This would enable the ability 
to quickly locate the code where conditions are being used and also be 
able to look at the logs and see why your code is doing what it's doing 
without a lot of extra verbosity and without needing a lot of work to 
find which ael-lines are running.

>   - finally, it would be good if the documentation could be clear about whether
> the extensions.conf [general] section can be substituted using AEL.  I haven't
> yet worked out whether this is possible or not.


[general] section options are not available in ael... currently there's 
no mechanism to support that sort of thing.

bracket items like [general] aren't supported in the AEL parser. and 
some of the options don't even make sense and/or apply to AEL like 
static/writeprotect