OpenEuphoria

Re: FOR i ...

• Posted by Pete Lomax <petelomax at blueyonder.co.??> Nov 15, 2007
• 665 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