 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] yahoo com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff <chr### [at] yahoocom> wrote:
: But I am sure some people would consider it a needless complexity...
You are right. And I wonder why?
If someone adds some new object, pattern or other feature, everyone praises
it and says "oohh... cool... great!". If someone even suggests adding something
to the syntax, everyone is immediately saying "no, no, no!".
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
> Chris Huff <chr### [at] yahoocom> wrote:
> : But I am sure some people would consider it a needless complexity...
>
> You are right. And I wonder why?
> If someone adds some new object, pattern or other feature, everyone praises
> it and says "oohh... cool... great!". If someone even suggests adding something
> to the syntax, everyone is immediately saying "no, no, no!".
Like I said elsewhere you have a clear conflict between the Programmer
mentality and the User mentality. Programmers not only want to know how
it works but they also want to be able to force it to work as they want
it to.
Users just want to be able to use it and don't care how it works. Users
want features that are easy to apply and the program takes care of the
details. Users want a big list of features to choose from without having
to do a big song and dance routine to get it to work.
Programming features are big song and dance routines !
That's how I see it anyway.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
> Now, that's an idea:
>
> #function Abs(x)
> #if(x>=0)
> #return x
> #else
> #return -x
> #end
> #end
>
> Hmm... Does this make sense? :)
>
I like the idea of functions, but I suspect there would be a lot of
resistance to their introduction.
Why? they look rather like macros and people will get confused. I'm not
saying people are dumb but a lot of POV users are not programmers and
might not appreciate the difference between macros and functions.
PoD.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
