I just came across a strange limitation when trying to use variable-substitution
in a function:

#declare VAR = <2,.7,.6>;

#declare MY_FUNCTION = function(x,y,z,a,b,c) {...body of function...}

Then, attempting to use dot-notation for VAR, within the function...

isosurface{
     function{MY_FUNCTION(x,y,z,VAR.x,VAR.y,VAR.z)}
     ...
     }

But this causes a fatal error:
    "expected 'operand', vector function 'vector identifier' found instead"

I assumed that the dot-notation would work-- because the components of VAR are
all individual scalar quantities now.

I tried surrounding the individual VAR components with parentheses (to try and
'eliminate' their vector nature, similar to dot-operator use for colors when a
'non-color' value is needed) but that doesn't work either.

I'm curious to know the reason for this limitation.

Post a reply to this message

Am 30.07.2018 um 14:53 schrieb Kenneth:

> I assumed that the dot-notation would work-- because the components of VAR are
> all individual scalar quantities now.
> 
> I tried surrounding the individual VAR components with parentheses (to try and
> 'eliminate' their vector nature, similar to dot-operator use for colors when a
> 'non-color' value is needed) but that doesn't work either.
> 
> I'm curious to know the reason for this limitation.

Functions are essentially processed by a completely different parser.
Some features implemented in the normal parser never made it into the
functions parser.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> Some features implemented in the normal parser never made it into the
> functions parser.

I had a hunch that something like this was the cause (not the details, but the
general idea of functions being processed 'differently' than, for example,
colors.)

It looks like there are two ways around this problem:

1) to actually fix the situation, by implementing the dot-notation feature into
the functions parser. (I really have no idea what's involved in such a scheme,
so maybe it's a naive idea.)

2) to include a caveat in the documentation-- somewhere(!)-- about dot-notation
use in functions. Similar to the caveat concerning colors (in the docs' "Common
Color Pitfalls") but with a specific restriction about dot-notation.

Of course, it would be nice if dot-notation actually WORKED in functions ;-)
From a user's standpoint, it naively seems that it should.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> clipka <ano### [at] anonymousorg> wrote:
> >
> > Some features implemented in the normal parser never made it into the
> > functions parser.

I actually just ran across this last night - had to unravel quite a few things
to actually figure out what was wrong.

I think my first instinct might be to access the function via a macro, where the
macro first #local(ly) declares some variables
#local a = val.x;
and then uses those variables in a function call.

I ran into this while also grappling with the different interpretations of x, y,
and z (and u and v) in isosurface and parametric function blocks.  I will post a
request to clarify in another thread.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 30.07.2018 um 14:53 schrieb Kenneth:
>
> > I assumed that the dot-notation would work-- because the components of VAR are
> > all individual scalar quantities now.
> >
> > I tried surrounding the individual VAR components with parentheses (to try and
> > 'eliminate' their vector nature, similar to dot-operator use for colors when a
> > 'non-color' value is needed) but that doesn't work either.
> >
> > I'm curious to know the reason for this limitation.
>
> Functions are essentially processed by a completely different parser.
> Some features implemented in the normal parser never made it into the
> functions parser.

IIRC one can use dot notation in functions when dealing with vector valued
functions. Here's an example that works:

#include "functions.inc"
#declare T_Fn =
    function {
        transform {
            scale <3, 1, 2>
            inverse
        }
    }
#declare Ellipsoid_Fn =
    function {
        f_sphere(
            T_Fn(x, y, z).x,
            T_Fn(x, y, z).y,
            T_Fn(x, y, z).z,
            1
        )
    }

--
Tor Olav
http://subcube.com

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> 1) to actually fix the situation, by implementing the dot-notation feature into
> the functions parser. (I really have no idea what's involved in such a scheme,
> so maybe it's a naive idea.)

There is nothing to "fix" because this is not a bug. The function parser works
exactly as designed and documented.

> 2) to include a caveat in the documentation-- somewhere(!)-- about dot-notation
> use in functions. Similar to the caveat concerning colors (in the docs' "Common
> Color Pitfalls") but with a specific restriction about dot-notation.

The documentation is very clear about what is allowed in functions:
http://www.povray.org/documentation/view/3.6.1/231/

Obviously, the documentation describes only the finite set of allowed syntax
elements, not the infinite set of not allowed syntax elements.

Thorsten

Post a reply to this message

"Thorsten Froehlich" <nomail@nomail> wrote:

>
> There is nothing to "fix" because this is not a bug. The function parser works
> exactly as designed and documented.
>
> The documentation is very clear about what is allowed in functions:
> http://www.povray.org/documentation/view/3.6.1/231/
>

Oh, come on now, that's an OLD and crusty way to answer a question in the
newsgroups-- basically "RTFM", the all-encompassing fallback position-- which I
thought had been 'deprecated' by now :-P

My question was, "What is the *reason* for the [dot-notation] limitation"--
since dot-notation works in every other situation I've tried it in, to the
extent that I thought of it as a fundamental 'tool' in POV-Ray...like #declare,
for example. Clipka's answer was... reasonable. Whereas RTFM is
rather...devoid...of useful information.

But you're correct-- the documentation does not state that dot-notation works in
user-defined functions. (I truly wish I had a complete and total knowledge of
the entire contents of the documentation, along with instant recall of the
details; then I wouldn't need to ask any questions!)

> Obviously, the documentation describes only the finite set of allowed syntax
> elements, not the infinite set of not allowed syntax elements.
>

Well, it *does* mention one of the infinite set of not-allowed syntax elements:

"Note: Only the above mentioned items can be used in user-defined functions. For
example the rand() function is not available."

That last tidbit of information has always been extremely useful; but how or why
did rand() make it into the 'exceptions'?? My guess is that users kept asking
the same question over and over: "Why doesn't rand() work in functions?"

;-)

Post a reply to this message

Am 31.07.2018 um 06:56 schrieb Thorsten Froehlich:

> There is nothing to "fix" because this is not a bug. The function parser works
> exactly as designed and documented.
...
> The documentation is very clear about what is allowed in functions:
> http://www.povray.org/documentation/view/3.6.1/231/

Actually, no, it isn't, because...

> Obviously, the documentation describes only the finite set of allowed syntax
> elements, not the infinite set of not allowed syntax elements.

... obviously the syntax description itself is evidently broken (at
least in the v3.6.1 incarnation).

Most notably, `MOD_EXPRESSION` is used in `FACTOR`but isn't specified
anywhere.

Just to knock you off your perch.


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.

Post a reply to this message

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

"Kenneth" <kdw### [at] gmailcom> wrote:
> Oh, come on now, that's an OLD and crusty way to answer a question in the
> newsgroups-- basically "RTFM", the all-encompassing fallback position-- which I
> thought had been 'deprecated' by now :-P

No, expecting spoon-feeding is the socially unacceptable behavior: You
effectively say that you value your own time to solve a problem by not reading
the documentation higher than the time of others reading this newsgroup for
potentially interesting information and getting them to do the tedious task of
explaing what has already been written somewhere to you for your sole benefit.
:-)

Now, this may be ok in p.newusers, but you didn't post there, did you? ;-)

> "Note: Only the above mentioned items can be used in user-defined functions. For
> example the rand() function is not available."

Yes, that is completely odd and I have no idea why this is in the documentation.

Thorsten

Post a reply to this message