Am 19.04.2010 23:34, schrieb Bent:

> Oddly, sum and prod are considered to be numbers -- when POV-Ray is looking for
> numbers:
>
> #debug concat("sum = ",str(sum,0,3),"; prod = ",str(prod,0,3),"\n")

Thatnks for pointing this out - and thanks for the thorough analysis; 
from what I see, you're perfectly right.


> Also, I was curious why POV-Ray is only picky about argument delimiters (that
> is, commas) some of the time.

Basically, the rules are simple: Commas are optional, always and 
everywhere (though in some cases omitting them may change the meaning, 
e.g. "1,-2" is two numeric exptessions while "1-2" is a single numeric 
expression) - *except in functions*, where commas are *mandatory*.

What happens when you leave them out depends:

> For instance, POV-Ray is perfectly happy with this:
>
> #macro A(b c)b+c#end
> #declare a=0;
> #declare b=A(1a);

The above should be rather easy to understand. The last one may be the 
most surprising, but as everything starting with a "." or digit is 
considered a number token, and "a" is never part of such a token, 
POV-Ray decides that the "a" must start a new token.

> #declare f=function{A(a.3)+A(A(1a)1)}

While commas are /not/ optional in functions, you do have macro calls 
here, which get resolved even before the function parser ever gets to 
see them.

> #debug str(b(0)3)

This sould be simple again. Note that (0) is a valid numeric expression 
(which, not surprisingly, evaluates to 0).

> #debug"\n"
> #debug str(pow(3!1)0(3))

Again, "!1" is a valid numeric expression, evaluating to 0. As there's 
no binary operator between "3" and "!1", POV-Ray decides that they can't 
be a single expression.

> #debug "\n"
> #debug str(f(0
> 0a)0 3)

While functions are involved here, function /calls/ from normal SDL code 
are still within the domain of the SDL parser, allowing you to drop 
commas here.

> #debug "\n"
> #debug vstr(3x"a"1!2+2)

Ugly, but evaluates to the same as

#debug vstr(3,x,"a",1,!2+2)


> However, it is not happy with this:
>
> #declare f=function{pow(3!1)}

In this case, "pow" is not a macro, so this will all be handled by the 
function parser, which insists on having commas.

> It isn't happy with this, either:
>
> #macro A(b(c))b+c#end

Here, POV-Ray is /not/ unhappy about the missing comma, but rather about 
the parentheses around the identifier name. It will not accept the 
following either:

#macro A(b,(c)) b + c #end

> Nor this:
>
> #macro A(b c)b+c#end
> #declare a=0;
> #declare b=A(1A(1a));

I must confess that this is a puzzler to me as well; theoretically it 
should work, but it doesn't.

> Nor this:
>
> #debug("a\n")

This is simple again: #debug expects a single string without 
parentheses. With numerical values that wouldn't make a difference, as a 
parenthesized expression is a valid numerical expression as well, but 
string expressions cannot be parenthesized. For instance, the following 
is illegal as well:

#declare MyString = concat("a", ("b"), "c");

> Why?

To teach you a habit of /always/ using commas? ;-)

Post a reply to this message