1. FOR i ...
It seems to me that the point of difference is whether or not the coder wants
the iterator variable to be declared in the FOR statement or prior to the FOR
statement. So may I suggest that we develop syntax that allows the coder to tell
Euphoria what their intention or expectation is. The current FOR syntax tells
Euphoria that the coder expects that the iterator variable is to be declared in
the FOR statement and scoped to the FOR statement.
-- At this point 'i' is assumed not to exist yet,
-- and in fact if it does, an error is raised.
for i = A to B by C do
-- 'i' is now declared and can be used inside the FOR block.
...
end for
-- 'i' is no longer visible or accessible.
We could develop a form of this syntax that allows the coder to tell Euphoria to
use a prior declaration for the iterator variable. Maybe something along the
lines of ...
integer i
-- At this point 'i' exists.
for <res-word> i = A to B by C do
-- The previously declared 'i' can be used inside the FOR block.
...
end for
-- 'i' is still visible and accessible.
where <res-word> is some existing reserved word, such as "with".
integer i
i = 20
? i
for with i = 1 to 5 do
? i
end for
? i
The output would be ...
20
1
2
3
4
5
6
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
2. Re: FOR i ...
Derek Parnell wrote:
>
> the point of difference is whether or not the coder wants
> the iterator variable to be declared in the FOR statement or prior
Agreed, mostly [see PS].
> for <res-word> i = A to B by C do
Fine by me. Experimenting, I found that (on both 2.4 & 3.1):
for integer=1 to 10 do end for
for atom=1 to 10 do end for
compiles cleanly (but obviously does nothing). However any attempt to reference
the [daftly named] control var, such as ?integer, triggers an error. Hence, I
believe, the above proves A) that integer/atom could be used as the <res-word>
with no changes to lexer/tokeniser, obviously changes are needed in the scanner
no matter what <res-word> is, and B) such would not introduce any backward
incompatibility, thus I propose:
integer i
for integer i=1 to 10 do -- re-uses existing i
end for
?i -- valid, prints 11
It should also be stated that, both for performance reasons and since it is
illegal to modify a for loop control var, any attempts at user defined type
checking on a for loop var simply won't happen. I'd further impose a compile time
error on any attempt to use a udt.
Regards,
Pete
PS Of course this does not actually solve the original problem of multiple and
confusing i in trace/ex.err, <ahem> as my first suggestion did </ahem>, but at
least provides a work-around, and an oft-requested missing feature.
3. Re: FOR i ...
Pete Lomax wrote:
>
> Derek Parnell wrote:
> >
> > the point of difference is whether or not the coder wants
> > the iterator variable to be declared in the FOR statement or prior
> Agreed, mostly [see PS].
>
> > for <res-word> i = A to B by C do
>
> Fine by me. Experimenting, I found that (on both 2.4 & 3.1):
> }}}
<eucode>
> for integer=1 to 10 do end for
> for atom=1 to 10 do end for
> </eucode>
{{{
> compiles cleanly (but obviously does nothing). However any attempt to
> reference
> the [daftly named] control var, such as ?integer, triggers an error. Hence, I
> believe, the above proves A) that integer/atom could be used as the <res-word>
> with no changes to lexer/tokeniser, obviously changes are needed in the
> scanner
> no matter what <res-word> is, and B) such would not introduce any backward
> incompatibility,
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.
> thus I propose:
> }}}
<eucode>
> integer i
> for integer i=1 to 10 do -- re-uses existing i
> end for
> ?i -- valid, prints 11
> </eucode>
{{{
>
> It should also be stated that, both for performance reasons and since it is
> illegal to modify a for loop control var, any attempts at user defined type
> checking on a for loop var simply won't happen. I'd further impose a compile
> time error on any attempt to use a udt.
>
NO
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
This should be legal, shouldn't it?
This is why I'd prefer either the "with" version Derek proposed, or a new
keyword like iterate, rather.
CChris
> Regards,
> Pete
> PS Of course this does not actually solve the original problem of multiple and
> confusing i in trace/ex.err, <ahem> as my first suggestion did </ahem>,
> but at least provides a work-around, and an oft-requested missing feature.
If we agree that regular loop indexes don't need to show up in ex.err unless the
loop they relate to is active, then it can be solved (by setting them to NOVALUE
on exiting the loop). This would permit to show them as undefined while tracing,
since a for loop index is always initialised.
CChris
4. Re: FOR i ...
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
5. Re: FOR i ...
Would it break any code if i were simply allowed to exist after the end of the
loop?
for i = 1 to 2 do
end for
for i = i to 4 do
end for
Chris Bensler
Code is Alchemy
6. Re: FOR i ...
Pete Lomax wrote:
>
> 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:
> }}}
<eucode>
> procedure big_ben_chime(hour h)
> </eucode>
{{{
>
> > 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.
>
1/ There is no logical reason why the type of the loop variable should appear in
the syntax at all. Adding the type marker does add something, namely confusion.
2/ Don't forget adding }}}
<eucode>without type_check</eucode>
{{{
at the start of the
test code, and the penalty will go away.
3/ Since the loop variable exists outside the loop, it may have uses outside the
loop which require it to be of some udt - for instance, because a routine needs
to typecheck its arguments, which is done whether you run with or without
typecheck. Preventing it from being an udt by issuing a compile error would be a
quirky, useless restriction.
> 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:
> }}}
<eucode>
> for ??=1 to ...
> n=?? (ie opASSIGN, opPROC, & opTYPE_CHECK)
> </eucode>
{{{
> Then fair do's, no skin off my nose, but sounds not good to me.
>
"for_existing" is a clearer statement of intent than "iterate" or "for with", so
I'd suggest that one rather. There is a risk of breaking code which defines a
variable named "for_existing", but the risk is probably pretty slim. Did anyone
experience any problem because "find_from" is no longer available as a valid
identifier?
As a side note, I think the scanner can be made smarter (with decisive help from
next_token()) so as to be able to tell, when encountering a redefined keyword,
whether it is a keyword or a variable. There is a decision rule for this, based
on the nature of the previous and next token. This will make extending Eu
definitely easier by reducing - hopefully to zero, but further checks are neeeded
- the problems caused by a non keyword litteral suddenly becoming a keyword. By
maintaining a separate lookahead buffer, the loss of performance will be nil -
Scanner() will elaborate the next token and return the one it had figured out
earlier, rather than processing and returning the current token.
> > 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.
>
I am not sure this makes sense at all, though I see what you want to do.
Examining a for_existing loop var after the end for_existing would completely
make sense and be possible, since it is a regular variable.
Currently you have to use a specific variable anyway; it will no longer be
needed.
> Regards,
> Pete
CChris
7. Re: FOR i ...
Chris Bensler wrote:
>
> Would it break any code if i were simply allowed to exist after the end of the
> loop?
>
> for i = 1 to 2 do
> end for
> for i = i to 4 do
> end for
>
> Chris Bensler
> Code is Alchemy
I don't think it would, but then Pete's proposal of allowing a predeclared
integer i won't work (or will do with subtle side effects, which is worse).
The parser will have to decide whether an existing i is a predeclared non loop
variable - probably disallowed, cf CK -, a loop index at the same level - allowed
and reusing that index - or a nesting loop index - disallowed -.
As a result, the i defined last before ex.err is generated will be dumped there,
whether the loop it belongs to was active or no longer is, with its last value.
Not worse that the current state of things.
This wouldn't add another construct to the language, but change the semantics of
an existing one. Not my own preference, because _both_ semantics are useful to
have.
CChris
8. Re: FOR i ...
CChris wrote:
>
> Chris Bensler wrote:
> >
> > Would it break any code if i were simply allowed to exist after the end of
> > the
> > loop?
> >
> > for i = 1 to 2 do
> > end for
> > for i = i to 4 do
> > end for
> >
> > Chris Bensler
> > Code is Alchemy
>
> I don't think it would, but then Pete's proposal of allowing a predeclared
> integer
> i won't work (or will do with subtle side effects, which is worse).
> The parser will have to decide whether an existing i is a predeclared non loop
> variable - probably disallowed, cf CK -, a loop index at the same level -
> allowed
> and reusing that index - or a nesting loop index - disallowed -.
>
> As a result, the i defined last before ex.err is generated will be dumped
> there,
> whether the loop it belongs to was active or no longer is, with its last
> value.
> Not worse that the current state of things.
>
> This wouldn't add another construct to the language, but change the semantics
> of an existing one. Not my own preference, because _both_ semantics are useful
> to have.
>
> CChris
To re-iterate what I wrote on an entirely inappropriate subject, why is it not
possible/reasonable to simply say that if the for-loop variable is declared
prior to the loop then it is used - and remains in scope after the loop exits -
and if the variable does NOT exist then the behaviour is exactly as it is now
in that the variable is in scope only for the duration of the for-next loop.
This is consistent with C-style languages if you consider the loop to be a
procedure. This MIGHT break existing programs but only if written in a way
that uses the same variable name outside the loop as inside, with no relation
between them - a pretty poor way of writing code anyway, IMHO. I guess if you
tried to use a non-atomic variable you would have to raise an error but that
is right anyway.
AndyD
