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

> for i = 1 to 5
> ...

Wrong for loop. I suppose I should have said I meant C-like loop. Try:
#for(COUNTER INITIALIZATION; CONTINUE CONDITION; COUNTER MODIFICATION)
...
#end
This is well defined, and more flexible. And doesn't have the problems 
you mention:
1: Initialization, which sets the initial state of the variable.
2: The test for the continue condition. If it evaluates as true, the 
body of the loop is executed.
3: The counter modification. This can do something as simple as 
incrementing the variable. Then you jump back to step 2.


> 	The lack of typing is a weakness that C folks love. (I will get
> around to testing it some day but I think I have seen a problem
> with #decare i = 1 and #declare i = 1.0 that has solved a loop
> problem. I won't swear to it.) But if all variables are
> automatically signed four bytes then it is not an efficient
> engine. 

I don't think the lack of typing has ever caused an error for me, but it 
does make it troublesome to read and write some code. One reason for the 
C-SDL idea, my version of which would be more strongly typed than 
POV-Script.


> >     The ++ and -- operators would not fit in the current syntax of POV,
> > so you can forget about them.
> 
> 	I have no problem with those than inc and dec. But is it going
> to be int + 1 or float + 1? But since it is not a typed language
> again all the clarity of C and Forth is possible. 

It would be value + 1.
What would their syntax be? Remember that POV requires a #declare or 
#local, changing this would mean changing the entire declaration syntax. 
What I said was that adding them would be impossible *without changing 
the declaration syntax*.

I would actually like to see the ability to modify existing variables 
without using a special command, or at least with a specialized #set 
command which would give an error for undeclared identifiers. I don't 
know how likely this is to happen, though...


> > So we should drop the #switch, #macro, and #while features and add #goto
> > and #label? And get rid of #local while we are at it...
> 
> 	There is an old saying, "All things are simple to those who do
> not have to do it themselves." I am of the KISS school. 

> 	#local is required when folks jump out of loops and such.

But there is no need for loops, you could just use #goto! Keep it 
simple, remember? Why have #switch, #macro, and #while when all you need 
is #goto?
And no, I am not serious about this. I really do think adding #goto 
would be a bad idea. I am just saying your argument against adding #for 
loops("One simple routine that can do everything is quite good enough.") 
doesn't make much sense.


> 	Most of my issue has been on alternatives to #while. I gave an
> example on for ... next as opposed to while. If the answer to for
> ... next is to make it behave the same was while, why is there a
> need for for ... next? 

Well, first, it shouldn't be BASIC-style for...next, but more C-style 
#for()...#end.


> 	There is an issue of clarity. Clarity to who? To the author?
> Clarity and familiarity are identical. 

Clarity to the author and anyone who wants to read it.


> 	Clarity to others? Axiom of programming. Uncommented code is
> unclear to others. Axiom the second. Commented code is likely
> unclear to others.

What?
Uncommented code can be confusing if it isn't well written with 
well-chosen variable names and a fairly simple structure.
Well commented code is almost always much more clear(except in the 
simplest cases). I wouldn't have made much progress in the POV source 
without the comments.(although most of the comments seem to be 
incomplete/missing)

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

Post a reply to this message