On 8/31/22 05:29, Antony Stone wrote:> >>> What I am suggesting is that Tracker=${CDR(uniqueid)} should be converted >>> by AEL into Set(Tracker=${CDR(uniqueid)}) in order to avoid this sort of >>> surprise. >> On the flip-side... anyone who currently relies on purely >> numeric/boolean handling of the current implementation would be >> incredibly surprised to find their AEL suddenly broken... so we need to >> take that into account. > Indeed. > > I realise that the better solution might be to wrap assignments (inside Set() > or MSet(), no matter) with $[..] *only* if the expressions contain arithmetic > operators + - * / and not if they are simple a=b assignments, including > a=${b}. > > This would ensure that even if ${b} expanded to something containing a dash, > it would be interpreted as a mathematical minus sign in a=${b} >I would hesitate about making this happen as well.. without a migration-plan in place. Typically: 1) Add a new option that would flip the behavior of var=val sets to auto-detect math and act accordingly on whether or not to use $[] (which comes with its own issues) 2) Warn about the change in the application: Ie: In Asterisk 20 there would be a warning stating in Asterisk 21 this will be the new default behavior But, there's issues with auto-detecting math. Because it's impossible for a compiler/transpiler to correctly assess *intent*. It can read the symbols and say, "Oh, I see you have some math symbols here, lets force this to math mode" in a purely search and replace context. Here's the problem with that. Variables can contain all kinds of (very unpredictable from a compiler perspective) stuff. How is the compiler supposed to tell the difference between the following examples, for intent var1 = ${a} + ${b} / ${c}; var2 = Hello World / Hello Bob / Hello Sue var3 = *1*1*1* HEY THERE IS A PROBLEM *1*1*1 var4 = This-Is-Some-Dash-Separated-Data: 1-2-3-4-5-6 I'm not saying I personally write code like this, but there are some quick examples that can easily proof this to be the wrong approach I think what you're looking for is quoted strings. var1 = "This-Is-Some-Dash-Separated-Data: 1-2-3-4-5-6" Which gets converted to an MSet(var1=$[ "This-Is-Some-Dash-Separated-Data: 1-2-3-4-5-6" ]) Which considering MSet actually has a desired behavior here of removing quotes, your value of var1 will be exactly what you expect it to be AEL 9999 => { var = "hi there - what's - up 0 * 1 / 4 not math"; NoOp(${var}); } Dialplan: vbox-markm-x64*CLI> dialplan show 9999 at services [ Context 'services' created by 'pbx_ael' ] '9999' => 1. MSet(var=$[ "hi there - what's - up 0 * 1 / 4 not math"]) [pbx_ael] 2. NoOp(${var}) [pbx_ael] Execution: MSet(var="hi there - what's - up 0 * 1 / 4 not math") NoOp(hi there - what's - up 0 * 1 / 4 not math) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20220831/494a7993/attachment.html>
On Wednesday 31 August 2022 at 15:01:57, Mark Murawski wrote:> On 8/31/22 05:29, Antony Stone wrote: > > > > I realise that a better solution might be to wrap assignments (inside > > Set() or MSet(), no matter) with $[..] *only* if the expressions contain > > arithmetic operators + - * / and not if they are simple a=b assignments, > > including a=${b}. > > > > This would ensure that even if ${b} expanded to something containing a > > dash, it would be interpreted as a mathematical minus sign in a=${b} > > I would hesitate about making this happen as well.. without a > migration-plan in place.Agreed; I didn't mean "please change it now"!> How is the compiler supposed to tell the difference between the > following examples, for intent > var1 = ${a} + ${b} / ${c}; > var2 = Hello World / Hello Bob / Hello Sue > var3 = *1*1*1* HEY THERE IS A PROBLEM *1*1*1 > var4 = This-Is-Some-Dash-Separated-Data: 1-2-3-4-5-6Agreed, but for text strings containing such symbols, I have to say that my natural inclination would be to put them in quote marks, as you say:> I think what you're looking for is quoted strings. > var1 = "This-Is-Some-Dash-Separated-Data: 1-2-3-4-5-6"It's when the *value of a variable* on the right hand side of the assignment happens to contain an arithmetic operator that the real surprise occurs.> Which considering MSet actually has a desired behavior here of removing > quotes, your value of var1 will be exactly what you expect it to beStrangely enough, I just discovered that as a solution to my example problem, which was: --------- Set(Tracker=${CDR(uniqueid)}); resulting in: Set(Tracker=eagle.domain.com-1661872057.2349) Just what I want. However: Tracker=${CDR(uniqueid)}; results in: MSet(Tracker=-1661872057.2349) --------- If I simply do Tracker="${CDR(uniqueid)}"; it works as required. It's just not the sort of syntax I've seen in any other language, and it feels (to me) weird. Maybe the documentation: "NOTE: AEL wraps the right hand side of an assignment with $[ ] to allow expressions to be used If this is unwanted, you can protect the right hand side from being wrapped by using the Set() application." could be enhanced to point out that quote marks can overcome the problem as well? https://wiki.asterisk.org/wiki/display/AST/AEL+Variables Antony. -- "640 kilobytes (of RAM) should be enough for anybody." - Bill Gates Please reply to the list; please *don't* CC me.