On 11/6/23 11:29, William F Pokorny wrote:
> I've take a run or two at forcing the semicolon in this one tuple / 
> batch assignment type, but so far I'm failing there too. That said, I 
> think this the more likely outcome at the moment.

I believe this fixed in the yuqk fork - in that lack of a semicolon is 
now flagged as an error. Only took a week... :-(

Bill P.


Details for those interested.
-----------------------------

Added an optional parameter in hereViaRValue defaulted false to:

Parse_Unknown_Vector()

called from Parser::Parse_RValue() and set true. Plus to

Parse_Express(expr, &terms, true)

called from Parser::Parse_Declare() and set true.

Plus to a set of expression related functions and calls in 
parser_expressions.cpp so the proper indication of the 'right value 
parsing' state exists in the function called Parser::Parse_Num_Factor() 
where the vector dot access parsing happens near the bottom.

It appears when the dot access methods were coded, the right side 
parsing state was never extended down into Parse_Num_Factor(). Further, 
necessary checking for semicolons was never created. Such checking needs 
to know whether the parser was in a right hand value parsing state.

This despite code being used where the dot access bit sometimes, 
necessarily, is triggering the execution of directives coded right in 
the middle of other work parsing work(a).

(a) - The triggering by way of a side effect of somewhere down the call 
chains grabbing directive tokens while the parser is in a state which 
allows the mid stream directives.

What all this means.

In the yuqk fork, the vector form of tuple / batch / list ID assignments 
should work. Further, due the additional checking down in the dot access 
methods for semicolons, it should be much less likely other non-tuple 
form vector type assignments can cause unwanted side effects due the 
lack of a semicolon. It would have been complicated SDL code which fell 
into the trap previously. If users previously tripped it, and got 
confusing results, my bet is they probably simplified their code - and 
things began to work.

I offer no equivalent v3.8 parser fixes beyond what can be found in my 
code or the description herein. Partly, this because I leaned on some 
newer yuqk / v4.0 parser functionality for the fix but, the update is 
complicated and I'm not going to try and replicate it in another version 
of parser code.

Disclaimer. There are simply too many paths into Parse_Num_Factor() for 
me to be 100% sure all situations which could be a problem are fixed. My 
test cases are clean... It's better than it was.

Post a reply to this message