Jamie Davison wrote:
> 
> Because not everybody on these groups, or indeed everybody who uses POV,
> is experienced in, or capable of reading C style code.
> 
> I have enough trouble reading POV code as it is, and adding (more)
> abstract symbols to the scene description language would kill my ability
> to understand roughly what is happening in a scene file.
> 

The proposed change would add nothing to the scene language; it would change the
way an existing operator is parsed.
Frankly, the way it works now initially caused more confusion for me, since I
did not see the point in evaluating the second part of the conditional, if the
whole condidtional was already bound to return "false".

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

Chris Huff wrote:
> 
> If that extremely_long_calculation sets up some variables for later use,
> not evaluating it could lead to obscure bugs in scene files.

Hmm. Are there many likely scenarios of this happening?
Granted, a macro invoked in a conditional could #declare variables needed later
in the code; but creating necessary variables like this is very bad form IMO, as
is (generally) using #declare in a macro to set up global variables.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

In article <3A15CA5E.DC4C415C@peak.edu.ee>, Margus Ramst 
<mar### [at] peakeduee> wrote:

> Hmm. Are there many likely scenarios of this happening?

Not a lot, but I see no reason to add something that can cause such 
confusion and would only have a slight benefit.


> Granted, a macro invoked in a conditional could #declare variables 
> needed later in the code; but creating necessary variables like this 
> is very bad form IMO, as is (generally) using #declare in a macro to 
> set up global variables.

It might be bad form, but it is possible and is sometimes the easiest 
way to do things. Remember that not all POV users are programmers who 
care about good form...this would just be considered a nuisance by them. 
And I think it is "bad form" for a language to do this type of thing, 
because there is no indication of what is happening when it occurs. It 
can be done manually, and can cause problems when done automatically.

Maybe if there was a warning when a macro call was skipped, or if it 
only skipped things other than macro calls...

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

Jamie Davison <jam### [at] dh70qdu-netcom> wrote:
: Sorry if I'm ranting, but I get a little fed up of seeing people trying 
: to turn POV into a programming language, when, in my opinion, it isn't 
: and shouldn't be.

  But the povray scripting language IS a programming language (since it's
Turing-strong).
  Making it a better programming language can make only good.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: Not a lot, but I see no reason to add something that can cause such 
: confusion and would only have a slight benefit.

  I see many reasons to add something that has so many benefits although
it might rarely sometimes cause some confusion.

  Things can always be said in two ways :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
> Chris Huff <chr### [at] maccom> wrote:
> : Not a lot, but I see no reason to add something that can cause such
> : confusion and would only have a slight benefit.
> 
>   I see many reasons to add something that has so many benefits although
> it might rarely sometimes cause some confusion.
> 
>   Things can always be said in two ways :)

Now I'm confused !

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

On 20 Nov 2000 05:22:15 -0500, Warp wrote...
> : Sorry if I'm ranting, but I get a little fed up of seeing people trying 
> : to turn POV into a programming language, when, in my opinion, it isn't 
> : and shouldn't be.
> 
>   But the povray scripting language IS a programming language (since it's
> Turing-strong).
>   Making it a better programming language can make only good.

By better, I assume you mean more like other, established general purpose 
programming languages, e.g. C, C++?

Personally, that doesn'y fit my definition of 'better'  But that's 
probably just me.

Of course it's entirely possible that I'm misinterpreting something 
somewhere along the lines.

Bye for now,
     Jamie.

Post a reply to this message

On Fri, 17 Nov 2000 17:56:05 -0600, David Fontaine wrote:
>because you don't need to read ahead or look at indentation to see that you're
>limiting a to an interval (0,10) (or is that [0,10]?). Same goes for a

(0,10)

>non-contigous set:
>  #if((a>0 & a<10) | a>20 | a=15)
>Imagine that coded as individual tests!

I think you might be missing the important point here: we currently have and
and or operators, but they don't short-circuit.  The result is that you
can't say things like

#if ( a != 0 and 5/a > 2 )

because the parser will puke on 5/a if a really is zero.

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

Post a reply to this message

In article <3a18fc06@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   I see many reasons to add something that has so many benefits although
> it might rarely sometimes cause some confusion.

What benefits? A small parsing speedup every once in a while, and more 
rarely a fairly large speed improvement. And this can already be 
accomplished by using a slightly different structure with the current 
language, by nesting the conditionals.

Oh, and it lets you write nicely obfuscated code that doesn't do what it 
appears to do, like this:

#if(ACondition & DoSomething()) #end

which would really be the same as this:

#if(ACondition)
    DoSomething()
#end

So, no real benefits, since what it does can easily be done manually 
already, and it adds possible confusion.

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

Ron Parker wrote:

> #if ( a != 0 and 5/a > 2 )
>
> because the parser will puke on 5/a if a really is zero.

Hmm, didn't think of that scenario...

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message