On 9/30/19 7:04 PM, Alain Martel wrote:
> Le 2019-09-29 à 08:48, William F Pokorny a écrit :
...
>> A declare without the leading # works too but we get:
>>
>> File 'tmp.pov' line 40: Parse Warning: Should have '#' before 'declare'.
>> File 'tmp.pov' line 40: Possible Parse Error: 'declare' should be 
>> changed to
>>   '#declare'. Future versions may not support 'declare' and may require
>>   '#declare'.
> 
> Using declare instead of #declare can result in an error at parse time.
> 

If you have an example which results in an actual error at parse time, 
I'd like to get it.

I have a collection of parser test cases and I spent time yesterday 
capturing/creating parser test cases for these '#' variants. I didn't 
come up with anything that generated an actual parse error - or render 
problem - only the warnings above.

I did come up with a case with isolated #s ahead of a bare 'declare' 
which did NOT generate the warnings above (I found a parser bug) though 
the render result was still fine.

>>
>> Given this warning, I'd think we should be getting one on #object {} 
>> and the like too as the other side of the syntax change push - now 
>> that I understand there is another side.
> 
> #object should generate a warning.
> Same for #Primitive_Name
> 

Unsure if you were agreeing we should be getting such warnings, or 
saying POV-Ray does generate such a warning. If the latter, I never saw 
that while trying different things. If warnings for #Primitive_Name do 
sometimes happen, I'd like an example test case for my collection.

Also had the thought last night, Does say '#accuracy 0.001' work..? It
does.

Aside: I've converted to vim/gvim for my editor. Still working to get 
back up to speed, but, vim itself ships with syntax highlighting and 
indenting for POV-Ray v3.7(1) and, interestingly, it specifically 
supports the '#<zero or as many spaces as you want>local' type syntax 
for the language control elements (and #default{} and not default{} if 
wondering - matching our current documentation).

Bill P.

(1) - There are some issues with it as others have noted. I might have 
go at my own v3.8 version adding error indications for bad # use along 
with v3.8 plus experimental feature support.

Post a reply to this message