POV-Ray : Newsgroups : povray.beta-test : Function parameter bug Server Time
30 Jul 2024 20:24:57 EDT (-0400)
  Function parameter bug (Message 6 to 15 of 25)  
<<< Previous 5 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Thorsten Froehlich
Subject: Re: Function parameter bug
Date: 27 Oct 2001 05:48:55
Message: <3bda8307@news.povray.org>
In article <3bd9fd4e@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> But shouldn't the parameters use a different name-space than things declared
> outside of the functions, just like it works with macros?

No, because one is the scene level and the other the parser level.  The
parser values are inserted first by substituting every variable you
declared.  The resulting scene file (which is invisible to you) is the
passed on the the actual parser which only sees the 0.1 as it should because
the "V" has been substituted by "0.1" as you requested.

You mistake is part of the functions are no macros misunderstanding!


    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

From: Rune
Subject: Re: Function parameter bug
Date: 27 Oct 2001 05:51:37
Message: <3bda83a9$1@news.povray.org>
"Christoph Hormann" 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.

Take a macro:

#declare V = 0.1:
#macro MyMacro(V) V*2 #end
sphere {x, 0.1}

Here's there's no problem since the parameter in the macro doesn't conflict
with already declared variables. You can still call the macro with the
declared variable and *then* it will be used:

#declare B = MyMacro(V);

But with functions a conflict happens at the time of declaring the function
and that's all wrong.

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

From: Rune
Subject: Re: Function parameter bug
Date: 27 Oct 2001 05:51:39
Message: <3bda83ab$1@news.povray.org>
"JRG" wrote:
> But why bother? Just use another identifier.

To use long cryptic parameter names and/or variable names just to avoid a
name conflicts is not an acceptable solution. You can never know if some
include file uses the same name you're using for your variables.

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

From: Thorsten Froehlich
Subject: Re: Function parameter bug
Date: 27 Oct 2001 06:06:07
Message: <3bda870f@news.povray.org>
In article <3bda83a9$1@news.povray.org> , "Rune" 
<run### [at] mobilixnetdk> wrote:

> When you *call* functions, not when you initiate them! At least it shouldn't
> be since it makes no sense at all.
>
> Take a macro:
>
> #declare V = 0.1:
> #macro MyMacro(V) V*2 #end
> sphere {x, 0.1}
>
> Here's there's no problem since the parameter in the macro doesn't conflict
> with already declared variables. You can still call the macro with the
> declared variable and *then* it will be used:
>
> #declare B = MyMacro(V);
>
> But with functions a conflict happens at the time of declaring the function
> and that's all wrong.

Repeat after we:

Functions are not macros.  Functions are not macros.  Functions are not
macros.  Functions are not macros.   Functions are not macros. ...

    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

From: Rune
Subject: Re: Function parameter bug
Date: 27 Oct 2001 06:09:18
Message: <3bda87ce@news.povray.org>
"Thorsten Froehlich" wrote:
> The parser values are inserted first by substituting
> every variable you declared.

But it doesn't make sense to have parameters that are constant! And indeed
an error is generated as I reported! The *only* result of the way it woks
now is apparently that parameter names cannot use the same name as declared
variables and that's *very* inconvenient, as it's very common to use
one-letter names for both variables and for function parameters.

> You mistake is part of the functions are no macros misunderstanding!

But what's the logic behind how it works? It seems to be a big limitation
that have no positive effects at all...

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

From: Christoph Hormann
Subject: Re: Function parameter bug
Date: 27 Oct 2001 06:10:14
Message: <3BDA8806.676946E0@gmx.de>
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

From: Rune
Subject: Re: Function parameter bug
Date: 27 Oct 2001 07:46:53
Message: <3bda9ead@news.povray.org>
"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

From: Thorsten Froehlich
Subject: Re: Function parameter bug
Date: 27 Oct 2001 08:12:32
Message: <3bdaa4b0@news.povray.org>
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

From: Rune
Subject: Re: Function parameter bug
Date: 27 Oct 2001 09:32:19
Message: <3bdab763@news.povray.org>
"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

From: Thorsten Froehlich
Subject: Re: Function parameter bug
Date: 27 Oct 2001 09:59:09
Message: <3bdabdad@news.povray.org>
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

<<< Previous 5 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.