1. For loops
Since there hasn't been much activity on this after some ideas wwere tossed,
here would be my proposal for changes/extensions:
1/ Change to the for loop semantics
Here would be the new rules:
* The loop index of a for loop will be available as a constant after the loop
ends, until it is redefined by another for loop or declared as a regular
variable. This is a change.
* The loop index, if private, can have the same name as any non private symbol,
and stops shadowing it on leaving the routine it is defined in. No change here.
* The loop index cannot have the same name as a previously declared variable in
the same routine (all top level code lumped together counts for a routine). No
change here.
* The loop index may have the same name as another loop index in the same
routine if that other index is not active at the time of its definition. You can
thus have two loops with same index following each other, but bot nested in each
other. No change here.
2/ New construct
for_existing <index>=<start> to <end> [by <increment>] do
-- something
end for_existing
The loop index must be a variable currently in scope and able to be assigned an
atom. That variable will not be accessible for write inside the loop, even from a
routine called from the loop.
If the limit or optional increment are variables, they may be modified inside
the loop, but the changes won't affect the limit and increment of the loop.
There are no other rules concerning its name, since it is an existing variable.
On exiting the loop, its index variable becomes accessible for write again.
Incrementing the loop variable will not cause a type check.
So this would be like a for loop, but using an existing variable.
3/ Change in ex.err dumps
If a variable is defined several times in a scope, like for loop indexes, only
the one defined last at the time of the dump will be displayed. This is a change.
Expected code breakage:
* none for 1/, since the change in 1/ will make legal code that currently isn't.
* some (or perhaps none) with 2/: programs which define variable(s) named
"for_existing" will require this name be changed.
* none for 3/, since code isn't involved.
No performance hit is expected.
Any comments?
Since I expect to move this week, the changes, if agreed upon, won't be
committed before next month.
CChris
2. Re: For loops
CChris wrote:
>
> Since there hasn't been much activity on this after some ideas wwere tossed,
> here would be my proposal for changes/extensions:
>
> 1/ Change to the for loop semantics
>
> Here would be the new rules:
> * The loop index of a for loop will be available as a constant after the loop
> ends, until it is redefined by another for loop or declared as a regular
> variable.
> This is a change.
> * The loop index, if private, can have the same name as any non private
> symbol,
> and stops shadowing it on leaving the routine it is defined in. No change
> here.
> * The loop index cannot have the same name as a previously declared variable
> in the same routine (all top level code lumped together counts for a routine).
> No change here.
> * The loop index may have the same name as another loop index in the same
> routine
> if that other index is not active at the time of its definition. You can thus
> have two loops with same index following each other, but bot nested in each
> other. No change here.
>
> 2/ New construct
>
> for_existing <index>=<start> to <end> [by <increment>] do
> -- something
> end for_existing
>
> The loop index must be a variable currently in scope and able to be assigned
> an atom. That variable will not be accessible for write inside the loop, even
> from a routine called from the loop.
> If the limit or optional increment are variables, they may be modified inside
> the loop, but the changes won't affect the limit and increment of the loop.
>
> There are no other rules concerning its name, since it is an existing
> variable.
>
> On exiting the loop, its index variable becomes accessible for write again.
> Incrementing the loop variable will not cause a type check.
>
> So this would be like a for loop, but using an existing variable.
>
> 3/ Change in ex.err dumps
>
> If a variable is defined several times in a scope, like for loop indexes, only
> the one defined last at the time of the dump will be displayed. This is a
> change.
>
>
> Expected code breakage:
> * none for 1/, since the change in 1/ will make legal code that currently
> isn't.
> * some (or perhaps none) with 2/: programs which define variable(s) named
> "for_existing"
> will require this name be changed.
> * none for 3/, since code isn't involved.
> No performance hit is expected.
>
>
> Any comments?
> Since I expect to move this week, the changes, if agreed upon, won't be
> committed
> before next month.
>
> CChris
For those who have followed my meanderings it will no surprise if I accept
this proposal. I just wondered why it would not be possible to write the
for_existing iterator within the loop. This agrees with current for-next loop
coding, but I don't see why it needs be preserved. Otherwise, I concur with
CChris's proposition.
AndyD
3. Re: For loops
Andy Drummond wrote:
>
> CChris wrote:
> >
> > Since there hasn't been much activity on this after some ideas wwere tossed,
> > here would be my proposal for changes/extensions:
> >
Maybe there has been little response because FOR is OK as it is and
doesn't need changing ;)
> > 1/ Change to the for loop semantics
> >
> > Here would be the new rules:
> > * The loop index of a for loop will be available as a constant after the
> > loop
> > ends, until it is redefined by another for loop or declared as a regular
> > variable.
> > This is a change.
> > * The loop index, if private, can have the same name as any non private
> > symbol,
> > and stops shadowing it on leaving the routine it is defined in. No change
> > here.
> > * The loop index cannot have the same name as a previously declared variable
> > in the same routine (all top level code lumped together counts for a
> > routine).
> > No change here.
> > * The loop index may have the same name as another loop index in the same
> > routine
> > if that other index is not active at the time of its definition. You can
> > thus
> > have two loops with same index following each other, but bot nested in each
> > other. No change here.
> >
> > 2/ New construct
> >
> > for_existing <index>=<start> to <end> [by <increment>] do
> > -- something
> > end for_existing
> >
> > The loop index must be a variable currently in scope and able to be assigned
> > an atom. That variable will not be accessible for write inside the loop,
> > even
> > from a routine called from the loop.
> > If the limit or optional increment are variables, they may be modified
> > inside
> > the loop, but the changes won't affect the limit and increment of the loop.
> >
> > There are no other rules concerning its name, since it is an existing
> > variable.
> >
> > On exiting the loop, its index variable becomes accessible for write again.
> > Incrementing the loop variable will not cause a type check.
> >
> > So this would be like a for loop, but using an existing variable.
> >
Does this offer anything WHILE can't do?
> > 3/ Change in ex.err dumps
> >
> > If a variable is defined several times in a scope, like for loop indexes,
> > only
> > the one defined last at the time of the dump will be displayed. This is a
> > change.
> >
> >
> > Expected code breakage:
> > * none for 1/, since the change in 1/ will make legal code that currently
> > isn't.
> > * some (or perhaps none) with 2/: programs which define variable(s) named
> > "for_existing"
> > will require this name be changed.
> > * none for 3/, since code isn't involved.
> > No performance hit is expected.
> >
> >
> > Any comments?
> > Since I expect to move this week, the changes, if agreed upon, won't be
> > committed
> > before next month.
> >
> > CChris
>
> For those who have followed my meanderings it will no surprise if I accept
> this proposal. I just wondered why it would not be possible to write the
> for_existing iterator within the loop. This agrees with current for-next loop
> coding, but I don't see why it needs be preserved. Otherwise, I concur with
> CChris's proposition.
>
> AndyD
The changes proposed, IMHO, amount to a work-around for the absence of
local variables. Maybe add those?
If you want to go to the trouble, I suggest that adding a missing
control feature such as a do..while would be a more appreciated use
of your time. This might prove to be simpler to do, too. (Only
guessing there).
Regards, John
4. Re: For loops
John E wrote:
>
> Andy Drummond wrote:
> >
> > CChris wrote:
> > >
> > > Since there hasn't been much activity on this after some ideas wwere
> > > tossed,
> > > here would be my proposal for changes/extensions:
> > >
>
> Maybe there has been little response because FOR is OK as it is and
> doesn't need changing ;)
>
If you read the forum for the past 7-8 days, you'll see that asimple bug report
about trace(1) triggered some activity indeed, and some requests for
additions/changes. The problem was that some of the changes were mutually
incompatible, so there was something to sort out.
>
> > > 1/ Change to the for loop semantics
> > >
> > > Here would be the new rules:
> > > * The loop index of a for loop will be available as a constant after the
> > > loop
> > > ends, until it is redefined by another for loop or declared as a regular
> > > variable.
> > > This is a change.
> > > * The loop index, if private, can have the same name as any non private
> > > symbol,
> > > and stops shadowing it on leaving the routine it is defined in. No change
> > > here.
> > > * The loop index cannot have the same name as a previously declared
> > > variable
> > > in the same routine (all top level code lumped together counts for a
> > > routine).
> > > No change here.
> > > * The loop index may have the same name as another loop index in the same
> > > routine
> > > if that other index is not active at the time of its definition. You can
> > > thus
> > > have two loops with same index following each other, but bot nested in
> > > each
> > > other. No change here.
> > >
> > > 2/ New construct
> > >
> > > for_existing <index>=<start> to <end> [by <increment>] do
> > > -- something
> > > end for_existing
> > >
> > > The loop index must be a variable currently in scope and able to be
> > > assigned
> > > an atom. That variable will not be accessible for write inside the loop,
> > > even
> > > from a routine called from the loop.
> > > If the limit or optional increment are variables, they may be modified
> > > inside
> > > the loop, but the changes won't affect the limit and increment of the
> > > loop.
> > >
> > > There are no other rules concerning its name, since it is an existing
> > > variable.
> > >
> > > On exiting the loop, its index variable becomes accessible for write
> > > again.
> > > Incrementing the loop variable will not cause a type check.
> > >
> > > So this would be like a for loop, but using an existing variable.
> > >
>
> Does this offer anything WHILE can't do?
1/ avoiding to forget to increment counter at the end;
2/ protecting loop index from unwanted interference (by internally setting its
status to constant);
3/ protecting limit and increment, just like in a for loop, if they are
(subscripted) variables.
This is actually a variant of a for loop, rather than a while loop. Or a cross
breed between the two. The variant syntax "for with ..." was suggested instead of
"for_existing". It avoids a new keyword, but perhaps isn't as obvious for the
reader of the code. I certainly could live with it.
>
>
> > > 3/ Change in ex.err dumps
> > >
> > > If a variable is defined several times in a scope, like for loop indexes,
> > > only
> > > the one defined last at the time of the dump will be displayed. This is a
> > > change.
> > >
> > >
> > > Expected code breakage:
> > > * none for 1/, since the change in 1/ will make legal code that currently
> > > isn't.
> > > * some (or perhaps none) with 2/: programs which define variable(s) named
> "for_existing"</font></i>
> > > will require this name be changed.
> > > * none for 3/, since code isn't involved.
> > > No performance hit is expected.
> > >
> > >
> > > Any comments?
> > > Since I expect to move this week, the changes, if agreed upon, won't be
> > > committed
> > > before next month.
> > >
> > > CChris
> >
> > For those who have followed my meanderings it will no surprise if I accept
> > this proposal. I just wondered why it would not be possible to write the
> > for_existing iterator within the loop. This agrees with current for-next
> > loop
> > coding, but I don't see why it needs be preserved. Otherwise, I concur with
> > CChris's proposition.
> >
> > AndyD
>
It is possible. But then what would be the difference with the modified for
loop?
The idea is that a for/for_existing loop uses a fixed increment to traverse some
fixed data structure or perform some operation. When it gets more dynamic than
that, use the while loop. That's my understanding at least. Currently, you must
use a while loop only beause you need some interaction with the counter. This
doesn't enhance code readability.
>
> The changes proposed, IMHO, amount to a work-around for the absence of
> local variables. Maybe add those?
If by "local" you mean with nested, coder defined scope like in C, then yes, the
issue could be handled this way. This is in Advanced Euphoria already (see
below), as a new scope ... end scope block, at the top of which you can define
variables (local or private) that go out of scope on reaching the end scope
statement.
There hasn't been much demand for this feature, so I didn't plan to introduce it
in standard Eu. But I'd consider it a good thing. Didn't you already see a flurry
of private vars most of which are used only in some branch of an if statement? Or
reused accidentally a var that should have been scoped out long ago?
>
> If you want to go to the trouble, I suggest that adding a missing
> control feature such as a do..while would be a more appreciated use
> of your time. This might prove to be simpler to do, too. (Only
> guessing there).
>
This was also suggested, but not much debated, as a do ... while loop is
strictly equivalent to:
while 1 do
-- something
if not <loop_again_condition> then exit end if
end while
Equivalent, but less verbose and making the intent clearer. I have it
implemented in my projet of modified interpreter - it may surface some day as
Advanced Euphoria, but is low priority at the moment.
The implementation of either is pretty simple actually, as it adapts the for
loop/while loop handling respectively. Scoped variables require adding an extra
field to the IL - and preventing ? to display an out of scope for loop var when
tracing could require it as well. This is a little harder, but can be done.
CChris
>
> Regards, John
5. Re: For loops
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:
for i=1 to 10 do end for
?i
for i=1 to 5 do end for
?9/0
runs without compilation error, displaying 11 and creating an ex.err with just
the one i (=6) in it, right?
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")
You will also need special handling in this top-level case:
for i=1 to 5 do end for
integer i
Again options a) and b) both seem equally plausible.
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?
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.
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.
6. Re: For loops
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
7. Re: For loops
CChris wrote:
>
> John E wrote:
> >
> > Andy Drummond wrote:
> > >
> > > CChris wrote:
> > > >
> > > > Since there hasn't been much activity on this after some ideas wwere
> > > > tossed,
> > > > here would be my proposal for changes/extensions:
> > > >
> >
> > Maybe there has been little response because FOR is OK as it is and
> > doesn't need changing ;)
> >
>
> If you read the forum for the past 7-8 days, you'll see that asimple bug
> report
> about trace(1) triggered some activity indeed, and some requests for
> additions/changes.
> The problem was that some of the changes were mutually incompatible, so there
> was something to sort out.
>
> >
I had indeed read most, but not all. I took your post to be a what
you considered to be a summary, my mistake. I also misunderstood
you when you said 'not much activity since...'. I'm not about to
declare war over it :)
But you know you are not just proposing this as a bug fix, but in fact
you are proposing an innovation.
> > > > 1/ Change to the for loop semantics
<snip>
> > > > So this would be like a for loop, but using an existing variable.
> > > >
> >
> > Does this offer anything WHILE can't do?
>
> 1/ avoiding to forget to increment counter at the end;
> 2/ protecting loop index from unwanted interference (by internally setting its
> status to constant);
> 3/ protecting limit and increment, just like in a for loop, if they are
> (subscripted)
> variables.
Righto, some worthwhile protections against programmer error, but no
enhanced ability.
>
> This is actually a variant of a for loop, rather than a while loop. Or a cross
> breed between the two. The variant syntax "for with ..." was suggested instead
> of "for_existing". It avoids a new keyword, but perhaps isn't as obvious for
> the reader of the code. I certainly could live with it.
>
An underscore in keywords seems... wrong :)
> >
> >
> > > > 3/ Change in ex.err dumps
> > > >
> > > > If a variable is defined several times in a scope, like for loop
> > > > indexes, only
> > > > the one defined last at the time of the dump will be displayed. This is
> > > > a
> change.</font></i>
> > > >
> > > >
> > > > Expected code breakage:
> > > > * none for 1/, since the change in 1/ will make legal code that
> > > > currently
> isn't.</font></i>
> > > > * some (or perhaps none) with 2/: programs which define variable(s)
> > > > named
> > "for_existing"</font></i>
> > > > will require this name be changed.
> > > > * none for 3/, since code isn't involved.
> > > > No performance hit is expected.
> > > >
> > > >
> > > > Any comments?
> > > > Since I expect to move this week, the changes, if agreed upon, won't be
> > > > committed
> > > > before next month.
> > > >
> > > > CChris
> > >
> > > For those who have followed my meanderings it will no surprise if I accept
> > > this proposal. I just wondered why it would not be possible to write the
> > > for_existing iterator within the loop. This agrees with current for-next
> > > loop
> > > coding, but I don't see why it needs be preserved. Otherwise, I concur
> > > with
> > > CChris's proposition.
> > >
> > > AndyD
> >
>
> It is possible. But then what would be the difference with the modified for
> loop?
> The idea is that a for/for_existing loop uses a fixed increment to traverse
> some fixed data structure or perform some operation. When it gets more dynamic
> than that, use the while loop. That's my understanding at least. Currently,
> you must use a while loop only beause you need some interaction with the
> counter.
> This doesn't enhance code readability.
>
> >
> > The changes proposed, IMHO, amount to a work-around for the absence of
> > local variables. Maybe add those?
>
> If by "local" you mean with nested, coder defined scope like in C, then yes,
> the issue could be handled this way. This is in Advanced Euphoria already (see
> below), as a new scope ... end scope block, at the top of which you can define
> variables (local or private) that go out of scope on reaching the end scope
> statement.
> There hasn't been much demand for this feature, so I didn't plan to introduce
> it in standard Eu. But I'd consider it a good thing. Didn't you already see
> a flurry of private vars most of which are used only in some branch of an if
> statement? Or reused accidentally a var that should have been scoped out long
> ago?
>
> >
> > If you want to go to the trouble, I suggest that adding a missing
> > control feature such as a do..while would be a more appreciated use
> > of your time. This might prove to be simpler to do, too. (Only
> > guessing there).
> >
>
> This was also suggested, but not much debated, as a do ... while loop is
> strictly
> equivalent to:
> }}}
<eucode>
> while 1 do
> -- something
> if not <loop_again_condition> then exit end if
> end while
> </eucode>
{{{
>
> Equivalent, but less verbose and making the intent clearer. I have it
> implemented
> in my projet of modified interpreter - it may surface some day as Advanced
> Euphoria,
> but is low priority at the moment.
>
> The implementation of either is pretty simple actually, as it adapts the for
> loop/while loop handling respectively. Scoped variables require adding an
> extra
> field to the IL - and preventing ? to display an out of scope for loop var
> when
> tracing could require it as well. This is a little harder, but can be done.
>
> CChris
> >
> > Regards, John
I think I'll stick with V2.5. I think RDS got the language more or less
right, that's why I bought a licence.
All the best with your version anyway, CChris, you are obviously keen to
get on and develop the language. No more posts from me.
John
8. Re: For loops
CChris wrote:
>
> Since there hasn't been much activity on this after some ideas wwere tossed,
> here would be my proposal for changes/extensions:
>
> 1/ Change to the for loop semantics
>
> Here would be the new rules:
> * The loop index of a for loop will be available as a constant after the loop
> ends, until it is redefined by another for loop or declared as a regular
> variable.
> This is a change.
> * The loop index, if private, can have the same name as any non private
> symbol,
> and stops shadowing it on leaving the routine it is defined in. No change
> here.
> * The loop index cannot have the same name as a previously declared variable
> in the same routine (all top level code lumped together counts for a routine).
> No change here.
> * The loop index may have the same name as another loop index in the same
> routine
> if that other index is not active at the time of its definition. You can thus
> have two loops with same index following each other, but bot nested in each
> other. No change here.
>
> 2/ New construct
>
> for_existing <index>=<start> to <end> [by <increment>] do
> -- something
> end for_existing
>
> The loop index must be a variable currently in scope and able to be assigned
> an atom. That variable will not be accessible for write inside the loop, even
> from a routine called from the loop.
> If the limit or optional increment are variables, they may be modified inside
> the loop, but the changes won't affect the limit and increment of the loop.
>
> There are no other rules concerning its name, since it is an existing
> variable.
>
> On exiting the loop, its index variable becomes accessible for write again.
> Incrementing the loop variable will not cause a type check.
>
> So this would be like a for loop, but using an existing variable.
>
> 3/ Change in ex.err dumps
>
> If a variable is defined several times in a scope, like for loop indexes, only
> the one defined last at the time of the dump will be displayed. This is a
> change.
>
>
> Expected code breakage:
> * none for 1/, since the change in 1/ will make legal code that currently
> isn't.
> * some (or perhaps none) with 2/: programs which define variable(s) named
> "for_existing"
> will require this name be changed.
> * none for 3/, since code isn't involved.
> No performance hit is expected.
>
>
> Any comments?
> Since I expect to move this week, the changes, if agreed upon, won't be
> committed
> before next month.
>
CChris:
The only thing I think might be added to for is continue.
As far as the the other things that you are talking about
are just not necessary because they all can be handled
simply by using the while loop.
I think you are concentrating to much on change and complicated
features.
Just add simple features that do not break code.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
9. Re: For loops
John E wrote:
>
> CChris wrote:
> >
> > John E wrote:
> > >
> > > Andy Drummond wrote:
> > > >
> > > > CChris wrote:
> > > > >
> > > > > Since there hasn't been much activity on this after some ideas wwere
> > > > > tossed,
> > > > > here would be my proposal for changes/extensions:
> > > > >
> > >
> > > Maybe there has been little response because FOR is OK as it is and
> > > doesn't need changing ;)
> > >
> >
> > If you read the forum for the past 7-8 days, you'll see that asimple bug
> > report
> > about trace(1) triggered some activity indeed, and some requests for
> > additions/changes.
> > The problem was that some of the changes were mutually incompatible, so
> > there
> > was something to sort out.
> >
> > >
> I had indeed read most, but not all. I took your post to be a what
> you considered to be a summary, my mistake. I also misunderstood
> you when you said 'not much activity since...'. I'm not about to
> declare war over it :)
>
> But you know you are not just proposing this as a bug fix, but in fact
> you are proposing an innovation.
>
Definitely.
The bug where an incorrect loop var is displayed in trace mode is already fixed
in bleeding edge code, available from the Sourceforge SVN repository.
?i currently can display an i that's out of scope. If the documented behaviour
changes, this won't need a fix; otherwise it still will.
I assumed the innovations had been clearly marked as such. They happened to be
brought to the spotlight by a bug report.
> > > > > 1/ Change to the for loop semantics
> <snip>
>
> > > > > So this would be like a for loop, but using an existing variable.
> > > > >
> > >
> > > Does this offer anything WHILE can't do?
> >
> > 1/ avoiding to forget to increment counter at the end;
> > 2/ protecting loop index from unwanted interference (by internally setting
> > its
> > status to constant);
> > 3/ protecting limit and increment, just like in a for loop, if they are
> > (subscripted)
> > variables.
>
> Righto, some worthwhile protections against programmer error, but no
> enhanced ability.
>
True.
>
> >
> > This is actually a variant of a for loop, rather than a while loop. Or a
> > cross
> > breed between the two. The variant syntax "for with ..." was suggested
> > instead
> > of "for_existing". It avoids a new keyword, but perhaps isn't as obvious for
> > the reader of the code. I certainly could live with it.
> >
>
> An underscore in keywords seems... wrong :)
Other options are:
1/ define "existing" as a separate keyword instead of for_existing. Could
increase the risk of a variable suddenly becoming a keyword, but perhaps not
much.
2/ use camelCase -> "forExisting". Not usual in Euphoria.
3/ force a for header to fit on one line like include statements, and then
process "existing" like "as" currently is. Riskier than 1/.
As long as there's a simple way to tell between regular and new loop (and if the
new loop is to exist), I don't have marked preferences among the various schemes.
>
> > >
> > > > > 3/ Change in ex.err dumps
> > > > >
> > > > > If a variable is defined several times in a scope, like for loop
> > > > > indexes,
> only</font></i>
> > > > > the one defined last at the time of the dump will be displayed. This
> > > > > is a
> > change.</font></i>
> > > > >
> > > > >
> > > > > Expected code breakage:
> > > > > * none for 1/, since the change in 1/ will make legal code that
> > > > > currently
> > isn't.</font></i>
> > > > > * some (or perhaps none) with 2/: programs which define variable(s)
> > > > > named
> > > "for_existing"</font></i>
> > > > > will require this name be changed.
> > > > > * none for 3/, since code isn't involved.
> > > > > No performance hit is expected.
> > > > >
> > > > >
> > > > > Any comments?
> > > > > Since I expect to move this week, the changes, if agreed upon, won't
> > > > > be
> committed</font></i>
> > > > > before next month.
> > > > >
> > > > > CChris
> > > >
> > > > For those who have followed my meanderings it will no surprise if I
> > > > accept
> > > > this proposal. I just wondered why it would not be possible to write the
> > > > for_existing iterator within the loop. This agrees with current for-next
> > > > loop
> > > > coding, but I don't see why it needs be preserved. Otherwise, I concur
> > > > with
> > > > CChris's proposition.
> > > >
> > > > AndyD
> > >
> >
> > It is possible. But then what would be the difference with the modified for
> > loop?
> > The idea is that a for/for_existing loop uses a fixed increment to traverse
> > some fixed data structure or perform some operation. When it gets more
> > dynamic
> > than that, use the while loop. That's my understanding at least. Currently,
> > you must use a while loop only beause you need some interaction with the
> > counter.
> > This doesn't enhance code readability.
> >
> > >
> > > The changes proposed, IMHO, amount to a work-around for the absence of
> > > local variables. Maybe add those?
> >
> > If by "local" you mean with nested, coder defined scope like in C, then yes,
> > the issue could be handled this way. This is in Advanced Euphoria already
> > (see
> > below), as a new scope ... end scope block, at the top of which you can
> > define
> > variables (local or private) that go out of scope on reaching the end scope
> > statement.
> > There hasn't been much demand for this feature, so I didn't plan to
> > introduce
> > it in standard Eu. But I'd consider it a good thing. Didn't you already see
> > a flurry of private vars most of which are used only in some branch of an if
> > statement? Or reused accidentally a var that should have been scoped out
> > long
> > ago?
> >
> > >
> > > If you want to go to the trouble, I suggest that adding a missing
> > > control feature such as a do..while would be a more appreciated use
> > > of your time. This might prove to be simpler to do, too. (Only
> > > guessing there).
> > >
> >
> > This was also suggested, but not much debated, as a do ... while loop is
> > strictly
> > equivalent to:
> > }}}
<eucode>
> > while 1 do
> > -- something
> > if not <loop_again_condition> then exit end if
> > end while
> > </eucode>
{{{
> >
> > Equivalent, but less verbose and making the intent clearer. I have it
> > implemented
> > in my projet of modified interpreter - it may surface some day as Advanced
> > Euphoria,
> > but is low priority at the moment.
> >
> > The implementation of either is pretty simple actually, as it adapts the for
> > loop/while loop handling respectively. Scoped variables require adding an
> > extra
> > field to the IL - and preventing ? to display an out of scope for loop var
> > when
> > tracing could require it as well. This is a little harder, but can be done.
> >
> > CChris
> > >
> > > Regards, John
>
>
> I think I'll stick with V2.5. I think RDS got the language more or less
> right, that's why I bought a licence.
>
> All the best with your version anyway, CChris, you are obviously keen to
> get on and develop the language. No more posts from me.
>
> John
Please note that Advanced Euphoria, if it ever released, won't be an RDS
creation (though based on code released by RDS), and will probably run counter to
some of its design concepts. Also note that no implementation for the innovations
has taken place in bleeding edge, let alone standard, Eu.
CChris
10. Re: For loops
Bernie Ryan wrote:
>
> CChris wrote:
> >
> > Since there hasn't been much activity on this after some ideas wwere tossed,
> > here would be my proposal for changes/extensions:
> >
> > 1/ Change to the for loop semantics
> >
> > Here would be the new rules:
> > * The loop index of a for loop will be available as a constant after the
> > loop
> > ends, until it is redefined by another for loop or declared as a regular
> > variable.
> > This is a change.
> > * The loop index, if private, can have the same name as any non private
> > symbol,
> > and stops shadowing it on leaving the routine it is defined in. No change
> > here.
> > * The loop index cannot have the same name as a previously declared variable
> > in the same routine (all top level code lumped together counts for a
> > routine).
> > No change here.
> > * The loop index may have the same name as another loop index in the same
> > routine
> > if that other index is not active at the time of its definition. You can
> > thus
> > have two loops with same index following each other, but bot nested in each
> > other. No change here.
> >
> > 2/ New construct
> >
> > for_existing <index>=<start> to <end> [by <increment>] do
> > -- something
> > end for_existing
> >
> > The loop index must be a variable currently in scope and able to be assigned
> > an atom. That variable will not be accessible for write inside the loop,
> > even
> > from a routine called from the loop.
> > If the limit or optional increment are variables, they may be modified
> > inside
> > the loop, but the changes won't affect the limit and increment of the loop.
> >
> > There are no other rules concerning its name, since it is an existing
> > variable.
> >
> > On exiting the loop, its index variable becomes accessible for write again.
> > Incrementing the loop variable will not cause a type check.
> >
> > So this would be like a for loop, but using an existing variable.
> >
> > 3/ Change in ex.err dumps
> >
> > If a variable is defined several times in a scope, like for loop indexes,
> > only
> > the one defined last at the time of the dump will be displayed. This is a
> > change.
> >
> >
> > Expected code breakage:
> > * none for 1/, since the change in 1/ will make legal code that currently
> > isn't.
> > * some (or perhaps none) with 2/: programs which define variable(s) named
> > "for_existing"
> > will require this name be changed.
> > * none for 3/, since code isn't involved.
> > No performance hit is expected.
> >
> >
> > Any comments?
> > Since I expect to move this week, the changes, if agreed upon, won't be
> > committed
> > before next month.
> >
>
> CChris:
>
> The only thing I think might be added to for is continue.
>
I agree that this would be quite useful. Already implemented in AE as "next".
> As far as the the other things that you are talking about
>
> are just not necessary because they all can be handled
>
> simply by using the while loop.
Simply? Well, perhaps.
And for the reader of the code, it is certainly not simpler, since the while
loop is being used for all sorts of different purposes. It's like calling
everything "stuff"; you can handle every sentence simply doing this, and let the
reader guess what you meant.
>
> I think you are concentrating to much on change and complicated
>
> features.
Just some that other users requested.
Definitions of what is simple or not vary among users, so ... it's kind of a
consensus thing.
>
> Just add simple features that do not break code.
>
Did you notice that RDS hasn't followed this pattern in the past? Additionally,
simple features often prove complicated to use - for instance, consider how
little namespaces are used, because they are inadequate out of simplicity.
> Bernie
>
> My files in archive:
> WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
>
> Can be downloaded here:
> <a
> href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan">http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan</a>
CChris
11. Re: For loops
- Posted by Bernie Ryan <xotron at ?luefrog.co?>
Nov 19, 2007
-
Last edited Nov 20, 2007
What I am concerned about that the same thing is going to happen
to the langauge that has happen with the win32lib.
If you download a windows program from the archive 70% will not
run because there have been so many changes made over time in
the library and older versions of win32lib are gone.
What will happen when a new user tries to run some older demos
and they don't run out of the box and the original coder is no
longer available.
That is not going to entice new user to adopt the langauge.
That same thing is going to happen to the Euphoria.
I think if you truly want to change the interpreter dramatically it should
be accomplished by writing a totally new separate interpreter.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
12. Re: For loops
- Posted by Matt Lewis <matthewwalkerlewis at gmail.?o?>
Nov 19, 2007
-
Last edited Nov 20, 2007
Bernie Ryan wrote:
>
>
> What I am concerned about that the same thing is going to happen
> to the langauge that has happen with the win32lib.
> If you download a windows program from the archive 70% will not
> run because there have been so many changes made over time in
> the library and older versions of win32lib are gone.
> What will happen when a new user tries to run some older demos
> and they don't run out of the box and the original coder is no
> longer available.
> That is not going to entice new user to adopt the langauge.
> That same thing is going to happen to the Euphoria.
> I think if you truly want to change the interpreter dramatically it should
> be accomplished by writing a totally new separate interpreter.
All software does this over time. You're arguing for a static language,
and that's just not going to happen. We could also argue that there are
additional features that would entice new users to adopt euphoria. Leaving
them out will turn those users away from Euphoria.
I think that if we're going to change the interpreter dramatically, we had
better think it through in detail and make sure that we really want those
changes. We need to decide if the trade off between the new functionality
is worth the potential lack of backwards compatibility.
It's not worth losing a lot of our legacy code for some minor upgrades
that will benefit few people.
But it's worth losing old [unsupported] win32lib programs in order to get
rid of the onX[] syntax.
But there are a lot of things that can be done without breaking old code.
And many of those will make some problems easier to solve. Now if only
we could all agree on which ones...
Matt
13. Re: For loops
- Posted by Matt Lewis <matthewwalkerlewis at ?mail.com>
Nov 19, 2007
-
Last edited Nov 20, 2007
CChris wrote:
>
> Bernie Ryan wrote:
> >
> > I think you are concentrating to much on change and complicated
> > features.
>
> Just some that other users requested.
> Definitions of what is simple or not vary among users, so ... it's kind of a
> consensus thing.
>
> > Just add simple features that do not break code.
>
> Did you notice that RDS hasn't followed this pattern in the past?
> Additionally,
> simple features often prove complicated to use - for instance, consider how
> little namespaces are used, because they are inadequate out of simplicity.
Yes, it's important to keep our collective eyes on the final goal. The
original namespace implementation had an elegant and simple implementation,
but it also had some fatal flaws (as far as fixing the problem for which
it was meant).
I think that the changes that are now in the trunk do a pretty good job of
closing that loop. The feature just became more powerful, even though the
usage hasn't really changed.
I think it's worth it to try to find a simple way to solve the common
problems that we all complain about on this list. For whatever reason,
it's often easier to come up with an over complex solution that explicitly
handles many specific cases, when in reality, a simpler solution may be
a better approach. It may not be entirely as powerful, but if it's easier
to comprehend, and ultimately solves the same problem as the more powerful
and complex solution, I think most people would agree to its superiority.
Simpler solutions also tend to be easier in terms of gaining consensus than
something that is more complex, since the number of possible disagreements
rise just like the combinatoric possibilities of features.
Matt
14. Re: For loops
- Posted by Pete Lomax <petelomax at b?ueyonde?.co.uk>
Nov 19, 2007
-
Last edited Nov 20, 2007
CChris wrote:
> Er, wait a minute:
> }}}
<eucode>
> 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
> </eucode>
{{{
> Should it print 6 or 11?
6
> Using 2/ allows variables with something else than a predefined type
This was the biggest flaw in my reply to Derek. Presumably:
type odd(integer x) return remainder(x,2) end type
odd o
for_existing o=1 to 10 do
end for_existing
would die with a type check on the end for_existing line.
I cannot accept this has any worthwhile value, not least because it encourages
writing loops many times slower [>=8] than normal for loops, but that if the for
construct is wrong, you will know soon enough - you don't need type checking on
it as well, and of course any type-check will probably pass with flying colours
even though the for construct is wrong. You cannot even do apparently sensible
things such as type checking the limit, eg:
for_existing o=1 to 10 by 2 do
is valid despite odd(10) being false. I could even make a similar argument for
the init value, in cases where the limit/step is such that the loop will iterate
zero times.
I still say that adding a new for_existing construct now seems pointless.
> > not particularly logical that i cannot be assigned to
> > after the end for, but it is a compromise I can easily accept.
>
> can't write to in natural scope, but can once out of that scope. I don't
> find this very logical.
Touche. I don't want to make an issue out of this. Actually it does make some
logical sense to say that variables introduced as for loop controls can only ever
be modified by for loop statements, both before and now after the corresponding
end for(s).
Regards,
Pete
15. Re: For loops
- Posted by CChris <christian.cuvier at agri?ulture.gouv.f?>
Nov 19, 2007
-
Last edited Nov 20, 2007
Pete Lomax wrote:
>
> CChris wrote:
> > Er, wait a minute:
> > }}}
<eucode>
> > 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
> > </eucode>
{{{
> > Should it print 6 or 11?
> 6
>
Agreed.
> > Using 2/ allows variables with something else than a predefined type
>
> This was the biggest flaw in my reply to Derek. Presumably:
> }}}
<eucode>
> type odd(integer x) return remainder(x,2) end type
> odd o
> for_existing o=1 to 10 do
> end for_existing
> </eucode>
{{{
> would die with a type check on the end for_existing line.
>
Sure would.
> I cannot accept this has any worthwhile value, not least because it encourages
> writing loops many times slower [>=8] than normal for loops,
Use without type_check if you don't want type checking to slow things down. Is
this approach wrong?
> but that if
> the for construct is wrong, you will know soon enough - you don't need type
> checking on it as well, and of course any type-check will probably pass with
> flying colours even though the for construct is wrong. You cannot even do
> apparently
> sensible things such as type checking the limit, eg:
> }}}
<eucode>
> for_existing o=1 to 10 by 2 do
> </eucode>
{{{
> is valid despite odd(10) being false.
The limit is not necessarily reached by the index, whose the end value is the
smallest beyond the limit ("what "beyond" means depends on the sign of the
increment). so the checking would be pointless.
> I could even make a similar argument for
> the init value, in cases where the limit/step is such that the loop will
> iterate
> zero times.
>
> I still say that adding a new for_existing construct now seems pointless.
>
Well, I'm not a staunch supporter of this. It was just the most consistent way
imho to accommodate requests that were made. We can decide that the while loop is
good enough for these cases - though using the same construct for many different
purposes doesn't help writing clearer code.
> > > not particularly logical that i cannot be assigned to
> > > after the end for, but it is a compromise I can easily accept.
> >
> > can't write to in natural scope, but can once out of that scope. I don't
> > find this very logical.
> Touche. I don't want to make an issue out of this. Actually it does make some
> logical sense to say that variables introduced as for loop controls can only
> ever be modified by for loop statements, both before and now after the
> corresponding
> end for(s).
>
> Regards,
> Pete
CChris
16. Re: For loops
CChris wrote:
>
> Pete Lomax wrote:
> >
> > I still say that adding a new for_existing construct now seems pointless.
> >
>
> Well, I'm not a staunch supporter of this. It was just the most consistent way
> imho to accommodate requests that were made. We can decide that the while loop
> is good enough for these cases - though using the same construct for many
> different
> purposes doesn't help writing clearer code.
I think that there's a legitimate place for something like the C-style
for-loop. It gives us a fairly well structured while loop that I think
makes for clearer code, since the mechanics of the loop are declared
before hand, but you have much greater freedom in choosing your method
of iteration and termination.
Matt
17. Re: For loops
Matt Lewis wrote:
>
> I think that there's a legitimate place for something like the C-style
> for-loop. It gives us a fairly well structured while loop that I think
> makes for clearer code, since the mechanics of the loop are declared
> before hand, but you have much greater freedom in choosing your method
> of iteration and termination.
Would this be too far outside Euphoric philosophy:
for( x, x+1, x < 10)
-- ...
end for
18. Re: For loops
c.k.lester wrote:
>
> Matt Lewis wrote:
> >
> > I think that there's a legitimate place for something like the C-style
> > for-loop. It gives us a fairly well structured while loop that I think
> > makes for clearer code, since the mechanics of the loop are declared
> > before hand, but you have much greater freedom in choosing your method
> > of iteration and termination.
>
> Would this be too far outside Euphoric philosophy:
>
> }}}
<eucode>
> for( x, x+1, x < 10)
> -- ...
> end for
> </eucode>
{{{
Yes. way too far! I would prefer that what we have now continues to work.
I feel, having thought a bit, that CChris's idea to allow the scope of the
for loop iterator to persist beyond the loop as a constant is pretty good.
It allows the programmer access to the value of the iterator when the loop
decided to terminate (not always when the limit is reached) without doing
any harm to existing code.
I also feel the continue statement would be valuable but I have never liked
the choice of word. Would "next" be better? Implying that the next loop is to
commence immediately?
for i=1 to 10 do
if array[i] < 0 then
next -- Do no more processing this time around
end if
<do something>
if some_condition then
exit -- Quit processing maybe before limit reached
end if
end for
?i -- Can tell at what point the loop exited
I agree of course that it is possible to do any of these things with the
existing language structure, but making things clearer and simpler is great
for code maintenance.
AndyD
19. Re: For loops
Andy Drummond wrote:
>
> c.k.lester wrote:
> >
> > Would this be too far outside Euphoric philosophy:
> > }}}
<eucode>
> > for( x, x+1, x < 10)
> > -- ...
> > end for
> > </eucode>
{{{
>
> Yes. way too far! I would prefer that what we have now continues to work.
> I feel, having thought a bit, that CChris's idea to allow the scope of the
> for loop iterator to persist beyond the loop as a constant is pretty good.
> It allows the programmer access to the value of the iterator when the loop
> decided to terminate (not always when the limit is reached) without doing
> any harm to existing code.
But that's just one way to do it. What about, say:
object in
loop in = gets(fn) while sequence(in) by in = gets(fn) do
-- ...
end loop
We've got the same elements (initialization, condition for continuing and
command for iteration) repackaged in a more euphorian manner. A simple
alternative would be:
object in
loop in = gets(fn) until atom(in) by in = gets(fn) do
-- ...
end loop
This is perhaps clearer, since it doesn't overload the while keyword, and
is probably more similar to the current for-loop construct. Maybe both
could be supported, though the use of 'not' in the condition would be
equivalent.
And maybe any and all of these 'subclauses' are optional, so that all of
the following are valid (even if possibly nonsensical examples):
loop until atom(in) by in = gets(fn) do
loop in = gets(fn) by in = gets(fn) do
loop by in = gets(fn) do
loop do
I don't think that any of these enhancements would require a change to
the back end at all, since we're just putting things together differently.
The IL code would probably map to a WHILE opcode, with different jump
points set to inject the extra iteration code.
> I also feel the continue statement would be valuable but I have never liked
>
> the choice of word. Would "next" be better? Implying that the next loop is to
> commence immediately?
I'm fine with either one. I think that this is a very worthy proposal (ooeu
already has 'continue').
Matt
20. Re: For loops
Matt Lewis wrote:
>
> Andy Drummond wrote:
> >
> > c.k.lester wrote:
> > >
> > > Would this be too far outside Euphoric philosophy:
> > > }}}
<eucode>
> > > for( x, x+1, x < 10)
> > > -- ...
> > > end for
> > > </eucode>
{{{
> >
> > Yes. way too far! I would prefer that what we have now continues to work.
> > I feel, having thought a bit, that CChris's idea to allow the scope of the
> > for loop iterator to persist beyond the loop as a constant is pretty good.
> > It allows the programmer access to the value of the iterator when the loop
> > decided to terminate (not always when the limit is reached) without doing
> > any harm to existing code.
>
> But that's just one way to do it. What about, say:
> }}}
<eucode>
> object in
> loop in = gets(fn) while sequence(in) by in = gets(fn) do
> -- ...
> end loop
> </eucode>
{{{
> We've got the same elements (initialization, condition for continuing and
> command for iteration) repackaged in a more euphorian manner. A simple
> alternative would be:
> }}}
<eucode>
> object in
> loop in = gets(fn) until atom(in) by in = gets(fn) do
> -- ...
> end loop
> </eucode>
{{{
> This is perhaps clearer, since it doesn't overload the while keyword, and
> is probably more similar to the current for-loop construct. Maybe both
> could be supported, though the use of 'not' in the condition would be
> equivalent.
>
> And maybe any and all of these 'subclauses' are optional, so that all of
> the following are valid (even if possibly nonsensical examples):
> }}}
<eucode>
> loop until atom(in) by in = gets(fn) do
> loop in = gets(fn) by in = gets(fn) do
> loop by in = gets(fn) do
> loop do
> </eucode>
{{{
>
> I don't think that any of these enhancements would require a change to
> the back end at all, since we're just putting things together differently.
> The IL code would probably map to a WHILE opcode, with different jump
> points set to inject the extra iteration code.
>
> > I also feel the continue statement would be valuable but I have never liked
> >
> > the choice of word. Would "next" be better? Implying that the next loop is
> > to
> > commence immediately?
>
> I'm fine with either one. I think that this is a very worthy proposal (ooeu
> already has 'continue').
>
> Matt
AE maps the
do [label "some string"] ... until <exit_condition>
construct to
while 1 do [label "some string"]
...
if <exit_condition> then exit end if
end while
and indeed doesn't require anything new in the backend.
Neither "next" (aka continue) nor "retry" (repeat current iteration, skipping
any increment or test), also in AE, do.
next and retry, as well as exit and exif, support an optional parameter:
* relative # extra levels to exit
* -# number of loop to exit (-1 = exit topmost and so on)
* a for loop variable (exif doesn't support this)
* a label, which is a double quoted string referenced by a "label" clause.
The various branch targets are resolved in the parser, which handles delayed
jumps by scanning a sequence at each block exit and backpatching when the branch
is ripe. The backend doesn't see anything new, as the EXIT opcode is being
emitted.
Of course the optional param could be restricted to be only a label. In the
simplest cases, this is probably overkill, but is theoretically true and safer,
as CB already emphasized. The resulting code simplification would be marginal,
since a single routine handles the optional parameter in the parser.
Everything works as expected AFAICT.
I didn't implement the "by" clause of the do loop because it is enough to put
its contents at the end of the loop body, so it seemed redundant. Unless there's
a refined semantic hue I didn't get.
Only possible issue: variables named "label", "until", "next", "retry" or "exif"
will need a rename. "label" is allowed only right after a do/then header end
marker. And a so much steeeeeeeeeeper learning curve, I'm sure.
CChris
21. Re: For loops
CChris wrote:
>
> The various branch targets are resolved in the parser, which handles delayed
> jumps by scanning a sequence at each block exit and backpatching when the
> branch is ripe. The backend doesn't see anything new, as the EXIT opcode
> is being emitted.
Yep, I did essentially the same thing in ooeu.
> Of course the optional param could be restricted to be only a label. In the
> simplest cases, this is probably overkill, but is theoretically true and
> safer, as CB already emphasized. The resulting code simplification would
> be marginal, since a single routine handles the optional parameter in the
> parser.
>
> Everything works as expected AFAICT.
>
> I didn't implement the "by" clause of the do loop because it is enough
> to put its contents at the end of the loop body, so it seemed redundant.
> Unless there's a refined semantic hue I didn't get.
Well, the reason I like this is that it's very clear, and you're less likely
to forget to increment the loop at the end and result in an accidental
"while 1 do " type of bug. I think it's nice because it's immediately
clear to the reader as to how the loop is meant to function. The body of
the loop is reserved for doing work, not incrementing. When you have a
loop where the incrementing isn't well defined (i.e., there are multiple
ways to move to the next value, or whatever) then you can fall back to
using a while-loop.
> Only possible issue: variables named "label", "until", "next", "retry"
> or "exif" will need a rename. "label" is allowed only right after a
> do/then header end marker. And a so much steeeeeeeeeeper learning curve,
> I'm sure.
Yeah, this is always a concern when adding to the language.
Matt
