A strange error message (with an old version...)

[snowsnowsnow]

So, I was working on a script a few days ago, using my 9 year old version of WB (with which I am quite happy, thankyouverymuch) and I hit upon a strange error condition.  The question becomes:

Can this statement:

Code (winbatch) Select Expand

t = A[I]

ever cause the script to abort with error "Statement continues after expected end" ?

'cause that's what was happening.  I could see it failing for any number of other reasons (i.e., any number of other error msgs) - but how could it generate that one?

Believe me, I pounded on this one for quite a while - moved the statement up/down in the script, re-wrote it several different ways - but it always bombed (with the same error message) whenever I tried to access

Code (winbatch) Select Expand

A[I].

The funny thing is that the crash seemed to happen the *second* time through the loop - i.e., the second time the above statement was executed.

It really looked like somehow the array had gotten corrupted, and that it had gotten into a state where any access to the array would cause the above-described condition to result.

Anyway, after pounding on it for quite a while, I ended up re-writing the part of the script entirely (basically, to not use arrays at all) and now it works fine (so I can't really go back and re-create the error now), but I am curious if there are (or were) any known issues that could cause this sort of thing?

[stanl]

I have often been baffled by that error.  I have received it when omitting a ";" at the end of an SQL statement (with the ACE Provider).

Let me take a stab at yours understanding that you probably already considered it:

With

Code Select Expand

t= a[I] I assume I is part of a For I = n to n1 loop. In which case the error message would really be more an "out of bounds" error. The idea that the array was corrupted is very interesting, but I would leave that up to those who respond to this thread with "What exact version are you using"? "Did you check the WB error .ini"? etc...

[td]

To much has change in the WIL interpreter over the last nine plus years to offer much in the way of even speculation as to the cause of the error.  However, one somewhat obscure cause of the error is related to a syntax error at some distant seemingly unrelated location in the script.  With a detailed knowledge of the inner workings of the parser, the seemingly unrelated cause and effect can be understood but without that knowledge the connection is very difficult to discern.

[snowsnowsnow]

Interesting responses.  Thanks.

One thing is that it does sort of sound to me like a "subscript out of bounds" problem, that just gets mistakenly translated to "Statement continues after expected end".  I'm pretty sure that I am not passing an invalid subscript, but this again leads me to think that some sort of corruption is in play here.  It could well be something like what Tony alludes to, but of course, the chances of running that down at this late date are basically zero.

FWIW, the idiom I usually use for iterating an array is:

Code (winbatch) Select Expand


A = Arrayize(...)
n0 = ArrInfo(A,1) - 1
FOR I = 0 TO n0
...
NEXT


As a side editorial, it would actually be nice if Arrayize() returned the highest legal subscript (i.e., one less than the number of items in the list), so you could use it like:

Code (winbatch) Select Expand


n0 = Arrayize(A,...)


Which would both set n0 and setup the array (since arrays are usually passed "by reference" anyway, in WB and in most other languages too for that matter).  Then you wouldn't have to use ArrInfo() on the next line of code.

[td]

Interesting responses.  Thanks.

One thing is that it does sort of sound to me like a "subscript out of bounds" problem, that just gets mistakenly translated to "Statement continues after expected end".  I'm pretty sure that I am not passing an invalid subscript, but this again leads me to think that some sort of corruption is in play here.  It could well be something like what Tony alludes to, but of course, the chances of running that down at this late date are basically zero.

Irregardless of the cause and as previously mentioned, much has changed in nines years so assuming for the moment the you have encountered some kind of bug, it is very unlikely that the problem still exists in the current version of the interpreter.

[snowsnowsnow]

Interesting responses.  Thanks.

One thing is that it does sort of sound to me like a "subscript out of bounds" problem, that just gets mistakenly translated to "Statement continues after expected end".  I'm pretty sure that I am not passing an invalid subscript, but this again leads me to think that some sort of corruption is in play here.  It could well be something like what Tony alludes to, but of course, the chances of running that down at this late date are basically zero.

Irregardless of the cause and as previously mentioned, much has changed in nines years so assuming for the moment the you have encountered some kind of bug, it is very unlikely that the problem still exists in the current version of the interpreter.

Agreed.  I think I've stipulated all along that a solution almost certainly doesn't exist.
My primary reason-for-posting was the hope that there might be a "known problem" - as in, yesh, don't do this and your arrays won't get corrupted.  Absent that, there really isn't any hope.

In fact, the only way this problem could be solved (by people other than me) is if I sent in all my code and all the tools that I used, including my camera (the script's purpose is to fetch data from my digital camera).  Obviously, that's not practical.

As I said, the hope was just that there was some "known problem".

Anyway...

[td]

Agreed.  I think I've stipulated all along that a solution almost certainly doesn't exist.
My primary reason-for-posting was the hope that there might be a "known problem" - as in, yesh, don't do this and your arrays won't get corrupted.  Absent that, there really isn't any hope.

In fact, the only way this problem could be solved (by people other than me) is if I sent in all my code and all the tools that I used, including my camera (the script's purpose is to fetch data from my digital camera).  Obviously, that's not practical.

As I said, the hope was just that there was some "known problem".

Anyway...

We keep extensive change logs and nothing in them suggests any kind of known problem might be causing your issue in your version.  That is one of the reasons why a I suggested that a non array related scripting error at some other spot in your script may be causing your problem. 

Of course, there is always the possibility that you encountered an error in that version that no one else encountered.  And that possibility is why I also mentioned that extensive changes have been made to the array implementation and WinBatch in general since your version.

[snowsnowsnow]

heh heh...

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Anyway, I do have an update on this thread.  I am now convinced that it is a subscript out of range problem.
(I.e., really, just a bad error message problem)

Today, I was working on another program, and it contained a line like:

s = StrCat(...)

where the ... is a long series of expressions that reference various elements of a couple of arrays.

I was getting "Function syntax error" aborts on this line, until I remembered that WB arrays go from 0 to n-1 (not 1 to n).  When I decreased all the subscripts by 1, the error went away.

If someone could test this on current versions of WB, that'd be interesting to me.

Something like

A = Arrayize("one two three"," ")

s = StrCat(A[1],",",A[2],",",A[3])

This is, of course, not as complex as the test case I was working with, but see if it fails and with which error message it fails...

[td]

The StrCat function was superseded by the concatenation operator in version 2006D. 

[snowsnowsnow]

The StrCat function was superseded by the concatenation operator in version 2006D.

With all due respect, what does that have to do with anything?

First of all, I assume that StrCat() still works, even though ":" is easier and thus preferred.  But they are equivalent, aren't they?

Anyway, I still would like for someone to try the quoted example, in a current version, using ":" if you prefer it to StrCat().

[JTaylor]

It produces a

    StrCat: Function Syntax Error

If you change it to the ":" concatenation it produces the appropriate Array Subscript out of bounds error.

Jim

[snowsnowsnow]

It produces a

    StrCat: Function Syntax Error

If you change it to the ":" concatenation it produces the appropriate Array Subscript out of bounds error.

Jim

Very interesting.  Thanks for checking this.

Error messages (particularly wrong ones) can be fun...

[td]

With all due respect, what does that have to do with anything?

It has a lot to do with the subject of StrCat.  The function currently exists strictly for backward compatibility.  It is a bit too strong for our liking but MSFT would call it 'deprecated'.  This means that it has more or less remained the same since version 2006D.   

First of all, I assume that StrCat() still works, even though ":" is easier and thus preferred.  But they are equivalent, aren't they?

No, they are not equivalent.  Because ':' is a WIL operator, it has a completely separate implementation.  The StrCat function was implemented before WIL had built in support for functions with optional parameters so it had to do all of its own parsing.   That is a sub-optimal design from a software engineering perspective.   

Anyway, I still would like for someone to try the quoted example, in a current version, using ":" if you prefer it to StrCat().

StrCat - virtually unchanged since 2006D.
:         - Relies solely on the WIL token parser for operands which means it will display appropriate WIL errors.

[snowsnowsnow]

That's very interesting.  Thanks for the clarification.  It does indeed explain a lot.

BTW, I assume (there goes that word again!) that when you say "optional parameters" (in the sense of the WIL interpreter not having support for same until recently), I assume that means the same thing as "a variable number of parameters".  Correct?

So, tell me more - in what sense does it now have support for functions with a variable number of parameters?

[td]

Optional parameters have been around for a long time.  I don't remember when that was added.  I just remember that it was post StrCat.   Parent process, WIL, and  extender functions can have optional parameters.  Function parameters are positional so all required parameters must precede optional parameters (from left to right) in the parameter list.  This also means that values must be supplied for all parameters up to and including the last optional one you wish to specify.   Most functions are limited to 16 parameters which is another reason why the StrCat function does its own parameter parsing.  StrCat can have up to 1024 parameters.

[stanl]

One might be a tad confused between the last 2 posts. Snow asked if optional equals variable, then Tony seemed to indicate positional, so either to clear up or muddy...

MyFunc(1,"ab",,,) - would indicate a function with 5 parameters, where the last three are optional, meaning if not filled in a default value within the function is used, but they are positional and order is important, and there are a multitude of these especially in File I/O where the last parameter can be left of and a default assumed.

StrCat(...) appears to accept variable, as to the number, and optional non-positional [i.e. strcat("x","y") could be strcat("y","x") and are interpreted by the outcome not within the function]. And I viewed strcat() as more or less accepting a list rather than parameters.

Finally, there is the way WB handles named parameters when using OLE with Excel and other OLE functions - here you can vary both the number and position of the parameter by referring by name. Not sure if it was ever suggested to handle internal functions that way.

... just musing

[td]

One might be a tad confused between the last 2 posts. Snow asked if optional equals variable, then Tony seemed to indicate positional, so either to clear up or muddy...

MyFunc(1,"ab",,,) - would indicate a function with 5 parameters, where the last three are optional, meaning if not filled in a default value within the function is used, but they are positional and order is important, and there are a multitude of these especially in File I/O where the last parameter can be left of and a default assumed.

StrCat(...) appears to accept variable, as to the number, and optional non-positional [i.e. strcat("x","y") could be strcat("y","x") and are interpreted by the outcome not within the function]. And I viewed strcat() as more or less accepting a list rather than parameters.

The StrCat has one required parameter, the first one, and the rest are optional parameters up to 1024 total.  They are also positional parameters because the parameter's position in the parameter list* determines how the function interprets the datum.  The fact that all parameters happen to converted to the same data type is moot.  And of course the other general rules of WIL optional parameters still apply, i.e., values must be supplied for all parameters up to and including the last optional one you wish to specify.  The last bit is another reason StrCat parameters can be considered positional.

If StrCat function's parameters were not positional, you could name parameters something like StrCat(second=''y', first='x') and theoretically end up with the side-effect 'xy'.

So StrCat follows the same parameter rules that other WIL functions follow with the exception that it accepts more of them. 
 
* 'parameter list' is a generally accepted term for the pieces of data provided as input to a function.

Finally, there is the way WB handles named parameters when using OLE with Excel and other OLE functions - here you can vary both the number and position of the parameter by referring by name. Not sure if it was ever suggested to handle internal functions that way.

... just musing

COM Automaton methods are not members of the set of parent process functions, WIL functions, and extender functions but the topic of this thread, the StrCat function, is a member of that set.