clipka <ano### [at] anonymousorg> wrote:
> Am 31.07.2018 um 06:56 schrieb Thorsten Froehlich:
> Most notably, `MOD_EXPRESSION` is used in `FACTOR`but isn't specified
> anywhere.
>
> Just to knock you off your perch.

LOL, I noticed that bug as well.

> That said, "as designed and documented" doesn't necessarily mean that
> it's free from issues that might warrant fixing. It might just be that
> there's a problem with the design.
>
> And I for one would argue that that's indeed the case (presuming dot
> notation has been excluded from functions by design rather than by
> oversight). Because - evidently - this behaviour goes against user
> expectations.

It is logically correct in a properly (given you worked on the tokenizer you
know what I mean) designed parser: Functions cannot access declared values
because functions persist after parsing. This would require substituting the
preprocessor-level declared variable with the value of the variable. This value
would be a vector, which isn't supported.

However, such an overload isn't desireable because you also have a namespace
collision. Given a user may declare any variable, and given the user may also
provide variable names for function arguments, you end up with another catch:
Either you blindly substitue declared values everywhere in a function, you do
not substitute in argument lists, you make exceptions to substitutions by giving
the argument namespace precedence over the declared values (and then you need to
access the whole preprocessor mess including local declares and macro
arguments!), or you just outright prohibit the preprocessor in functions.

The last approach was chosen because it also eliminates the macro "problem".

In essence, the function parser isn't the real problem. It only exposes the
design weakness of declares and macros in POV-Ray's SDL. The section on the
nature of macros isn't in the documentation by accident after all :-)

Post a reply to this message