OpenEuphoria

Re: For loops

• Posted by CChris <christian.cuvier at a?ricult?re.gouv.fr> Nov 19, 2007
• 601 views

Pete Lomax wrote:
> 
> CChris wrote:
> > 
> > here would be my proposal for changes/extensions:
> > 1/ Change to the for loop semantics
> > 2/ New construct
> > 3/ Change in ex.err dumps
> 
> So what you are saying, by 1/ and 3/ alone, is that:
> }}}
<eucode>
>     for i=1 to 10 do end for
>     ?i
>     for i=1 to 5 do end for
>     ?9/0
> </eucode>
{{{

> runs without compilation error, displaying 11 and creating an ex.err with just
> the one i (=6) in it, right?
> 

Yep

> Now, when the compiler encounters the for i=1 to 5 statement, it must be doing
> one of two things:
>   a) hiding the previous i and creating a new one, or
>   b) re-using that i
> In both cases the i must be specially marked as "from a for loop" I take it?
> (and also "the end for has been found and processed")

Currently, i's scope in SymTab is either SC_LOOPVAR or SC_GLOOPVAR, so we know
it is a for loop index, and even whether it is local or private.
Marking i as constant makes for a good out of scope marker I think. This would
replace the current hiding that's performed. Er, wait a minute:

for i=1 to 10 do end for
for j=1 to 3 do
  for i=1 to 5 do end for
end for
?i

I assume this code should be legal. Should it print 6 or 11? If the answer is
11, then some hiding of the first i has to take place at some point. I think 6
makes more sense, but I'd rather dot that i.

> 
> You will also need special handling in this top-level case:
> }}}
<eucode>
> for i=1 to 5 do end for
> integer i
> </eucode>
{{{

> Again options a) and b) both seem equally plausible.
> 

Yes, redefinition has to be allowed in this special case. Since out of scope
loop vars are easy to spot, it is an easy adjustment to DefinedYet(), since i
would no longer be hidden.

> Option a) makes the plans for ex.err rather tricky whereas b) means that no
> change whatsoever to ex.err creation is required. Obviously therefore b) is
> the sensible thing to do, right?

Definitely.

> 
> If you are going to make the changes for 1/ and 3/, they solve all the
> problems
> on their own, and proposal 2/ becomes utterly pointless.
> 

The semantics are not the same.
Using 1/ and 3/ attaches the loop var to a for loop, and extends its use. But it
can be redefined, as you emphasized earlier.
Using 2/ allows the use of variables with something else than a predefined type
(starting with object), which might be global and cannot be redefined later,
since it is a regular variable. Also see below.

> Regards,
> Pete
> 
> PS It does not strike me as particularly logical that i cannot be assigned to
> after the end for, but it is a compromise I can easily accept.

The meaning of the change 1/ is that the variable can still be inspected as the
for loop is over, and only that. Since it is attached to a loop that is over,
there's not much point in modifying it. What you say is: I can't write to it in
its natural scope, but I can once I get out of that scope. I don't find this very
logical.
If you allow writing to the index, you'll be able to define atomic variables on
the spot just by setting them as indexes, without using a regular declaration.
This doesn't strike me as enhancing clean coding.
If you want the behaviour of a regular variable, declare it regularly and use 2/
instead. Isn't this simpler for the writer and clearer to the reader?

CChris