POV 3.5 RC5 icl on WinNT Sp 6 PII 233 with 128 MB

In the joungle of reports I don't remember such case:

#local C=0;
#local inc=function(C){C+1};

Is this supposed to work or not ? It not works with becouse of error message
"'parameter identifier' expected". I looked in chapters about functions for
'parameter identifier' but can't find any appropriate note so expect it has
similiar behavior to macro parameters.

ABX

Post a reply to this message

Skiba <abx### [at] babilonorg>  wrote:

> #local C=0;
> #local inc=function(C){C+1};
>
> Is this supposed to work or not ? It not works with becouse of error message
> "'parameter identifier' expected". I looked in chapters about functions for
> 'parameter identifier' but can't find any appropriate note so expect it has
> similiar behavior to macro parameters.

Well, "C" is a parse time constant so it will of course as one would expect be
substituted for its value:

    #local inc=function(0){0+1};

The is exactly the same way as it works for every other scene (time) object.
Remember that functions are *not* macros but just another 'object' type!

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> Well, "C" is a parse time constant so it will of course
> as one would expect be substituted for its value

But as mentioned before that's extremely inconvenient, as it means that
you have to chose your function parameters with care so that they don't
interfere with variables that are already used.

> The is exactly the same way as it works for every
> other scene (time) object.
> Remember that functions are *not* macros but just
> another 'object' type!

But other scene objects don't have user-defined parameters. If I have
understood correctly, the parameters in macros are local to the macros,
so they don't interfere with parameters of the same names outside of the
macro definition. This makes it simple to choose parameter names in
macros, because any names can be chosen. Design-wise I don't see what
prevents function parameters to work the same way as macro parameters.
It sure would be much more convenient. But if it's an internal
limitation, then of course there's nothing to do about it.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated May 20)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

In article <3cf23481@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> Design-wise I don't see what
> prevents function parameters to work the same way as macro parameters.
> It sure would be much more convenient. But if it's an internal
> limitation, then of course there's nothing to do about it.

Well, #declares and #macros are processed first, that is why they can be
inserted everywhere with very few restrictions.  The parser cannot know
something has been subsituted by either a macro or a declared value because
that is exactly the point of these directives.  They build the scene the
parser reads.  It is similar to not being able to declare keywords as names.
Function parameters behave just like user defined keywords would in this case.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> Well, #declares and #macros are processed first, that
> is why they can be inserted everywhere with very few
> restrictions.  The parser cannot know something has
> been subsituted by either a macro or a declared value
> because that is exactly the point of these directives.

But macro parameters don't interfere with #declared variables. What is
it that makes it impossible to make function parameters work the same
way as macro parameters?

This works fine:

#declare C = 0;

#macro Macro (C) C+1 #end

You don't get an error saying, "Expected 'parameter identifier', float
function 'float identifier' found instead".

But this doesn't work:

#declare C = 0;

#declare Function = function(C){C+1}

Here you get the error, "Expected 'parameter identifier', float function
'float identifier' found instead".

I know that functions are not macros, but that in itself is not an
excuse to make something less userfriendly than it could be. Do we agree
that if it wasn't for some internal limitation, it would be optimal if
function parameters could work similarly to macro parameters? If we do
not agree on that, then I probably have misunderstood you...

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated May 20)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

In article <3cf23e9d@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

>  Do we agree
> that if it wasn't for some internal limitation, it would be optimal if
> function parameters could work similarly to macro parameters?

No, we don't agree here.  The current solution is optimal as far as separation
between directives and scene description objects go.  They are on two
completely separate levels where the directive level of the language is
defined to be applied prior to reading the scene as description of a "world"
as it is.  In a sense it is the "are macros functions or macros" question as
noted in the docs.  Basically the same is true here as far as we are dealing
with "real" functions here.  So #declares work just like macros and do
interact with #macros on one level but functions are on another.

I am not really sure I am explaining it very well though...

    Thorsten

Post a reply to this message