Re: FOR i ...
- Posted by Pete Lomax <petelomax at blueyonder.co.??> Nov 15, 2007
- 471 views
CChris wrote: > > Pete Lomax wrote: > > obviously changes are needed in the scanner no matter what <res-word> is > > Actually, the parser expects a variable name and an equal sign, so it has to > be modified for your syntax to work. It is a workable solution. <slaps head> Yes, I meant to say parser not scanner there. > }}} <eucode> > type hour(integer n) > return n>=0 and n<=23 > end type > hour n > for hour n=0 to 23 do big_ben_chime() end for > </eucode> {{{ > This should be legal, shouldn't it? Not really seeing any point to this. It would be at least 8 times slower than a non-type-checked loop [I just ran a quick test to prove this], and what you probably should be doing for type checking is eg calling:
procedure big_ben_chime(hour h)
> This is why I'd prefer either the "with" version Derek proposed, or a new > keyword > like iterate, rather. I don't see how as that makes the slightest bit of difference. Is a "for with h" or an "iterate h" going to type-check or not, or somehow type-check at zero cost? What I don't understand here is just how or why changing the keyword or introducing another confusing construct is going to magically change anything at all, please explain. Of course my "for integer i=1" does not magically change things either, just reads better than "for with i=1" imo, giving a better sense that "integer i" already exists. I suppose if the consensus is that "for hour n=1" should be supported and is shorthand for:
for ??=1 to ... n=?? (ie opASSIGN, opPROC, & opTYPE_CHECK)
Then fair do's, no skin off my nose, but sounds not good to me. > by setting them to NOVALUE on exiting the loop I one day hope to be able to examine a for loop var after the end for, hence I strongly disagree with that. Regards, Pete