> If you actually use the
> language as it is for complex tasks, you will find the separation between
> scene description and (programming) language very natural and essential
for
> the flexibility that is simply impossible otherwise.

Ironically, what I'm talking about is that same flexibility... Say, what
about using loops and switches in functions? Although I did not see the code
yet, I can only guess why, but pretty reliably -- based on the fact that you
used select() instead of simple 'arithmetic if'...

I'm sure that one day we will see functions as complex as shaders in
RenderMan. By the way, I do not think that there exist any fundamental
difficulty for that -- I know that many have branded that not feasible on
portability grounds. But -- that only applies to the solution that was
implemented in POVMan (based on POV-Ray 2.2, IIRC), which employed bytecode
compiler built with Flex/Bison. If you look at how it was done in BMRT, you
will find quite different solution, less powerful, but more portable (SL
files are not even compiled, they are, err... preprocessed :-)

So my point is -- we should not have, say, two different if's, for parse and
rendering time, but rather a single statement. If its control expression
does evaluate to a constant -- OK, it works like present #if. If it does
not -- well, it depends. If context does allow the use of functions (say, in
a height_field or an image_map), then, if we are not inside a function body
already, then that 'if' should be implicitly wrapped by the automatically
generated function (and should thus work as 'if' in Algol -- that is, return
a value). If the context does not allow that -- signal an error.

These may probably be tomorrow's solutions, but we must not render them
theoretically impossible today...

Post a reply to this message