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

Jamie Davison <jam### [at] dh70qdu-netcom> wrote:
: By better, I assume you mean more like other, established general purpose 
: programming languages, e.g. C, C++?

  Nope. I mean more modular and more intuitive and easy-to-use but powerful
features. Also more complicated but even more powerful features could be
good (two completely different examples of this: Perl and Prolog).

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

  Why should the user optimize by hand when povray could do it automatically?

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

: #if(ACondition & DoSomething()) #end

  But you can already make pretty obfuscated code with povray. Just consider
something like this:

#local L=array[4800] #local Y=-2; #local I=0;
#while(#local X=-2;
#while(#local Zr=X; #local Zi=Y; #local N=0;
#while(#local A=Zr*Zr; #local B=Zi*Zi;
#local Zi=2*Zr*Zi+Y; #local Zr=A-B+X;
#local N=N+1; N<20&A+B<2) #end
#local L[I]=<X,N/40,Y>;
#local X=X+.05; #local I=I+1; X<=1) #end
#local Y=Y+.05; Y<=2) #end
union
{ #local I=0; #while(I<4800) sphere{L[I],.05} #local I=I+1; #end
  pigment { rgb x } finish { specular .5 }
}
camera { location <-2,2,-2> look_at 0 }
light_source { <0,20,-10>, 1 }


  Avoiding a feature only because you CAN make obfuscated code with it is
not a good principle.
  If that had been the principle in povray, its scripting language would not
be as versatile as it is now (and things like macros would have been had to
be implemented in a completely different way as it is now).

  If povray can optimize the speed of the parsing, that's only a good thing.

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

Jamie Davison <jam### [at] dh70qdu-netcom> wrote:

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

Or he could mean better as in making the obvious logical steps that can save
time and energy for everyone.  Or maybe making the parsing of the syntax
smarter and not doing stupid, unnecessary operations.

But that's probably me.

Geoff

Post a reply to this message