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

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
     https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to