Matt Giwer <jul### [at] ijnet> wrote:
: 	Introducing additional syntaxes raises more problems than it
: solves.

  I don't think so.
  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.

  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.

  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.

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

: 	Next, complex conditional if then else statements.

  What's this?

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

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

Post a reply to this message

Ken wrote:
> 
> Greetings,
> 
>   As we all know the language used by POV-Ray is not only easy to use
> but offers a lot of flexibility. There are often many ways to describe
> an object or attribute of an object because of the "looseness" of
> it's language.
> 
>  Now many in the past have argued that it is too primitive for thier
> needs and suggest that it become more of an official programming
> language. They also suggest it should become more object oriented
> or stricter rules should be applied to the language from what it is
> now. Some say the syntax is too loose for all practical purposes.
> Some even suggest it should move to a binary format that needs to
> be compiled before being parsed (heaven forbid).
> 
>  I say the one thing that attracted me to POV-Ray was the fact that
> it's text based input was both easy to learn, was intuitive from the
> beginning, and I never had to learn a programmers language to use
> the program. I like the way that you can describe something in several
> ways to achieve the same results. In my opinion this loose and very
> flexible language makes it a very powerful program to use.
> 
> Would you have difficulty re-learning POV-Ray if it's language format
> changed ?
> Would you resent it or maybe even quit using the program completely ?

Ken, if I had to re-learn the language, then it would probably be a
fairly large inducement for me to change over to RenderMan. One of
the reasons I like POV-Ray is that it is much easier to use (and
has a quicker turnaround time, if you're using the procedural RI
API) than RenderMan. It's easier to get raytracing effects, too.
However, if everything I know about POV-Ray (and admittedly it isn't
as much as I'd like) were thrown out in the street, then I'd
look around.

Post a reply to this message

You are right.
  However I think there are some places where the use of goto (at least in
C and C++) is more or less reasonable:

- Case 1:

  for(cond1)
    for(cond2)
      while(cond3)
        if(skip) goto end_loops;

end_loops:
  ...

- Case 2:

recalculate_initial_values:
  make_some_calculations;
  for(cond1)
    for(cond2)
      while(cond3)
        if(wrong_values) goto recalculate_initial_values;

- Case 3:

  calculation1;
  if(error) goto end_calculations;
  calculation2;
  if(error) goto end_calculations;
  calculation3;
  if(error) goto end_calculations;
  calculation4;
  if(error) goto end_calculations;

  handle_results;

end_calculations:
  clean_up;


  However, I haven't needed the goto-statement in years, though (and I make
a LOT of C++ code). I can only deduce that usually goto is not needed.

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

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote:
: I think union could be used for this if the ability to bind variables 
: and macros to objects was added. I would also like to see a pointer-like 
: feature added(with checking for valid accesses, of course). I think this 
: is what you meant by "reference-type data types". Probably something to 
: think about for POV 4.0...(or 4.1) :-)

  Yes, a pointer type, but a limited one. More like a reference type in Java.

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

Post a reply to this message

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

Nieminen Juha wrote:

>   You are right.
>   However I think there are some places where the use of goto (at least in
> C and C++) is more or less reasonable:
>
> - Case 1:
>
>   for(cond1)
>     for(cond2)
>       while(cond3)
>         if(skip) goto end_loops;
>
> end_loops:
>   ...
>
> - Case 2:
>
> recalculate_initial_values:
>   make_some_calculations;
>   for(cond1)
>     for(cond2)
>       while(cond3)
>         if(wrong_values) goto recalculate_initial_values;
>
> - Case 3:
>
>   calculation1;
>   if(error) goto end_calculations;
>   calculation2;
>   if(error) goto end_calculations;
>   calculation3;
>   if(error) goto end_calculations;
>   calculation4;
>   if(error) goto end_calculations;
>
>   handle_results;
>
> end_calculations:
>   clean_up;

Of those, only case 3 looks like possibly decent use.  Case 1 and 2 look very
problematic.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

"Jon A. Cruz" wrote:
> 
> Ken wrote:
> 
> > Strangely the GOTO command is one of the few in Qbasic I ever understood
> > how to use successfully... Imagine that !
> 
> Well, under Qbasic, the use of GOTO is probably much more needed.
> 
> Switch to something like Java, or Smalltalk, or lisp...

I would rather fight than switch (I'll be that really dates me).

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

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote:
: 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.

  The #break-statement should NOT jump out of the current #if-statement, but
only out of the current #while-statement (and whatever else loop statement
this enhanced language would have).
  Why?
  Because usually you do this:

#while(whatever)
  ...
  #if(ending_condition)
    #break
  #end
  ...
#end

  It's obvious that if the #break just jumps out of the #if-statement, it
will be mostly useless.

  Unless...
  ... you could specify how many blocks do the #break jump out of. For
example:

#while(cond1)
  #while(cond2)
    #while(cond3)
      #if(cond4)
        #break(3)
      #end
    #end
  #end
  ...
#end

  Supposing that the #break also jumps out of the current #if-statement (and
it's counted as one block), the #break in this code will jump to the line
after the second last #end (ie. the line after the #while(cond2)-block,
marked with "...").

  Of course a simple #break that just jumps out of the current loop would be
mostly enough.

: Maybe even macros(have you ever wanted to jump 
: out of a macro early?)

  I don't know how this could be done. As far as I know, #macro is just
a text-replacement command. The macro call is just replaced with the body
of the macro with the parameters changed to their proper values.
  If you would #break a macro, it would mean that the body will literally be
broken, ie. with missing #end-statements (probably from the #if inside which
the #break was) thus causing problems to the parser.
  If macros were more like function calls, it would be more easier to add
a #return-statement.

  Now, that's an idea:

#function Abs(x)
  #if(x>=0)
    #return x
  #else
    #return -x
  #end
#end

  Hmm... Does this make sense? :)

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

Post a reply to this message

>
> Of those, only case 3 looks like possibly decent use.  Case 1 and 2
look very
> problematic.

Java handles case 1 with a labeled break, doesn't it?

Johannes.

Post a reply to this message

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

>   It's obvious that if the #break just jumps out of the #if-statement, it
> will be mostly useless.
> 
>   Unless...
>   ... you could specify how many blocks do the #break jump out of. For
> example:
...
>   Supposing that the #break also jumps out of the current 
>   #if-statement (and it's counted as one block), the #break in this 
>   code will jump to the line after the second last #end (ie. the line 
>   after the #while(cond2)-block, marked with "...").
> 
>   Of course a simple #break that just jumps out of the current loop would 
> be mostly enough.

Yes, that would be enough for just about anything. I guess I was 
thinking about Java-style multi-level breaks when I mentioned #if 
statements. I don't think they would really be needed in POV, but they 
might be a possibility in CSDL.


> : Maybe even macros(have you ever wanted to jump 
> : out of a macro early?)
> 
>   I don't know how this could be done. As far as I know, #macro is just
> a text-replacement command. The macro call is just replaced with the body
> of the macro with the parameters changed to their proper values.
>   If you would #break a macro, it would mean that the body will literally 
> be broken, ie. with missing #end-statements (probably from the #if 
> inside which the #break was) thus causing problems to the parser.

Wouldn't this problem with missing #end statements also occur with a 
loop? In both cases, there would probably be data in the parser that has 
to be reset.


>   If macros were more like function calls, it would be more easier to add
> a #return-statement.
> 
>   Now, that's an idea:
> 
> #function Abs(x)
>   #if(x>=0)
>     #return x
>   #else
>     #return -x
>   #end
> #end
> 
>   Hmm... Does this make sense? :)

I do like this better, since it works more like a function. But I am 
sure some people would consider it a needless complexity...maybe for 
CSDL though. :-)

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

Post a reply to this message