In article <39A30BD5.5E049847@club-internet.fr>, Francois Dispot 
<woz### [at] club-internetfr> wrote:

> Being able to call finctions would be great, and would also suppress the
> need for texture or pigment evaluation...

Do you mean using eval_pattern() or eval_pigment() to extract the value? 
This makes it possible to evaluate functions in the current version, but 
would break with variable numbers of parameters.


> About the "if" function, it could also be possible to have something
> like the well-known cryptic a?b:c syntax.

Why? Like you said, it is cryptic. I personally avoid it like goto or 
the plague. :-)


> Adding local variables and loops would probably make things quite
> different. Could you elaborate on a possible syntax? Did you think about
> some lisp-like or RPN (a la PostScript) method?

The syntax would be very similar to ordinary POV, and in ways more 
similar to C...I don't know what Lisp is like, and definitely not RPN(if 
you mean Reverse Polish Notation, I don't know PostScript either). Just 
something like this:

#declare MyFunc =
function (V, Oct, A){
    var Ctr = 0;
    var O = 0;
    var Result = 0;

    if(Oct <= 0)
        O = 1;
    else
        O = Oct;
    endif// or maybe use {} blocks
    
    while(Ctr < O)
        Result += sin(O*V);
        newVal += 1;
    endwhile

    Result/O
    // or
    return A*(Result/O);
};

#declare Value = MyFunc(clock, 4, 1.4);

I really am not sure about the return syntax...the first one would 
maintain compatibility with existing functions, but might make the 
parser harder to write(and it looks funny if you are used to programming 
in C). Maybe the return value should be the first expression not 
preceded by an expression which is using it, and not followed by =, +=, 
-=, --, or ++. So if the parser encounters an equation is just sitting 
there alone, not being used as input to if(), while(), or anything, or a 
variable which is not being modified, it would be used as the return 
value.
And maybe it should use #if(), #while(), etc. for consistency with the 
rest of the language.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> You don't need a macro for this, a plain old function will do fine.
>
> #declare Heaviside = function {if(x - y, 1, 0)}
> // x=the value, y=the jump threshold, z=nothing

I was wondering about the macro, that would make it more general, but,
as has been demonstrated, they cannot be used inside functions :-)

Thanks to all, I got exactly what I needed, one-stop shopping :-))

Post a reply to this message

On Tue, 22 Aug 2000 21:53:40 -0500, Chris Huff wrote:
>Maybe the return value should be the first expression not 
>preceded by an expression which is using it, and not followed by =, +=, 
>-=, --, or ++. So if the parser encounters an equation is just sitting 
>there alone, not being used as input to if(), while(), or anything, or a 
>variable which is not being modified, it would be used as the return 
>value.

Perl uses the value of the last evaluated expression as the return value.
Could that work?

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> Perl uses the value of the last evaluated expression as the return value.
> Could that work?

It might, I think...does it just return at the end of the function with 
the value of the last expression, or is there an equivalent to the 
"return" statement in C?
It could be useful to have any "orphan" expression force a return with 
the value of that expression if it is reached, that would allow multiple 
exit points. Or maybe that isn't a good idea...I have found it sometimes 
makes cleaner code, but I have also heard it isn't good programming 
style. And constantly checking every expression for the returning 
conditions might slow things down, but maybe a "return" statement could 
be inserted at parse-time so the checking doesn't have to be done at 
run-time...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-73EA9B.08380023082000@news.povray.org...
> In article <slr### [at] fwicom>, ron### [at] povrayorg
> wrote:
>
> > Perl uses the value of the last evaluated expression as the return
value.
> > Could that work?
>
> It might, I think...does it just return at the end of the function with
> the value of the last expression, or is there an equivalent to the
> "return" statement in C?

Both - it will return the last evaluated expression or you can use "return
$foo", so

sub foobar{
    $foo = 1;
    return $foo;
}

is the same as

sub foobar{
    $foo = 1;
}

Post a reply to this message

On Wed, 23 Aug 2000 08:38:00 -0500, Chris Huff wrote:
>In article <slr### [at] fwicom>, ron### [at] povrayorg 
>wrote:
>
>> Perl uses the value of the last evaluated expression as the return value.
>> Could that work?
>
>It might, I think...does it just return at the end of the function with 
>the value of the last expression, or is there an equivalent to the 
>"return" statement in C?

Yes.

That is, it does both.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> Yes.
> 
> That is, it does both.

This sounds like a good compromise. :-)
Now, just have to figure out how to write it...I don't understand much 
of the isosurface code at all, hopefully the function stuff will be 
separated out and cleaned up in 3.5.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message