Rune wrote:
> 
> > Since it's leagal to use declared variables in functions,
> 
> When you *call* functions, not when you initiate them! At least it shouldn't
> be since it makes no sense at all.
> 
> [...]

Surely also when you initiate them, and this makes a lot of sense.

I would find constructs like the following extremely irritating:

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

I know macros work this way, but as Thorsten mentioned, they are something
completely different.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

"Christoph Hormann" wrote:
> Rune wrote:
> >
> > > Since it's leagal to use declared variables in functions,
> >
> > When you *call* functions, not when you initiate them! At least it
shouldn't
> > be since it makes no sense at all.
> >
> > [...]
>
> Surely also when you initiate them, and this makes a lot of sense.

You say it's legal an useful to use declared variables as parameters when
declaring a function. But I can't see how, as it just generates an error, as
I reported. Please post an example.

> I would find constructs like the following extremely irritating:
>
> #declare V = 0.1;
> #declare Myfunction = function (V, x) {V*x}

This should make V a parameter, unrelated to the variable V IMO.
Currently it generates an error. What's the use in that?
How do *you* think it should work?

> #declare Myfunction2 = function (x) {V*x}

This should use the variable V, and it does, so there's no problem here.

> I know macros work this way, but as Thorsten mentioned,
> they are something completely different.

I still don't see how the current behavior makes any sense!

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 <3bda9ead@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

>> I know macros work this way, but as Thorsten mentioned,
>> they are something completely different.
>
> I still don't see how the current behavior makes any sense!

Well, if you don't understand the reasoning so far, try to see it this way:

A # declared variable is just like a macro without any parameters (it really
is, also the docs don't and won't explain it that way).  So whenever POV-Ray
finds the string matching the #declared variable it will just replace it
with whatever the value of the #declared variable.

    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, if you don't understand the reasoning so far,
> try to see it this way:

Thorsten, it's not that I don't understand how function parameters work,
what I don't understand is why they're designed to work that way.

I know macros and functions are different things, but I think the parameters
in functions should work the same way as the parameters in macros. As I
said, the current implementation is a great limitation that has no
advantages at all! All it means is that you have to make sure that the names
of the parameters in your functions never are the same as any declared
variable identifiers. That gets very difficult when working with include
files containing functions made by other people. Are we really supposed to
never use function parameters with names identical to variable identifiers?

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 <3bdab763@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> Thorsten, it's not that I don't understand how function parameters work,
> what I don't understand is why they're designed to work that way.

Because POV-Ray directives are designed to work this way.  They sit "on top"
of your scene.  Contrary to macros functions are _part_of_the_scene_ and as
such are and have to be handled different from macros.

Would you expect the scene below to work as well? - It would be a
consequence of what you are asking for (as I explained above) and obviously
does not make sense!

    #declare foo = function(a,b,c)
    {
        #while(a > 0)
            (b - a) *
            #declare a = a - 1;
        #end
        c
    }


____________________________________________________
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:
> 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