>> // misformed #declare
>> #declare Weird = #declare Aval = 1;
>
>> // other properly formed statements
>> #declare PigVal = pigment {rgb <0,0,0>};
>> #declare ObjVal = sphere {<0,0,0>,1};
>
>> #if (true=true)
>> #local c=0;
>> #while (c=0)
>
>> // this object ends the misformed #declare and doesn't render
>> object {pass_text}
>
>> // this object renders normally
>> object {fail_text}
>
>> #local c=1;
>> #end
>> #end
>
>  As I said, the way the parser works is not always completely intuitive.
>
>  Your example is a perfect example. It makes perfect sense when you know
> how the parsing of #declares works, even if this kind of parsing sometimes
> results in odd behavior like in your example.
>
>  What is happening is that when the parser sees the very first "#declare",
> it then parses an identifier name and a '='. After this it calls 
> recursively
> itself, asking itself for something which can be assigned to an 
> identifier.
> The very first thing which pops up is that first "object" block. Thus that
> gets assigned to the first identifier.
>
>  Of course since the parser is calling itself recursively, if there are
> any other #-commands in-between, those will get parsed as their own 
> entities,
> before the parser gets to that first "object" block.
>
>  As said, the behavior is not buggy per se, but a side-effect of the
> recursive nature of the parser. Sometimes these side-effects produce
> unintuitive results.

The problem isn't that Weird is being set to an object identifier,
the problem is that #end (which is outside the declare) is being
associated with #while (inside the declare). I think most people
would expect the scope of control structures inside of a declare
to be inside that declare. I guess you could do things like ...

#local c = 0;
#declare Third = #declare Second = #declare First =
#while (c<3) object {pass_text} #local c=c+1; #end

... with the current parsing, but it just seems bad to encourage
difficult to read code. The first example is more of a typical typo,
"oops I paste in a declare with the value". IMHO this is one
of those "That's not a bug, it's a feature!" things.

Post a reply to this message