On 11/6/23 10:04, William F Pokorny wrote:
> All seems to work except the mandatory semicolon bit is not enforced by 
> the parser!
> 
> This means the following code runs without complaint, but incorrectly.
> 
>      #declare <A0,A1,A2> = <3,2,1>; // This works.
>      #declare <A0,A1,A2> = <1,2,3>  // This only appears to work
>                                     // Meaning no
parse error
>      #debug concat("A0 = ",str(A0,3,1),"\n")
>      #debug concat("A1 = ",str(A1,3,1),"\n")
>      #debug concat("A2 = ",str(A2,3,1),"\n")
> 
>      #error "Stopping at parse test end\n"
> 
> The exposure made worse because in other applications, the tuple ID 
> assignments treat the trailing semicolon as optional.

An update. It was apparent once I dug through the code that clipka 
intended for the vector form to work like other tuple assignments in not 
needing a trailing semicolon, but allowing one.

The vector tuple form is broken in all parsers since mid 2015 in not 
working as intended or failing for lack of semicolons.

Try as I might over the past few days, I've not been able to make it 
work as intended without breaking the general ability to declare things 
nearly anywhere.

A capability which looks to be the primary reason we sometimes need 
semicolons. We need to somehow mark the end of all the '#' language 
directives where we allow them in the middle of a other parsing.

It's also very much related to how grabbing a single token can sometimes 
cause the parser to eat up a bunch of scene code and do nothing with it. 
This last is exactly what is happening in the sample code up top. It is 
what was happening with this recent bug find too:

https://news.povray.org/povray.beta-test/thread/%3C6533cdad%241%40news.povray.org%3E/

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.

Bill P.

Post a reply to this message