"Thorsten Froehlich" wrote:
> Would you expect the scene below to work as well?

I don't ask for a change of the part between the {...} brackets, all I ask
is that the function parameters are made local to the function so they don't
conflict with existing variables.

Consider this code:

#declare A = 0.1;
#declare foo = function(A) {A*2}

Now when the parser reaches function(A) it "calls" the already declared
variable A and then generates an error.

Then consider this code:

#declare foo = function(C) {C*2}
#declare D = C;

Here C has not been already declared and thus the function can use C as a
parameter. That must mean that C is somehow being #declared by the function
when the function is parsed. But after the function has been declared the
variable C is not available anymore, as can be seen when attempting to
render the line #declare D = C;. That must mean that C is local to the
function.

All I'm asking is that functions *always* create local variables for the
parameters, no matter if existing variables exist that have the same name as
the function parameters. Wouldn't that be more logical? And would't it be
possible to implement?

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

Post a reply to this message

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

> All I'm asking is that functions *always* create local variables for the
> parameters, no matter if existing variables exist that have the same name as
> the function parameters. Wouldn't that be more logical? And would't it be
> possible to implement?

You still did not understand which means I am not able to explain it well
enough :-(

What you are assuming is that function variables have a scope within the
parser like #declared variables have.  But they do not have any scope at
all!  They are not part of the parser and its #declared variables.  If they
had a scope in the context of the parser as you expect them to have (because
otherwise the #declared values could not be "hidden" inside functions) the
example I gave would be valid, but it is not and cannot be valid without
changing the fundamentals of what functions are (it would make them to
macros).  Let me try a different example (based on some other discussion
that took place in this groups recently).  It shows a problem the change you
are asking for would create (unless it would be made illegal).  I hope it
illustrates the problem of adding function parameters to any parser level
scope:

#declare foo = function(a,b,c)
{
    a +
    #declare b = 5;
    c + b // What is 'b' now assuming either model of operation???
}

Currently the answer is:  'b' will be substituted by '5'

You ask for:  It should either remain 'b' or be an error.  Neither makes
              sense to me.  I hope neither makes sense to you and it
              explains the problem with adding a scope for function
              parameters to the parser.

____________________________________________________
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:
> You still did not understand which means I am not able
> to explain it well enough :-(

I still don't understand I'm afraid. In this one-line example:

#declare foo = function(C) {C*2}

C is not defined before the function. C *is* defined inside the function
{...} brackets. C is not defined after the function brackets. If that
doesn't mean that C is local to the function, then what does it mean?

> #declare foo = function(a,b,c)
> {
>     a +
>     #declare b = 5;
>     c + b // What is 'b' now assuming either model of operation???
> }
>
> Currently the answer is:  'b' will be substituted by '5'

That's what I want too. Only if B is declared *before* the function it
shouldn't affect the function, like here:

> #declare b = 5;
> #declare foo = function(a,b,c)
> {
>     a + c + b // What is 'b' now assuming either model of operation???
> }
> #declare q = foo(7,8,9)

In this example an error occurs, but I would like the b in the function to
be substituted with the b parameter fed to the function when it is invoked
(ie. 8), not the b variable declared before the function.

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

Post a reply to this message

I think I see the problem here. The code

  #declare V = 0.1;
  #declare Myfunction = function (V) {V*2}
  sphere {x, V}

is internally transformed into something like

  #declare Myfunction = function (0.1) {0.1*2}
  sphere {x, 0.1}

But why can't the parser transform it into something like this instead?

  #declare Myfunction = function (Myfunction_V) {Myfunction_V*2}
  sphere {x, 0.1}

Post a reply to this message

"Anders K." wrote:
> But why can't the parser transform it into something
> like this instead?
>
>   #declare Myfunction = function (Myfunction_V) {Myfunction_V*2}
>   sphere {x, 0.1}

Yeah, that's what I mean too.

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

Post a reply to this message

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

> "Thorsten Froehlich" wrote:
>> You still did not understand which means I am not able
>> to explain it well enough :-(
>
> I still don't understand I'm afraid. In this one-line example:
>
> #declare foo = function(C) {C*2}
>
> C is not defined before the function. C *is* defined inside the function
> {...} brackets. C is not defined after the function brackets. If that
> doesn't mean that C is local to the function, then what does it mean?

Sorry, if you still ask this question than I failed and I am unable to
explain it better.  Sorry!


    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

Rune <run### [at] mobilixnetdk> wrote:
: #declare foo = function(C) {C*2}

: C is not defined before the function. C *is* defined inside the function
: {...} brackets.

  Nope, it isn't. Not from the point of view of the parser. It is not an
identifier which the parser sees.
  That 'C' has become a variable in the function evaluation engine, which is
a completely different beast than the parser. The parser doesn't know anything
about functions, and the function handler doesn't know anything about the
parser. The parser has no notion of a variable/identifier called 'C'.
  In the same way if you had declared an identifier called 'D', then the
*parser* sees and recognizes that 'D', but the function handler is completely
unaware of it (the parser can give the function the value of 'D', but the
function handler doesn't see 'D' in any way).

  Think about the function definition (what is inside { and }) as a string
which is just raw data to the parser unless it contains something the
parser recognizes (eg. a previously declared identifier).

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

"Thorsten Froehlich" wrote:
> Sorry, if you still ask this question than I failed
> and I am unable to explain it better.  Sorry!

Anyway, if it can't be fixed, I presume that means that all functions in
include files have to use very special names for the parameters to minimize
the risc that the user has variables with identical names.

For example these functions from math.inc:

#declare sind = function (V) {sin(radians(V))}
#declare adj_range2 = function (V, Mn, Mx, OMn, OMx) {((V - Mn)/(Mx -
Mn))*(OMx - OMn) + OMn}

must be changed to something like:

#declare sind = function (__V) {sin(radians(__V))}
#declare adj_range2 = function (__V, __Mn, __Mx, __OMn, __OMx) {((__V -
__Mn)/(__Mx - __Mn))*(__OMx - __OMn) + __OMn}

Is that really so?

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

Post a reply to this message

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

> must be changed to something like:
>
> #declare sind = function (__V) {sin(radians(__V))}
> #declare adj_range2 = function (__V, __Mn, __Mx, __OMn, __OMx) {((__V -
> __Mn)/(__Mx - __Mn))*(__OMx - __OMn) + __OMn}
>
> Is that really so?

I think the naming you have is nearly failsafe.  You could also check if the
variables used in math.inc have been declared and then simply output to
#error (which may or may not be 'fixed' for beta 7).

    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

"Warp" wrote:
>   Think about the function definition (what is inside
> { and }) as a string which is just raw data to the parser
> unless it contains something the parser recognizes (eg. a
> previously declared identifier).

Ok. Could you say that the parser has "first rights" to see the code, and
only afterwards the function engine gets to see the code? Thus, if something
is named similar to both a variable and a parameter, it's the variable that
counts?

Is that correctly understood?

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

Post a reply to this message