1. Short-circuit warning
Is this warning really valid:
Warning: ../bin/indent.ex:53 - call to matches() might be short-circuited
Well, maybe valid, but useful? For instance, I specifically made the if
statement to short-circuit, that's the way I want it. I program all the time
counting on short circuits and do not really feel as though I need a warning
about it. I thought short-circuits were a benefit?
--
Jeremy Cowgar
http://jeremy.cowgar.com
2. Re: Short-circuit warning
Jeremy Cowgar wrote:
>
> Is this warning really valid:
>
> Warning: ../bin/indent.ex:53 - call to matches() might be short-circuited
>
> Well, maybe valid, but useful? For instance, I specifically made the if
> statement
> to short-circuit, that's the way I want it. I program all the time counting
> on short circuits and do not really feel as though I need a warning about it.
> I thought short-circuits were a benefit?
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
I think it was a valid warning when short-circuiting was new to Euphoria. I
guess the question is whether short-circuiting is expected behavior by people new
or relatively new to programming?
Personally, I say do away with it and make it very clear in the docs that that
is how things work.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
3. Re: Short-circuit warning
Jason Gade wrote:
>
>
> I think it was a valid warning when short-circuiting was new to Euphoria. I
> guess the question is whether short-circuiting is expected behavior by people
> new or relatively new to programming?
>
> Personally, I say do away with it and make it very clear in the docs that that
> is how things work.
>
Short circuiting should be explained in the manual and it should be taught in
any elementary programming course. I do not think that Euphoria should consider
everyone a newbie or a dummy. It's a programming language. There are some things
you should know when programming. Short circuiting is one of those, IMHO. I've
not seen any language (I'm sure that it may exist) that has given a warning about
short circuiting. That's almost as bad as:
Warning: if statement may branch if it's condition is true
Um, we know that 
To me the short-circuit warnings galore just mask a real
warning. Makes me want to turn off warnings, but I know that would be bad.
--
Jeremy Cowgar
http://jeremy.cowgar.com
4. Re: Short-circuit warning
Jeremy Cowgar wrote:
>
> Is this warning really valid:
>
> Warning: ../bin/indent.ex:53 - call to matches() might be short-circuited
>
> Well, maybe valid, but useful? For instance, I specifically made the if
> statement
> to short-circuit, that's the way I want it. I program all the time counting
> on short circuits and do not really feel as though I need a warning about it.
> I thought short-circuits were a benefit?
Yes, they are, but if the part that is being short circuited has side effects,
you may not really want to short circuit. I think that was the real reason
for the warning. And it's still valid. I think we probably should keep it,
but we might be able to improve it by eliminating cases where we can prove
that there are no side effects. I haven't studied that part of the code,
so I'm not sure how feasible this is.
Matt
5. Re: Short-circuit warning
Matt Lewis wrote:
>
> Yes, they are, but if the part that is being short circuited has side effects,
> you may not really want to short circuit. I think that was the real reason
> for the warning. And it's still valid. I think we probably should keep it,
> but we might be able to improve it by eliminating cases where we can prove
> that there are no side effects. I haven't studied that part of the code,
> so I'm not sure how feasible this is.
>
I would say that it would be very difficult to analyze that. Here's an example
of where I get short-circuit warnings that are flooding the output making it hard
to even see the output of my program:
if in_if or re:matches(else_if, line) then
...
elsif in_continue and length(line) > 5 and equal(line[1..5], ...)
...
end if
I guess that's the way I have always programmed.
I wonder, maybe we should add something like:
without xyz_warning
??
--
Jeremy Cowgar
http://jeremy.cowgar.com
6. Re: Short-circuit warning
Jeremy Cowgar wrote:
>
> Is this warning really valid:
Ditch it. Its PITA. Either don't allow short-ciruiting or allow it, but if its
okay to use short circiuiting then let me make my own mistakes - once at least.
If we really must have a warning then allow the "with warning" statement to have
fine granularity.
without warning(short-circuit,unused-local-constants)
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
7. Re: Short-circuit warning
Jeremy Cowgar wrote:
>
> Jason Gade wrote:
> >
> >
> > I think it was a valid warning when short-circuiting was new to Euphoria. I
> > guess the question is whether short-circuiting is expected behavior by
> > people
> > new or relatively new to programming?
> >
> > Personally, I say do away with it and make it very clear in the docs that
> > that
> > is how things work.
> >
>
> Short circuiting should be explained in the manual and it should be taught in
> any elementary programming course. I do not think that Euphoria should
> consider
> everyone a newbie or a dummy. It's a programming language. There are some
> things
> you should know when programming. Short circuiting is one of those, IMHO. I've
> not seen any language (I'm sure that it may exist) that has given a warning
> about short circuiting. That's almost as bad as:
>
> Warning: if statement may branch if it's condition is true
>
> Um, we know that To me the short-circuit warnings
> galore just mask a real warning. Makes me want to turn off warnings, but I
> know that would be bad.
>
Which is what I routinely do, and not only because of this particular warning.
"local variable is not used" occur a lot when you create GUI apps, and these
useless warnings just clutter the output. I also heard that it harms CGI
programs, but didn't play with this.
Pete Lomax was recommending a with warning= directive to selectively turn
warnings on or off. This would be harmless in terms of performance, and might
make it workable, or even useful, to turn warnings on.
CChris
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
8. Re: Short-circuit warning
I would like to see the Short-circuit warning disappear
However, CChris also mentioned the 'local variable is not used' warning.
I find I can lose some of those warnings by putting 'without warning'
as the very last line of the program so that earlier warnings are not lost.
Arthur Crump
CChris wrote:
>
> Jeremy Cowgar wrote:
> >
> > Jason Gade wrote:
> > >
> > >
> > > I think it was a valid warning when short-circuiting was new to Euphoria.
> > > I
> > > guess the question is whether short-circuiting is expected behavior by
> > > people
> > > new or relatively new to programming?
> > >
> > > Personally, I say do away with it and make it very clear in the docs that
> > > that
> > > is how things work.
> > >
> >
> > Short circuiting should be explained in the manual and it should be taught
> > in
> > any elementary programming course. I do not think that Euphoria should
> > consider
> > everyone a newbie or a dummy. It's a programming language. There are some
> > things
> > you should know when programming. Short circuiting is one of those, IMHO.
> > I've
> > not seen any language (I'm sure that it may exist) that has given a warning
> > about short circuiting. That's almost as bad as:
> >
> > Warning: if statement may branch if it's condition is true
> >
> > Um, we know that To me the short-circuit warnings
> > galore just mask a real warning. Makes me want to turn off warnings, but I
> know that would be bad.</font></i>
> >
>
> Which is what I routinely do, and not only because of this particular warning.
> "local variable is not used" occur a lot when you create GUI apps, and these
> useless warnings just clutter the output. I also heard that it harms CGI
> programs,
> but didn't play with this.
>
> Pete Lomax was recommending a with warning= directive to selectively turn
> warnings
> on or off. This would be harmless in terms of performance, and might make it
> workable, or even useful, to turn warnings on.
>
> CChris
>
> > --
> > Jeremy Cowgar
> > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
9. Re: Short-circuit warning
Arthur Crump wrote:
>
> I would like to see the Short-circuit warning disappear
> However, CChris also mentioned the 'local variable is not used' warning.
> I find I can lose some of those warnings by putting 'without warning'
> as the very last line of the program so that earlier warnings are not lost.
>
> Arthur Crump
Yeah, I was thinking about it. Make "-w strict" a command line option, and
"with/without strict" a keyword option? I don't think want multiple levels of
warnings like a C compiler but I guess I can see how these two warnings bug a lot
of people.
Not sure if with or without should be the default, though. Probably with.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
10. Re: Short-circuit warning
Jeremy Cowgar wrote:
>
> Is this warning really valid:
>
> Warning: ../bin/indent.ex:53 - call to matches() might be short-circuited
>
> Well, maybe valid, but useful? For instance, I specifically made the if
> statement
> to short-circuit, that's the way I want it. I program all the time counting
> on short circuits and do not really feel as though I need a warning about it.
> I thought short-circuits were a benefit?
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=6&fromYear=1&toMonth=5&toYear=D&postedBy=xotron&keywords=short-circuit
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
11. Re: Short-circuit warning
Bernie Ryan wrote:
>
> <a
> href="http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=6&fromYear=1&toMonth=5&toYear=D&postedBy=xotron&keywords=short-circuit">http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=6&fromYear=1&toMonth=5&toYear=D&postedBy=xotron&keywords=short-circuit</a>
>
Bernie, I agree 100% with what you said (slightly edited )
"I can write CORRECT code that runs with NO ERRORS and when the
program completes running it pops a STUPID short-circuit
message.
Why is it necessary for the user to have to edit his program to
prevent this popup window from displaying.
It would be fine if this was a compiler but its and interpter
and it should not be displaying that message."
Further:
"If the code is correct it should run without warnings or errors
It's not up to the interpter to second guess some users logic."
The key that I found in Bernies post that none of us have said in the past is
that the code "IS CORRECT". Again, I maintain if we are going to begin telling
the interpreter logic as warning messages then we need to add a few more:
Warning: if statement may branch if tested condition is true
Warning: while loop may repeat more than once
Warning: for 1 to 10 will execute multiple times unless an exit is encountered
Warning: puts will write something somewhere.
Warning: open will try to open a file but may fail if the file does not exist or
could not be created
Warning: append will append
Maybe I'm just making up funny examples, but they are not too far from the
short-circuit warning.
--
Jeremy Cowgar
http://jeremy.cowgar.com
12. Re: Short-circuit warning
Well, you /are/ making up silly examples. Short circuiting is not intuitive to
people new to programming.
Not everyone new to programming will have taken a class on it.
Even reading the manual short-circuiting may not appear very clear to people who
are new to boolean algebra. The least-surprise assumption is that both conditions
are tested and then a decision is made. We only think differently because we're
used to it.
Now, short-circuiting is very useful. I still suggest "with/without strict" for
the short-circuit warning and for the unused local vars warning.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
13. Re: Short-circuit warning
Jason Gade wrote:
>
> Jeremy Cowgar wrote:
> >
> > Is this warning really valid:
> >
> > Warning: ../bin/indent.ex:53 - call to matches() might be short-circuited
> >
> > Well, maybe valid, but useful? For instance, I specifically made the if
> > statement
> > to short-circuit, that's the way I want it. I program all the time counting
> > on short circuits and do not really feel as though I need a warning about
> > it.
> > I thought short-circuits were a benefit?
> >
> > --
> > Jeremy Cowgar
> > <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
>
> I think it was a valid warning when short-circuiting was new to Euphoria. I
> guess the question is whether short-circuiting is expected behavior by people
> new or relatively new to programming?
>
> Personally, I say do away with it and make it very clear in the docs that that
> is how things work.
>
When I first used Euphoria the docs DID describe the short-circuiting process.
It was very clear, and made coding easier with things like:
if atom(res) or length(res)=0 or res[1]='+' then
do something
end if
To do that with three nested if statements would be silly. As is the process
of hiding side-effects within if statements. An if statement is a condition
testing statement, and just because you CAN hide assignments within it hardly
makes for clear coding and good practice.
So please stick with short-circuiting if statements and recommend that users
do actually read the original Euphoria documentation first.
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
>
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
>
> j.
14. Re: Short-circuit warning
Andy Drummond wrote:
> When I first used Euphoria the docs DID describe the short-circuiting process.
> It was very clear, and made coding easier with things like:
> }}}
<eucode>
> if atom(res) or length(res)=0 or res[1]='+' then
> do something
> end if
> </eucode>
{{{
> To do that with three nested if statements would be silly. As is the process
> of hiding side-effects within if statements. An if statement is a condition
> testing statement, and just because you CAN hide assignments within it hardly
> makes for clear coding and good practice.
> So please stick with short-circuiting if statements and recommend that users
> do actually read the original Euphoria documentation first.
No one is talking about doing away with short circuiting. We're talking about
whether there should be a warning in the short circuiting case.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
15. Re: Short-circuit warning
Jason Gade wrote:
>
> Andy Drummond wrote:
> > When I first used Euphoria the docs DID describe the short-circuiting
> > process.
> > It was very clear, and made coding easier with things like:
> > }}}
<eucode>
> > if atom(res) or length(res)=0 or res[1]='+' then
> > do something
> > end if
> > </eucode>
{{{
> > To do that with three nested if statements would be silly. As is the process
> > of hiding side-effects within if statements. An if statement is a condition
> > testing statement, and just because you CAN hide assignments within it
> > hardly
> > makes for clear coding and good practice.
> > So please stick with short-circuiting if statements and recommend that users
> > do actually read the original Euphoria documentation first.
>
> No one is talking about doing away with short circuiting. We're talking about
> whether there should be a warning in the short circuiting case.
I misunderstood what was being said then. In which case I agree with the
contributer who thought up a whole pile of silly warnings. That could be
economised with a single one:
warning: This language follows the documentation.
I have one concern. Don't break existing code. After that almost any change
can be considered and maybe implemented.
16. Re: Short-circuit warning
Jason Gade wrote:
>
> No one is talking about doing away with short circuiting. We're talking about
> whether there should be a warning in the short circuiting case.
>
Here is my proposal. Add an option to ecu/ex/exw/exwc called -lint. lint is a
common tool name that checks for common mistakes that may pass the parser but may
cause problems later.
Disable such warnings as Short-circuit. Encourage new programmers to use the
-lint option frequently to analyze their code. After a very short amount of time
even a new programmer should not need the short circuit warning.
Euphoria may be a good first programming language but the percentage of people
who are using Euphoria as a first language I would say is low (but that is just a
guess, I have no data to back that up except that the questions asked here in
EUforum are not newbie type questions). Now, even when a newbie comes or if we
have a lot of newbies, they are new and they are going to have to spend much time
in the manual to do anything. They need to learn and they will learn or they will
quit.
You cannot be a new programmer and not spend time in a manual. The fact that you
are new probably means you do not understand many things and you will be reading,
you will be asking question.
The Euphoria users manual has an entire section on Short Circuiting that is
quite good.
Let's rely on the Users Manual to help new programmers. That's where they should
be. Let's not clutter the output of an advanced program with multiple pages of
warnings about common newbie mistakes, and that is no joke. I began programming
the PgSQL wrapper and I converted all the PgSQL types, error messages and other
constants over, than began programming. My first test had 9 pages of warnings. I
couldn't see the output of my program even. I could have added a wait_key() but I
was doing automated testing on it checking the exit code. I wound up disabling
warnings which made me miss a few good ones that could have helped.
We should program, see real warnings, we should run exwc -lint on our programs
once in a while or as often as we would like. But polluting the output w/so many
warnings that real warnings or program output cannot be found is counter
productive.
--
Jeremy Cowgar
http://jeremy.cowgar.com
17. Re: Short-circuit warning
Oh, I forgot to paste the link for the manual section on Short Circuiting:
http://rapideuphoria.com/refman_2.htm#shortcir
--
Jeremy Cowgar
http://jeremy.cowgar.com
18. Re: Short-circuit warning
Jeremy Cowgar wrote:
>
> Jason Gade wrote:
> >
> > No one is talking about doing away with short circuiting. We're talking
> > about
> > whether there should be a warning in the short circuiting case.
> >
>
> Here is my proposal. Add an option to ecu/ex/exw/exwc called -lint. lint is
> a common tool name that checks for common mistakes that may pass the parser
> but may cause problems later.
>
> Disable such warnings as Short-circuit. Encourage new programmers to use the
> -lint option frequently to analyze their code. After a very short amount of
> time even a new programmer should not need the short circuit warning.
[snip]
I could go with that. I've never used lint but I'm familiar with the concept.
But I also like with/without strict. I need to refresh my memory of what all the
(useful) warnings are.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
19. Re: Short-circuit warning
Andy Drummond wrote:
>
> When I first used Euphoria the docs DID describe the short-circuiting process.
> It was very clear, and made coding easier with things like:
> }}}
<eucode>
> if atom(res) or length(res)=0 or res[1]='+' then
> do something
> end if
> </eucode>
{{{
> To do that with three nested if statements would be silly.
By the way, it used to be that short ciruiting was significantly slower than
coding multiple IFs. I don't know if that situation has changed or not.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
20. Re: Short-circuit warning
Derek Parnell wrote:
>
> Andy Drummond wrote:
> >
> > When I first used Euphoria the docs DID describe the short-circuiting
> > process.
> > It was very clear, and made coding easier with things like:
> > }}}
<eucode>
> > if atom(res) or length(res)=0 or res[1]='+' then
> > do something
> > end if
> > </eucode>
{{{
> > To do that with three nested if statements would be silly.
>
> By the way, it used to be that short ciruiting was significantly slower than
> coding multiple IFs. I don't know if that situation has changed or not.
>
>
I never tested it but I always assumed that it had to be quicker; in effect the
short-circuit is just a paraphrase for the multiple-if method. Strange! That's
one reason I wanted it kept - though I gather there is no suggestion that it
should
go. I evidently misunderstood what some people were saying!
> --
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell
21. Re: Short-circuit warning
Derek Parnell wrote:
>
> By the way, it used to be that short ciruiting was significantly slower than
> coding multiple IFs. I don't know if that situation has changed or not.
>
>
Wow! Why is that? I just tested it, Derek is right.
test1.e
------------------------
object a, b
a = 10
for i = 1 to 100000000 do
if atom(a) then
if a > 5 then
if a = 10 then
b = a
end if
end if
end if
end for
test2.e
------------------------
object a, b
a = 10
for i = 1 to 100000000 do
if atom(a) and a > 5 and a = 10 then
b = a
end if
end for
Is that a valid test? Here are the results:
[jeremy@jdesk euphoria]$ time exu test1.e
real 0m1.503s
user 0m1.503s
sys 0m0.000s
[jeremy@jdesk euphoria]$ time exu test2.e
real 0m2.171s
user 0m2.167s
sys 0m0.003s
--
Jeremy Cowgar
http://jeremy.cowgar.com
22. Re: Short-circuit warning
> Wow! Why is that?
Can you examine the IL code to see what is actualy being generated?
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
23. Re: Short-circuit warning
Derek Parnell wrote:
>
>
> > Wow! Why is that?
>
> Can you examine the IL code to see what is actualy being generated?
>
I understand the generated C code better, I realize it's not the same, but look
at this... This is for the nested if's:
// for i = 1 to 100000000 do
{ int _1i;
_1i = 1;
L1:
if (_1i > 100000000)
goto L2;
// if atom(a) then
_8 = 1;
if (_8 == 0)
goto L3;
// if a > 5 then
// if a = 10 then
// b = a
_1b = 10;
L4:
L5:
L3:
// end for
_1i = _1i + 1;
goto L1;
L2:
So, it is optimizing the nested ifs. The code generated for the short-circuting
is not at all optimized. It checks each condition. Maybe my test was flawed, in
that it allowed optimization in one sense. But, you would think if it could
optimize the nested ifs than it could have optimized the single if.
I'll come up with a different test and see if the result is the same.
--
Jeremy Cowgar
http://jeremy.cowgar.com
24. Re: Short-circuit warning
Derek Parnell wrote:
>
>
> > Wow! Why is that?
>
> Can you examine the IL code to see what is actualy being generated?
The short circuit generates longer IL. There are 7 ops in the short circuit
code, but only 4 in the nested case. I think the issue is that the short
circuit handles the and/or logic, but you still need the opcodes to do
the actual comparisons. The short circuit logic is baked into the nested
ifs.
I started with this:
with trace
procedure test1()
object a, b
a = 10
for i = 1 to 100000000 do
if atom(a) then
if a > 5 then
if a = 10 then
b = a
end if
end if
end if
end for
end procedure
procedure test2()
object a, b
a = 10
for i = 1 to 100000000 do
if atom(a) and a > 5 and a = 10 then
b = a
end if
end for
end procedure
test1()
test2()
...and I get the following IL:
SubProgram [_toplevel_:00114]
1: 058 29 # STARTLINE: ss.exw(29)<<test1()>>
3: 027 116 # PROC: [test1:116]
5: 089 # UPDATE_GLOBALS:
6: 058 30 # STARTLINE: ss.exw(30)<<test2()>>
8: 027 125 # PROC: [test2:125]
10: 089 # UPDATE_GLOBALS:
11: 034 # RETURNT:
End SubProgram [_toplevel_:00114]
SubProgram [test1:00116]
1: 088 116 # ERASE_PRIVATE_NAMES: [test1:116]
3: 089 # UPDATE_GLOBALS:
4: 058 5 # STARTLINE: ss.exw(5)<<a = 10>>
6: 018 119 117 # [LIT 10:119] => [a:117]
9: 087 117 # DISPLAY_VAR: [a:117]
11: 058 7 # STARTLINE: ss.exw(7)<<for i = 1 to
100000000
# do>>
13: 125 121 122 121 116 120 56 # FOR_I: inc [LIT 1:121], lim [LIT
100000000:122],
# initial [LIT 1:121], lv [i:120],
jmp 0056
20: 087 120 # DISPLAY_VAR: [i:120]
22: 058 8 # STARTLINE: ss.exw(8)<<if atom(a)
then>>
24: 067 117 123 # IS_AN_ATOM: [a:117] [_temp_:123]
27: 020 123 49 # IF: [_temp_:123] = 0 goto 0049
30: 058 9 # STARTLINE: ss.exw(9)<<if a > 5 then>>
32: 107 117 124 49 # GREATER_IFW [a:117] > [LIT 5:124]
goto 0036
# else goto 0049
36: 058 10 # STARTLINE: ss.exw(10)<<if a = 10
then>>
38: 104 117 119 49 # IFW [a:117] = [LIT 10:119] goto 0042
else
# goto 0049
42: 058 11 # STARTLINE: ss.exw(11)<<b = a>>
44: 018 117 118 # [a:117] => [b:118]
47: 087 118 # DISPLAY_VAR: [b:118]
49: 058 15 # STARTLINE: ss.exw(15)<<end for>>
51: 054 20 122 120 121 # ENDFOR_INT_UP1: top 0020, lim: [LIT
100000000:122],
# lv [i:120]
56: 090 120 # ERASE_SYMBOL: [i:120]
58: 058 16 # STARTLINE: ss.exw(16)<<end
procedure>>
60: 088 116 # ERASE_PRIVATE_NAMES: [test1:116]
62: 029 116 # RETURNP
End SubProgram [test1:00116]
SubProgram [test2:00125]
1: 088 125 # ERASE_PRIVATE_NAMES: [test2:125]
3: 089 # UPDATE_GLOBALS:
4: 058 20 # STARTLINE: ss.exw(20)<<a = 10>>
6: 018 119 126 # [LIT 10:119] => [a:126]
9: 087 126 # DISPLAY_VAR: [a:126]
11: 058 22 # STARTLINE: ss.exw(22)<<for i = 1 to
100000000
# do>>
13: 125 121 122 121 125 128 63 # FOR_I: inc [LIT 1:121], lim [LIT
100000000:122],
# initial [LIT 1:121], lv [i:128],
jmp 0063
20: 087 128 # DISPLAY_VAR: [i:128]
22: 058 23 # STARTLINE: ss.exw(23)<<if atom(a) and
a
# > 5 and a = 10 then>>
24: 067 126 129 # IS_AN_ATOM: [a:126] [_temp_:129]
27: 143 129 129 38 # SC1_AND: [_temp_:129], [_temp_:129],
0038
31: 006 126 124 130 # GREATER: [a:126], [LIT 5:124] =>
[_temp_:130]
35: 144 130 129 # SC2_AND: [_temp_:130], [_temp_:129]
38: 148 129 130 56 # SC1_AND_IF: [_temp_:129],
[_temp_:130],
# 0056
42: 003 126 119 129 # EQUALS: [a:126], [LIT 10:119] =>
[_temp_:129]
46: 020 129 56 # IF: [_temp_:129] = 0 goto 0056
49: 058 24 # STARTLINE: ss.exw(24)<<b = a>>
51: 018 126 127 # [a:126] => [b:127]
54: 087 127 # DISPLAY_VAR: [b:127]
56: 058 26 # STARTLINE: ss.exw(26)<<end for>>
58: 054 20 122 128 121 # ENDFOR_INT_UP1: top 0020, lim: [LIT
100000000:122],
# lv [i:128]
63: 090 128 # ERASE_SYMBOL: [i:128]
65: 058 27 # STARTLINE: ss.exw(27)<<end
procedure>>
67: 088 125 # ERASE_PRIVATE_NAMES: [test2:125]
69: 029 125 # RETURNP
End SubProgram [test2:00125]
25. Re: Short-circuit warning
- Posted by gshingles <gshingles at ??ail.com>
May 20, 2008
-
Last edited May 21, 2008
Jeremy Cowgar wrote:
>
> Oh, I forgot to paste the link for the manual section on Short Circuiting:
>
> <a
> href="http://rapideuphoria.com/refman_2.htm#shortcir">http://rapideuphoria.com/refman_2.htm#shortcir</a>
Thanks for that Jeremy. It contains the line "Older versions (pre-2.1) of
Euphoria did not use short-circuit evaluation..." which perhaps explains the
existence of the warning. In which case I would say the warning is redundant
now, two major versions later.
Gary
26. Re: Short-circuit warning
Jeremy,
I want to show you the differences between short-circut evaluation
and non-short-circut evaluation.
Himm... If you want to modify a variable while you compare it:
while (flag && ++c < 10) { .. } -- oops that is C.
We can't do that in Euphoria, anyway.
When you want to assign a variable so you don't need so many []'s:
if ( node[N_NEXT][4][6] == True && (color = node[N_NEXT][4][3]) == Red )
{ -- oops, that is C also.
When you want obtain information using pass by reference:
if ( foo == 5 or get_bar_value( &bar ) == false ) {
.. -- careful not to use bar here.
-- oops, that is also C.
You have to put a lot effort to construct a situation where
shortcircuting would keep a variable from being assigned or updated
properly. The examples I gave are not even possible in EUPHORIA.
Unless you construct a function for updating a global variable
and bury it in the logic of an if-statement. You see how
difficult it is for short-circuting to be a problem with program
logic?
So, yes, I think think you have guessed correctly. I am on Jeremy's
side on this issue.
Shawn Pringle
