In article <38C8DD71.3560294C@neuro.informatik.uni-ulm.de>, Axel Baune 
<aba### [at] neuroinformatikuni-ulmde> wrote:

> The variant
> 
> > > #declare A = A + B;
> > > #declare A = A - B;
> 
> is far more readable than the other.

I disagree. I find this syntax:
#declare NumOfParts += PartsAdded;
#declare NumOfParts -= PartsRemoved;

much easier to read than:
#declare NumOfParts = NumOfParts + PartsAdded;
#declare NumOfParts = NumOfParts - PartsRemoved;


I read the += operator as saying "add B to A", instead of "set variable 
A to the result of adding A and B". It is a special case, and while more 
limited, makes code more readable since you know exactly what the code 
is intended to do.
Also, shorter expressions are almost always more readable than longer 
ones, even if the longer one is theoretically "cleaner".(within certain 
limits, of course. Warp's sig is not an example of shorter==better.) And 
the duplicated portion can often get quite large, even when it can't be 
put in a separate variable(I very rarely use single character names, I 
usually only use them for loop counters.).


> Besides this it would comlicate the parser of PoV if the other 
> variant should be maintained. This will lead to a new type of 
> possible parser bugs.  

As has already been said by others, this isn't true.

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

Post a reply to this message

In article <38C8DC47.1BEAFE1C@neuro.informatik.uni-ulm.de>, Axel Baune 
<aba### [at] neuroinformatikuni-ulmde> wrote:

> From the viewpoint of a computer scientist (I'm one) this is a not a
> syntactically correct defiend for-loop. The variable of a for-loop
> belongs to the for-command and should be never _changable_ by the user. 

Why? I see it as just another specialized structural component, which 
should be used when it is appropriate. Your restriction on modifying the 
loop variable seems arbitrary...
You say you are a computer scientist, but are you a computer programmer? 
I am still inexperienced with programming(I've only done a couple 
particle simulators and a few POV patches), but I can't think of any 
reason the loop variable shouldn't be used except for counting.

Maybe if you defined a for loop as a block of code that is executed a 
fixed number of times...but then, why have an initializer and an 
increment statement? Your for loop should only take one parameter(the 
number of times to loop) and should always increment by 1. You could use 
this to do everything an ordinary for loop with your restriction could 
do...
It is just that your definition seems to be going to an extreme(the 
other extreme being only using goto. :-) ).


> Sorry for flaming, but this are the programming styles, which make
> software packages difficult to maintain, debug, readable and
> understandable by other programmers.

How is it hard to understand?

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

Post a reply to this message

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

>   I think that there should some struct-type and reference-type data 
>   types.
> This would allow, for example, making linked lists.

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

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

Post a reply to this message

PoD wrote:
> 
> Some aspects of the language which relate purely to programming could be
> changed or (probably better) extended without affecting those who don't
> use them.
> 
> For a non-programmer or a programmer , macros, loops etc are a lot
> harder in POV than the equivalents in most programming languages.
> 
> Surely replacing
>   #declare I=1; #while(I<=5) ... #declare I=I+1;#end
> with either
>   for I = 1 to 5 {...}
> ala Basic, or even for a non-programmer,
>   for( I=1; I <= 5; I=I+1){...}
> would make life easier for all.

	So what is the difference other than a different syntax? The 123
ways to create a loop? They all do the same thing in the end.
Even step = 3 with I=I+3. 

	Introducing additional syntaxes raises more problems than it
solves. With one elementary syntax that can do everything there
isn't nearly as much to read and a hundred fewer places for
parser differences to creep in. 

	Next, complex conditional if then else statements. Can GOTO be
far behind?

Post a reply to this message

Johannes Hubert wrote:
> 
> "ingo" <ing### [at] homenl> wrote in message
> news:8EF2B8E07seed7@204.213.191.228...
> > Nieminen Juha wrote:
> >
> > >#declare A += B;
> > >#declare A -= B;
> >
> > What does it mean?
> 
> the same as
> 
> #declare A = A + B;
> #declare A = A - B;

	OK. Any what is the value beyond saving a few keystrokes? 

	The time required for extra keystrokes is the last thing that
worries even the best of programmers.

Post a reply to this message

In article <38C992EA.4C6238BD@ij.net>, Matt Giwer <jul### [at] ijnet> 
wrote:

> 	So what is the difference other than a different syntax? The 123
> ways to create a loop? They all do the same thing in the end.
> Even step = 3 with I=I+3. 
> 
> 	Introducing additional syntaxes raises more problems than it
> solves. With one elementary syntax that can do everything there
> isn't nearly as much to read and a hundred fewer places for
> parser differences to creep in. 

The only difference is syntax. But that is a meaningful difference. 
Although a for loop could also be implemented as a while loop, it can 
sometimes be easier to write and understand if written as a for loop.

And what do you mean by "a hundred fewer places for parser differences 
to creep in"? I don't think the modifications would be very extensive, 
and there is only one parser.


> 	Next, complex conditional if then else statements. Can GOTO be
> far behind?

Umm, we have if-then-else statements. And switch statements. And goto is 
a bad idea for many reasons.

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

Post a reply to this message

In article <38C994D0.C4A06309@ij.net>, Matt Giwer <jul### [at] ijnet> 
wrote:

> > #declare A = A + B;
> > #declare A = A - B;
> 
> 	OK. Any what is the value beyond saving a few keystrokes? 
> 
> 	The time required for extra keystrokes is the last thing that
> worries even the best of programmers.

Better readability, code which is easier to maintain without introducing 
new bugs, etc. The examples given make using = and + look good, but they 
also use single-character variable names. Just about the only time I use 
single-character variable names is in loop counters, most of the time 
the names are longer. Add in using multidimensional arrays, and you 
quickly get to line lengths that are very difficult to keep track of and 
modify later.

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

Post a reply to this message

Nieminen Juha wrote:

> Axel Baune <aba### [at] neuroinformatikuni-ulmde> wrote:
> : As I've never looked into the Code for the PoV-Parser I' did"t know
> : exactly, but I've already written a parser of my own for my programms,
> : and therefore I know what effects it would have on my own parser if I
> : wish to include the new syntax. From this knowledge I've extrapolated to
> : the PoV-Parser.
>
>   Perhaps you didn't do it the right way ;)
>
>   Using something like yacc and lex makes it quite easy to add new syntax.
> Although povray doesn't use them, it might use something similar (I really
> don't know).

Well, using something like XML rules would make it much easier to parse.
Unfortunately POV-Ray's language and parser are not designed quite that way.
After the change for 4.0, maybe it will end up a little more extensible.

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

An evolution to a Basic like syntax would be OK.

Object Oriented - heaven help us!!  The programmers (some) might like this
but I think the rest of us casual users would be driven away.

--
Jim

Check out my web site  http://www.kressworks.com/

Ken <tyl### [at] pacbellnet> wrote in message
news:38C7685C.5A4F3A68@pacbell.net...
>
>
> 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.
>
>  What I do worry about though is the influence that the people who seek
> a more programmer like language may have for the mass of people that have
> no programming background but still enjoy using the program. It might
> be good for them in some circumstances but would it be good for everyone
> is not so cut and dried as it were.
>
>
> So the questions I have are really for the non-programmer types out there.
>
> 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 ?
>
>
>
> P.S. I am not suggesting that the POV-Team is even considering changing
>      the language at this time. I am mearly trying to find out what the
>      mainstream users of the program think about this and if they really
>      like the way the syntax is currently structured.
>
>
> --
> 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

Jim Kress wrote:

> An evolution to a Basic like syntax would be OK.
>
> Object Oriented - heaven help us!!  The programmers (some) might like this
> but I think the rest of us casual users would be driven away.

No. No. Really. OO for POV-Ray would be nice.

Trust me.  :-)


In all seriousness, object oriented would work very well for POV-Ray, since it
models... objects!

If you are hand-coding POV-Ray, then you have to start thinking about the
objects you are making, primitives, meshes, etc. and where they go and how they
interact and what properties they have...

It's already a little OO, but going more so in the proper manner (notice I just
said "in the proper manner") might help greatly.


For those who learn other types of programming first, OO gets a little
difficult to pick up. But I believe that in general learning OO as a first
language is easier.

There are cases where an OO language might not be appropriate, but since the
concepts in POV-Ray are already so similar, it makes OO a good choice for
POV-Ray. Many of the concepts that make learning an OO language 'more
difficult' than learning VB are concepts that need to be learned for POV-Ray
itself.

OO was also used by Macromind in their Lingo in Director. Director was
definitely not for programmers but for designers. For their needs, it was very
good.

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