[asterisk-users] Originate with label?

[asterisk at phreaknet.org]

On 8/29/2022 11:00 AM, Mark Murawski wrote:
> 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)

Why all the GotoIfs? Why not just use the If/EndIf applications 
(assuming they get merged)? Much cleaner syntax:

If($["${DIALSTATUS}"="BUSY"])
Set(voiceMailOptions=b)
Else()
Set(voiceMailOptions=u)
EndIf()

NA

>
> 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.