Am 2017-02-02 09:31, also sprach clipka:
> Am 02.02.2017 um 11:37 schrieb dick balaska:
>> I'm stuck on my parser. :(
>>
>> I use the colefax spline macro like this.
>> #declare fishpath=create_spline(array[3] {<1,2,3>,<2,3,4>,<3,4,5>} 3)
>>
>> povclipse2 needs to see it like this.
>> #declare fishpath=create_spline(array[3] {<1,2,3>,<2,3,4>,<3,4,5>}, 3);
>>
>> povray lets me sneak that comma separator in, but refuses to accept the
>> trailing semicolon.
>>
>> I don't know how to resolve this.  To me, there is a rule that says
>> "start with #declare and run to a ;"  I don't know that it's a funky
>> macro at this point, it's just opaque text.  It is the same as
>> #declare one=cos(0);
>
> There's a difference: cos() is a function, and is therefore always
> well-behaved; create_spline() is a macro, and macros /can/ do extremely
> funky stuff that leaves the official parser in a completely different
> state than a function would. For example, a macro designed to be used in
> a "#declare" may already contain the trailing semicolon, which would be
> poor macro style yet perfectly legit. And there are other things that
> can interfere.
>

Yes, but I don't know that cos is a function and create_spline is a 
macro at this point. I'm trying to extract a sentence for further 
evaluation.  The eclipse parser is all about drill down.  The first 
"sentence" is the entire file.  In colors.inc, the next sentence (after 
the comments) is everything between #ifndef(Colors_Inc_Temp) and its #end

It would be helpful if a bare[1], 'unexpected' semicolon was a NOP, like 
in C, instead of a fatal error.
http://www.povray.org/documentation/view/3.6.0/237/
says "Semicolons after other declarations are optional."  so, sometimes 
they are a NOP.

[1] by bare, I mean top level, not in the middle of an evaluation.
like C's  int i=0;;

-- 
dik

Post a reply to this message