In article <38cb9a68@news.povray.org>, Nieminen Juha 
<war### [at] sarakerttunencstutfi> wrote:

>   A more compact and clearer syntax makes the code more readable and 
> minimizes the possibility of errors.
>   For example, suppose you have this:
> 
> #declare XLoopIndex1 = 0;
> #while(XLoopIndex1 < 100)
>   ...
>   (30 lines of code)
>   ...
>   #declare XLoopindex1 = nextValue();
> #end
> 
>   When one reads the code he will most probably not remember the name of
> the loop index after reading the 30 lines of code and the typing mistake
> will most probably pass unnoticed. Povray will not issue any error since
> there's no syntax nor semantic error. However, the parsing will perform 
> an endless loop.

I suppose this is a good place to bring up another feature I have been 
thinking of. It has bothered me for some time that the same keywords 
that create variables are used to modify them, maybe a #set directive 
should be added. It would act exactly like #declare or #local, except it 
would produce an error if handed an undefined identifier. The keyword 
would always use the most local version of the identifier, of course, 
and local variables would stay local, and #declared variables would act 
as if you used #declare. This also would be backward compatible, 
#declare and #local could still be used to modify variables, it just 
would mean more typing, less clear code, and harder debugging.
That code would be rewritten:
#declare XLoopIndex1 = 0;
#while(XLoopIndex1 < 100)
  ...
  (30 lines of code)
  ...
  #set XLoopindex1 = nextValue();
#end
The #set would produce an error, since XLoopindex1 is not defined. And 
POV would not go into an infinite loop, and you could tell exactly what 
the problem was by looking at the error message.


>   Compare it to this:
> 
> #for ( XLoopIndex1 = 0; XLoopIndex1 < 100; XLoopindex1 = nextValue )
>   ...
>   (30 lines of code)
>   ...
> #end
> 
>   Now since all the commands related to the loop index are at the same 
> line, noticing the typing mistake is more probable.
>   Also understanding the functionality of the loop is much easier to see 
> now, since you don't have to search for the end of the loop to see 
> how does the loop index change.

This alone is a perfectly good reason for adding a #for loop, in my 
opinion.


>   Also this new syntax would be very handy sometimes:
> 
> #do
>   ...
> #until(whatever)
> 
>   There really are times, where you want to execute the body of the loop 
> at least once before the ending condition is tested (for example the 
> condition is calculated in the body of the loop).
>   With the current #while-loop you would have to calculate the condition
> in two places: First before the loop, and then inside the loop. 
> Copying the same code to several places is not a good thing.

I actually have run into this situation a couple times with POV. 
Debugging and extending two separate yet nearly identical chunks of code 
is *not* fun. This loop structure would probably be even easier to add 
then #for(), since it is basically a backwards #while() loop.


> In a similar way the +=, -=, etc. operators will allow to avoid 
> copying of code to several places (specially if the variable to 
> modify is a very long statement).

And maybe -- and ++ operators. I am really not sure about these, they 
don't exactly enhance readability except in highly compact code which 
you are unlikely to attempt in POV(all those # signs and #end's make the 
language too bulky to write highly compact code that is still readable). 
They probably would not be very useful, especially since I don't think 
separate prefix and postfix notations would be possible in the POV 
language(CSDL would be different, of course).


> : Can GOTO be far behind?
> I don't think that goto will be needed. I do think that #break and 
> #continue statements inside a loop would be handy.

There is a #break statement for switch statements, and from the 
description, it doesn't seem like it would be too difficult to extend to 
#if statments and loops. Maybe even macros(have you ever wanted to jump 
out of a macro early?)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message