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

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

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

Because it can't be done automatically without breaking certain things 
or leading to odd behavior that isn't intuitive from reading the code...


>   Avoiding a feature only because you CAN make obfuscated code with it is
> not a good principle.

I did not say that. I meant that the fact that you can make obfuscated 
code with it is not a good reason to add it. It was intended as a joke, 
because you seem to like doing that kind of thing. :-)


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

Not if it complicates things unnecessarily. If a user puts a call to a 
macro with a side effect in the code, he will expect the macro to be 
called. Note: users are not always programmers or software designers, 
don't expect them to always avoid something that is "bad style". They 
just want things to do what they are told. The error caused when this 
optimization is done to a macro with a side effect is one that would be 
extremely difficult to track down unless you already know where to look 
for it.

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

Warp wrote in message <3a1a3c21@news.povray.org>...
>
>#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 }


Nice mandelbroit.

--
Mark

Post a reply to this message

David Fontaine wrote:

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

It is the same kind of thing as my original example.
--
Bye
Pabs

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: Not if it complicates things unnecessarily. If a user puts a call to a 
: macro with a side effect in the code, he will expect the macro to be 
: called.

  If the user is so advanced that he knows how to make macros with side
effects and how to use them in complicated places (such as inside an
#if conditional), he has probably already very familiar with the povray
code (and he has probably read the documentation about all the commands).
  If the behaviour is clearly and well documented, it shouldn't cause
problems.

-- 
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 in message <3a1bce46@news.povray.org>...
>
>  If the user is so advanced that he knows how to make macros with side
>effects and how to use them in complicated places (such as inside an
>#if conditional), he has probably already very familiar with the povray
>code (and he has probably read the documentation about all the commands).
>  If the behaviour is clearly and well documented, it shouldn't cause
>problems.


Are you offering to handle tech support for this new feature?

--
Mark
"The derivative of sin(2x) is cos(2x)"  - Matt Giwer

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote:
: Are you offering to handle tech support for this new feature?

  Does this mean that if someone suggests a new feature, he should also
offer tech support for that feature?
  Does it mean that if the person who has the suggestion doesn't want to
do it, he should not make the suggestion?

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

On Thu, 23 Nov 2000 02:57:27 -0500, Mark Wagner wrote:
>Warp wrote in message <3a1bce46@news.povray.org>...
>>
>>  If the user is so advanced that he knows how to make macros with side
>>effects and how to use them in complicated places (such as inside an
>>#if conditional), he has probably already very familiar with the povray
>>code (and he has probably read the documentation about all the commands).
>>  If the behaviour is clearly and well documented, it shouldn't cause
>>problems.
>
>
>Are you offering to handle tech support for this new feature?

Isn't that why we hired him? :)

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

Post a reply to this message