Automagic Forum

I'm curious about the quoting requirements for variables. They seem backwards to me, so I'm wondering if someone can explain the logic behind them. Specifically, I'm referring to the fact numeric variables have to be quoted and strings don't. For example:

string: split({var_name},"delimiter")
number: var = {"var"} + 1

Or at least that's what I thought, but checking some different scripts I've done, some are quoted and some aren't, some are enclosed in curly braces and some aren't (I'm not wondering if whether or not they're enclosed affects whether or not quotes are needed), and both seem to work sometimes, but other times it only works one way. In fact, I recently struggled with a flow and tried using the toNumber function thinking the problem was that I was performing arithmetic on a string, but discovered I just needed to quote the variable (or maybe the other way around, since testing it now to put my thoughts together, it only works unquoted and unbraced).

So what exactly are the rules regarding variable syntax? This is the type of thing that always gives me problems, since each language uses different rules and they all seem to be somewhat illogical.

And why are semicolons required after each line of code but not after an if statement?

It is the vice versa, string require quote (either single quote or double quotes), while number must not be quoted. Curly braces are used to group if(), while() or for() block. Inside double quote (must be double quotes), curly braces used as inline expression to replace variables with their values. You can put multiple curly braces or even doing calculation inside double quotes. Single quote will makes the curly braces behave as normal curly braces.

Try this in script and put debug dialog afterward to see the result. Feel free to ask which var you are confused with.

Thanks for the thorough reply. I did my own test, then took another look at yours. Here's what I tried:

a = 2;
b = 3;

c = a + b; // 5
d = {a} + {b}; // 2
e = {"a"} + {"b"}; // a
f = "{a}" + "{b}"; // 5
g = "{a}"*"{b}"; // 6

h = "test string";
i = split(h," "); // [test, string]
j = split({h}," "); // [test, string]
k = split({"h"}," "); // [h]
l = split("{h}"," ") // [test, string]

And between the two, and thinking about it some more, here's my thoughts:

- Part of my problem is that sometimes I put the quotes inside the braces and sometimes I put them outside, so when things don't work right, sometimes it's because of quoting when I shouldn't be and sometimes it's because I'm quoting wrong.
- Quoting numeric variables works fine when adding, but not with multiplying (and, I assume, it also works with subtraction but not division), which adds to the confusion. And technically, it does work with multiplying, but only when done just right, as in my example vs yours. So it's clear now that, even though it *can* work with numeric variables quoted, it's best not to quote them. It's just confusing because the fact it does often work has led me to think that was the correct way to do it.
- I prefer quoting variables, since it makes them turn green, which is nice for making them stand out, making the code more readable. I'm used to this in other languages and editors, and not only does it make me prefer to quote them, but it makes it look like the syntax isn't right when I don't, since they're not colored and therefore look like they're not recognized as variables.
- If they're not quotes and/or braced, they look like a letter or word, not a variable. For example, c = a + b above looks like it should either result in ab or an error, like you're trying to add letters, not variables. It just feels like it should be c = {a} + {b} or c = !a + !b or c = %a + %b or something like that, to identify them as variables. It seems everything is a variable unless it's quoted, though. Just seems strange to me.
- Strings actually appear to work fine either way: bare, braced, or quoted and braced, also adding to the confusion.

And another example that seems to be contradictory:

sync_flow_name = {flow_name}

Only way it works. Doesn't work without the braces (which, based on the rules, seems like the proper way), with quotes, or with quotes and braces.

Interestingly, even though the are example requires the braces, triggertime doesn't. I thought maybe braces were required for flow context variables, but clearly that's not the case. Also, they're required to identify something as a variable in a condition, e.g. Wi-Fi connected, and in message dialogs, which I also find confusing.

With your last post, I now understand your question on curly braces. In scripting environment (script, expression, control UI, extras), curly braces is not needed at all. But in any other fields in non scripting environment, curly braces is needed to access the variable's content. You can see the element's field explanation, if it has "variables supported", you can put variable there by using curly braces. You can somewhat imagine that all those "variables supported" field has imaginary double quotes, which will translate the curly braces into their value. You can see the difference as you put curly braces, the color will change to cyan-blue, denoting it is a variable. For the ones which doesn't turn cyan-blue after putting braces, most likely that field doesn't support variable.


Let's walk thru the script for the strange part. this is one of the problem, when there is curly braces, it terminate the value there. Anything afterward + {b} is calculated but not assigned to the d. This cause logic error. So even if you put d still take the {a} portion only, which is 2. However if you put another assignment in b and c braces, it will assign for each. d = 2, d2 = 3, d3 = 5. This is useful for multiple script assignment in one line, but I won't encourage this style. I better split them to multiple statement in single line and terminate with semi colon. There are exception though, when I need to use function, or I want to save additional curly braces in if(), for(), while() block.

e suffer from the same problem, except now it is assigned to string "a", instead of variable a.

f and g are OK. If you still need the green coloring to identify the variable, use this way. I still don't encourage it, better use c method.

j and l are OK, as both still evaluate to the value of h. But k will evaluate to string "h", hence when you split it, nothing happen, and the result is the "h" alone as the first element.

vertigo wrote: ↑

09 May 2020 07:02

And between the two, and thinking about it some more, here's my thoughts:

- Part of my problem is that sometimes I put the quotes inside the braces and sometimes I put them outside, so when things don't work right, sometimes it's because of quoting when I shouldn't be and sometimes it's because I'm quoting wrong.

Don't put curly braces unnecessarily in scripting, as it might cause logic error as shown above (more fatal than syntax error). I sometimes think that the coloring is actually a hindrance, it makes us lazy. I occassionally type a long script in notepad (without any coloring), and then pasting it to script later.

vertigo wrote: ↑

09 May 2020 07:02

- Quoting numeric variables works fine when adding, but not with multiplying (and, I assume, it also works with subtraction but not division), which adds to the confusion. And technically, it does work with multiplying, but only when done just right, as in my example vs yours. So it's clear now that, even though it *can* work with numeric variables quoted, it's best not to quote them. It's just confusing because the fact it does often work has led me to think that was the correct way to do it.

Automagic has some of the problem from javascript, such as force variable type. When "1" can be converted to number, it will be converted to number if the next operand is number too. Best way is to avoid this force conversion, as it is very prone to logic error. Especially when dealing with +, as it can be use to add number and concatente string.

vertigo wrote: ↑

09 May 2020 07:02

- I prefer quoting variables, since it makes them turn green, which is nice for making them stand out, making the code more readable. I'm used to this in other languages and editors, and not only does it make me prefer to quote them, but it makes it look like the syntax isn't right when I don't, since they're not colored and therefore look like they're not recognized as variables.
- If they're not quotes and/or braced, they look like a letter or word, not a variable. For example, c = a + b above looks like it should either result in ab or an error, like you're trying to add letters, not variables. It just feels like it should be c = {a} + {b} or c = !a + !b or c = %a + %b or something like that, to identify them as variables. It seems everything is a variable unless it's quoted, though. Just seems strange to me.

I recommend to get used to Automagic scripting style. White color should be quite stand out. And if you got undefined variable, you get red underline to notify you. Javascript, python and several other languages also use this method. (c = a + b) I don't think Automagic will change this scripting style.

This works fine here in script action, without braces

Thanks! Very helpful as always. I think the main thing in there that I need to remember is: script = don't use curlies, vars are supported = use them. And to just get used to not having the vars colored, though I have to say I do prefer when they are, and it feels very strange that they're not, but at least now that I understand how it works I should be able to get used to it. And I don't expect or think thatbAutomagic should change, I just wanted to see where I was going wrong. Which seems to mainly be that I'm used to coding where it's all code, so all the same, whereas this is sometimes code and sometimes not, so it just feels inconsistent.

I figured out why I appeared to need the braces in sync_flow_name = flow_name. I was mismatching the syntax between the script and the message dialog later that uses the variable. So I got that working. Thanks again for the guidance.