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