My povclipse2 parser is mature enough to throw someone else's code at 
it, and I chose BorderChars. [1]

He uses a construct
color <1,1,1>
which, while it works, doesn't seem particularly legal according to the 
spec:
http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_7_3

It should be
color rgb <1,1,1>

Should I flag this as an error? as a warning? or silently digest it as 
pov does?

[1] He also gave me
#declare foo /*;*/ = 1;
which made me realize I had to abandon the eclipse builtin scanners 
(give me the text from '#declare' to ';')
because there is no chance to treat comments as whitespace.
-- 
dik

Post a reply to this message

Le 23/01/2017 à 09:05, dick balaska a écrit :
> My povclipse2 parser is mature enough to throw someone else's code at
> it, and I chose BorderChars. [1]
>
> He uses a construct
> color <1,1,1>
> which, while it works, doesn't seem particularly legal according to the
> spec:
> http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_7_3
>
> It should be
> color rgb <1,1,1>
>
> Should I flag this as an error? as a warning? or silently digest it as
> pov does?
>

actually, if I read the doc correctly, *color <1,1,1>* is to be 
interpreted as *color rgbft <1,1,1,0,0>* (due to the implicit rgbft when 
none are specified and to vector promotion from a vector).

It's a few paragraph above your reference.

The trap would be *color 1*, which would be promoted to *color 
rgbft<1,1,1,1,1>* (due this time to vector promotion from a real number)

Due to the trap, I would vote for at least a warning. If you can 
separate the real from the vector expression, the warning might be 
suppressed for the vector.

Back to the BorderChars, it is legal, and the documentation might need 
some proof-reading about the syntax after color.

because it is fine with
#declare Foo = rgb<1,1,1>;
... color Foo ...

So it should be fine with
... color rgb<1,1,1> ...


> [1] He also gave me
> #declare foo /*;*/ = 1;
> which made me realize I had to abandon the eclipse builtin scanners
> (give me the text from '#declare' to ';')
> because there is no chance to treat comments as whitespace.

Post a reply to this message

Am 23.01.2017 um 09:05 schrieb dick balaska:
> My povclipse2 parser is mature enough to throw someone else's code at
> it, and I chose BorderChars. [1]
> 
> He uses a construct
> color <1,1,1>
> which, while it works, doesn't seem particularly legal according to the
> spec:
> http://www.povray.org/documentation/3.7.0/r3_3.html#r3_3_1_7_3
> 
> It should be
> color rgb <1,1,1>
> 
> Should I flag this as an error? as a warning? or silently digest it as
> pov does?

As Jerome correctly pointed out, `color <1,1,1>` is perfectly valid,
matching the production rules

    COLOR:
        ...
        color COLOR_BODY |
        ...
    COLOR_BODY:
        COLOR_VECTOR |
        ...
    COLOR_VECTOR:
        ...
        [ rgbft ] <5_Term_Vector> |
        ...

since <5_Term_Vector> can also be an implicitly expanded 3-term vector
(in which case the missing components are set to 0).

This behaviour is fully intentional in POV-Ray.

/Not/ intentional is the fact that <5_Term_Vector> can also be an
implicitly expanded scalar (in which all components are set to the
scalar value), and the newest versions of POV-Ray issue a warning in
such cases.

I think it would also be in order to isse a warning on `color
<1,1,1,1>`, as it would not be entirely clear whether the user intends
the 4th channel to be interpreted as filter or transmit. But `color
<1,1,1>` is certainly unambiguous.

Post a reply to this message