 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 31.07.2018 um 20:31 schrieb Thorsten Froehlich:
>> 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.
I don't see an issue there.
It would be a valid point if the dot operator were to be implemented as
an operation in the function VM.
However, since we are talking about `SDL_VARIABLE.x` (and siblings)
here, and not `FUNCTION_PARAMETER.x`, I see no sound reason why the
function parser couldn't resolve the operation at parse-time.
The rule would be pretty simple:
If the token is an SDL variable holding a vector or colour, take a peek
at the next token. If that token is a dot, expect a component name, and
inject the respective value into function. If the token is not a dot (or
the component name is invalid), raise an error.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <nomail@nomail> wrote:
>
> No, expecting spoon-feeding is the socially unacceptable behavior...
Ah, the ol' spoon-feeding reposte.
Well, even Einstein had to be spoon-fed every now and then (by Marcel Grossman)
with arcane maths knowledge that he didn't know. If MC had used the "RTFM"
method instead, we may never have had the General Theory Of Relativity! (ha!)
>
> > "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.
>
But don't take it out!!
And add dot-notation.
:-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> Ah, the ol' spoon-feeding reposte.
>
Oops.
"riposte"
If I'm going to use a high-brow literary word, I guess I should first learn how
to spell it... :-O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> If I'm going to use a high-brow literary word, I guess I should first learn how
> to spell it... :-O
Yeah. That's the Epi-TOME of ignorance. :D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> I don't see an issue there.
Well, I implemented that part of the parser, and I do ;-)
> It would be a valid point if the dot operator were to be implemented as
> an operation in the function VM.
The dot operator isn't the problem. The preprcessor declares, locals and macro
argument names are.
> However, since we are talking about `SDL_VARIABLE.x` (and siblings)
> here, and not `FUNCTION_PARAMETER.x`, I see no sound reason why the
> function parser couldn't resolve the operation at parse-time.
>
> The rule would be pretty simple:
>
> If the token is an SDL variable holding a vector or colour, take a peek
> at the next token. If that token is a dot, expect a component name, and
> inject the respective value into function. If the token is not a dot (or
> the component name is invalid), raise an error.
Good luck trying. You end up making a copy of most of the identifer parser code
to support this, with lots of modifications to code that is already one of the
most fragile pieces of the regular parser, just to exclude macros and other
unwanted features getting in the way. Of cource it would "work", just that the
code would be a nightmare to support.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
