Strict Syntax Checking for Scripts

[klownboy]

I'm not sure why with version 15.00.0520 (it may have started one or 2 betas before this one) I started getting this "subject" message error on this section of a UDC script written and used frequently for nearly 2 years and most importantly it's not a function. This is a the section of the script. The first line of this section of the script throws the error. All it does is change the a specific CTB icon based on the state, in this case the viewing mode...it has worked fine for a long time so something happened - possibly with these latest function changes. Thanks.

Code: Select all

  if (ctbicon( , 14) != ":viewlist" OR cbtstate( , 14) != 0) {
    ctbstate(0, 14);
    ctbicon(":viewlist", 14);
  }

[admin]

Well, the new error trapping proved useful: You have a typo there: "cbtstate" should be "ctbstate"!

Thanks to PeterH ...

[PeterH]

Exactly this is why I think such situations should be reported by the script parser.
Isn't it helpful?. A very fine example


In the prev hours I would have needed it for bad quoted strings!
Had tried to paste the last token into the quote - but must have missed
See the example with bug - only to test I added the Echo:

Code: Select all

   $varv = '$_DB_sn0 $_DB_sn1 $_DB_sn2 $_DB_snc' $_DB_snl; // list of perm names
   Echo "varv = '$varv'.";

What would you expect as contents for $varv?
The result (in means of my script) was very strange. Output was rubbish

For me this was a bad-formed statement and should have been reported
(I think it can not make any sense in any way.)

[klownboy]

Thanks Don and PeterH. I'm glad I could provide a fine example I had that portion of the script in 2 places (one in a UDC script and one in an actual script) and one was working and the other was not. I stared at the 2 versions too long I suppose to see the difference. It's funny it hadn't showed up before, but now I know why. It was probably ignored instead of displaying the error message and I never realized it wasn't working under certain conditions via the UDC. Of course even now the error only showed under certain situations. I'm not sure it should be worded as a "undefined function" error though - that though me off track a bit since this was in existence nearly 2 years ago. Thanks.

[PeterH]

Thanks! That is, in short:

People make errors,
software should help people recognizing them. As good as possible.

[admin]

In the prev hours I would have needed it for bad quoted strings!
Had tried to paste the last token into the quote - but must have missed
See the example with bug - only to test I added the Echo:

Code: Select all

   $varv = '$_DB_sn0 $_DB_sn1 $_DB_sn2 $_DB_snc' $_DB_snl; // list of perm names
   Echo "varv = '$varv'.";

What would you expect as contents for $varv?
The result (in means of my script) was very strange. Output was rubbish

For me this was a bad-formed statement and should have been reported
(I think it can not make any sense in any way.)

This is more difficult. Reporting this will break too many old scripts.

What about a tweak for this? Like ScriptingStrictSyntax = 1, or so?

[bdeshi]

Expect to see more tinkers/users reporting this script doesn't work, that one doesn't work.

And sometimes scripts use this loophole "creatively".

I vote to leave it as is. Or at most mark it TODO for when you do another renovation like that commands-2-function conversion.

[PeterH]

...

This is more difficult. Reporting this will break too many old scripts.

What about a tweak for this? Like ScriptingStrictSyntax = 1, or so?

Saw the beta, installed, tweaked.

Run a test script, found a
$next = PopupMenu($items, 600, 300, , , , <crlf>, ' : ', 'Cancel');
reports: "Dubious syntax: 600"
I don't believe

But don't get me wrong: I think this is the way to go! Even at the price of several like this one!
I'm sure: I'll belong to those who will test it!

And as an idea: this should be settable with Setting and SettingP - then everyone can chose in a dynamic manner.

Just found No. 2: after Continue it's mocking about 300

In $dings=Chr(01); mocks about 01
Seems it doesn't like numerics without quote?

[admin]

Yep. Next version better.

[PeterH]

Yep. Next version better.

Much better!!!
(Before: not much fun when each numeric is mocked on )

Still found one I can't decide: for Load *,...; is * a constant, like TRUE, or must it be quoted?
Either you must allow it unquoted, or I must quote it
Docu doesn't seem exact here, and no example. When mentioned it's without quotes - but e.g. Resource Type also shows f or s, but surely has to be quoted...

[admin]

Hmm, not sure. I would even tend to allow (= find non-dubious) all one-characters arguments unquoted. Simply for economic reasons.

[bdeshi]

When there are multiple cases of the same dubiousness in a single scripted line, the error dialog should point out which one is currently caught.

[admin]

Not possible within the current architecture.

[PeterH]

Hmm, not sure. I would even tend to allow (= find non-dubious) all one-characters arguments unquoted. Simply for economic reasons.

I think in sense of understandig it's a bit risky: it might seem to say to some people that some strings need no quoting...
And: "TRUE" is not the same as TRUE - why should "F" be the same as F?

On the other side your economic reasons are correct.

Hm.

[bdeshi]

Don't hate the idea of stopping and broadcasting my mistakes at every other line, but I'd love to skip over all the warnings (when I'm sure the mistakes won't kill the script) by CTRL+continue, just like in stepmode.