1. A bug in the interpreter
- Posted by Daryl Border <Darylb5 at aol.com> Feb 28, 2006
- 494 views
I was experimenting with some code recently, when I discovered a bug in the parser. The following code will parse without complaint, but does not work properly.
include get.e integer ch for n = 1 to 10 do if 4 < n < 8 then ? n end if end for ch = wait_key()
This program should display the numbers 5,6,and 7. It actually displays the number 1 through 10. The problem is with function rexpr() in parser.e which parses the expression 4 < n < 8. If the value of n is 1, it calcualtes 4 < 1 which is FALSE. It then calculates FALSE < 8 which is meaningless because FALSE is not a number. Because TRUE and FALSE are represented by the numbers 1 and 0, the computer can perform the calcualtion. And because both 0 and 1 are less than 8, the expression will evaluate to TRUE no matter what value n contains. Here's a modified version of function rexpr() I believe will correct the problem. It requires the procedure TempKeep() in emit.e be made global.
function rexpr() token tok integer id, opnd sequence patches patches = {} tok = cexpr() if tok[T_ID] <= GREATER and tok[T_ID] >= LESS then id = tok[T_ID] tok = cexpr() emit_op(id) opnd = Code[$-1] -- preserve the previous rhs value to be used as the next lhs value if tok[T_ID] <= GREATER and tok[T_ID] >= LESS then TempKeep(opnd) if short_circuit then emit_op(SC1_AND) patches &= length(Code) emit_addr(0) end if end if while tok[T_ID] <= GREATER and tok[T_ID] >= LESS do id = tok[T_ID] emit_opnd(opnd) -- push operand onto cg_stack tok = cexpr() -- get next operand emit_op(id) if short_circuit then emit_op(SC2_NULL) end if opnd = Code[$-1] if tok[T_ID] <= GREATER and tok[T_ID] >= LESS then TempKeep(opnd) if short_circuit then emit_op(SC1_AND) patches &= length(Code) emit_addr(0) end if end if if not short_circuit then emit_op(AND) end if end while opnd = Code[$] for n = 1 to length(patches) do backpatch(patches[n],opnd) backpatch(patches[n]+1,length(Code)+1) end for end if return tok end function
Thanks Daryl Border
2. Re: A bug in the interpreter
- Posted by cklester <cklester at yahoo.com> Feb 28, 2006
- 481 views
Daryl Border wrote: > > I was experimenting with some code recently, when I discovered a bug in the > parser. > The following code will parse without complaint, but does not work properly. > > include get.e > integer ch > > for n = 1 to 10 do > if 4 < n < 8 then > ? n > end if > end for > > ch = wait_key() > In Euphoria, you have to do it this way: if 4 < n and n < 8 then -=ck "Programming in a state of Euphoria." http://www.cklester.com/euphoria/
3. Re: A bug in the interpreter
- Posted by Ed Davis <ed_davis2 at yahoo.com> Feb 28, 2006
- 474 views
Darly Border wrote: >I was experimenting with some code recently, when I discovered a >bug in the parser. The following code will parse without >complaint, but does not work properly. > >for n = 1 to 10 do > if 4 < n < 8 then > ? n > end if >end for > >This program should display the numbers 5,6,and 7. It actually >displays the number 1 through 10. > >The problem is with function rexpr() in parser.e which parses >the expression 4 < n < 8. If the value of n is 1, it calcualtes >4 < 1 which is FALSE. It then calculates FALSE < 8 which is >meaningless because FALSE is not a number. Because TRUE and >FALSE are represented by the numbers 1 and 0, the computer can >perform the calcualtion. And because both 0 and 1 are less than >8, the expression will evaluate to TRUE no matter what value n >contains. While I think "4 < n < 8" is a nice shortcut, what about "(4 < n) < 8"? It is also accepted by Euphoria. How should it be evaluated? Perhaps a question to ask is are Euphoria expressions meant to be more C-like or Pascal-like. Or something in between? Something entirely different? C will accept both of the above expressions, but will evaluate both as the latter expression, where "4 < n" returns a 0 or 1 depending on the truth value of the expression. Basically the way Euphoria is evaluating it now. Pascal will accept neither expression, because relational operators require an integer expression, and "4 < n" is a boolean expression, parenthesized or not. It would be kind of cool if Euphoria could properly handle "4 < n < 8", but you'd have to define 'properly', and you'd also have to have special code for "(4 < n) < 8", so that the relational operators behaved consistently. I think it would bother me if Euphoria handled "4 < n < 8" 'properly' (e.g., not as it does now), but continued to support "(4 < n) < 8". That seems awfully inconsistent. I think the viable solutions are: 1) Leave it the way it is. It might be nice to document the behavior. Essentially C-like behavior. 2) Make expressions more Pascal-like, and thus prohibit "4 < n < 8" and "(4 < n) < 8" altogether. The former expression is easy to prohibit via a grammar change. The latter would require expressions to be typed as number vs. boolean. This might be a lot of work, and it might introduce unwanted side effects. 3) Make "4 < n < 8" work the way a non-C programmer thinks it should work, e.g., "4 < n" and "n < 8". And then prohibit "(4 < n) < 8", as it would make no sense anymore. You've already solved the first problem. However, as in number 2 above, prohibiting the latter expression might be a lot of work, and it might introduce unwanted side effects. This reminds me of a question I've had: is there an official Euphoria grammar?
4. Re: A bug in the interpreter
- Posted by Daryl Border <Darylb5 at aol.com> Feb 28, 2006
- 458 views
- Last edited Mar 01, 2006
Ed Davis wrote: > > Darly Border wrote: > > >I was experimenting with some code recently, when I discovered a > >bug in the parser. The following code will parse without > >complaint, but does not work properly. > > > >for n = 1 to 10 do > > if 4 < n < 8 then > > ? n > > end if > >end for > > > >This program should display the numbers 5,6,and 7. It actually > >displays the number 1 through 10. > > > >The problem is with function rexpr() in parser.e which parses > >the expression 4 < n < 8. If the value of n is 1, it calcualtes > >4 < 1 which is FALSE. It then calculates FALSE < 8 which is > >meaningless because FALSE is not a number. Because TRUE and > >FALSE are represented by the numbers 1 and 0, the computer can > >perform the calcualtion. And because both 0 and 1 are less than > >8, the expression will evaluate to TRUE no matter what value n > >contains. > > While I think "4 < n < 8" is a nice shortcut, what about > "(4 < n) < 8"? It is also accepted by Euphoria. How should it > be evaluated? > > Perhaps a question to ask is are Euphoria expressions meant to be > more C-like or Pascal-like. Or something in between? Something > entirely different? > > C will accept both of the above expressions, but will evaluate > both as the latter expression, where "4 < n" returns a 0 or 1 > depending on the truth value of the expression. Basically the > way Euphoria is evaluating it now. > > Pascal will accept neither expression, because relational > operators require an integer expression, and "4 < n" is a boolean > expression, parenthesized or not. > > It would be kind of cool if Euphoria could properly handle "4 < n > < 8", but you'd have to define 'properly', and you'd also have to > have special code for "(4 < n) < 8", so that the relational > operators behaved consistently. > > I think it would bother me if Euphoria handled "4 < n < 8" > 'properly' (e.g., not as it does now), but continued to support > "(4 < n) < 8". That seems awfully inconsistent. > > I think the viable solutions are: > > 1) Leave it the way it is. It might be nice to document the > behavior. Essentially C-like behavior. > > 2) Make expressions more Pascal-like, and thus prohibit "4 < n < > 8" and "(4 < n) < 8" altogether. The former expression is easy > to prohibit via a grammar change. The latter would require > expressions to be typed as number vs. boolean. This might be a > lot of work, and it might introduce unwanted side effects. > > 3) Make "4 < n < 8" work the way a non-C programmer thinks it > should work, e.g., "4 < n" and "n < 8". And then prohibit "(4 < > n) < 8", as it would make no sense anymore. You've already > solved the first problem. However, as in number 2 above, > prohibiting the latter expression might be a lot of work, and it > might introduce unwanted side effects. > > This reminds me of a question I've had: is there an official > Euphoria grammar? Ed, It is not the responsibility of the interpreter to prevent the programmer from using poorly formed expressions such as (4 < n) < 8. It is the responsibility of the interpreter to evaluate the expressions according to the rules of mathmatics. My code evaluates both expressions correctly. Euphoria currently does not. Daryl Border
5. Re: A bug in the interpreter
- Posted by Alex Chamberlain <alex.chamberlain at tiscali.co.uk> Feb 28, 2006
- 449 views
- Last edited Mar 01, 2006
Mathematically, 4 < n < 8 should evaluate to 4 < n and n < 8. Euphoria should develop to reflect this as it is "correct". (4 < n) < 8 is different - as I see it. If n = 32, (4 < n) < 8 = TRUE < 8 = 1 < 8 = TRUE which is incorrect! Alex
6. Re: A bug in the interpreter
- Posted by Jason Gade <jaygade at yahoo.com> Feb 28, 2006
- 447 views
- Last edited Mar 01, 2006
Alex Chamberlain wrote: > > Mathematically, 4 < n < 8 should evaluate to 4 < n and n < 8. Euphoria > should develop to reflect this as it is "correct". > > (4 < n) < 8 is different - as I see it. > > If n = 32, > (4 < n) < 8 = TRUE < 8 = 1 < 8 = TRUE which is incorrect! > > Alex I understand the mathematics behind it, but it is just notation. I can't think of any other common programming language that uses notation like this. Most languages that I'm aware of require the keyword 'and' to disambiguate the expression. For the second example, the programmer needs to be aware that comparing TRUE and 8 has no mathematical meaning. Since Euphoria doesn't have built-in boolean types the language just uses 1 and 0 as TRUE and FALSE. Some other languages use -1 and 0. Euphoria will also interpret any nonzero value as TRUE in the proper context. Again, this is pretty standard behavior in programming languages. Or at least the ones I'm familiar with (C and relatives, BASIC, Euphoria). -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
7. Re: A bug in the interpreter
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 28, 2006
- 449 views
- Last edited Mar 01, 2006
Ed Davis wrote: > This reminds me of a question I've had: is there an official > Euphoria grammar? No there isn't. Someone started to write one once, but I don't know if he finished it. The syntax of Euphoria is simple enough that I think most people can figure it out from the reference manual, and now there's the PD source to resolve any doubts. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
8. Re: A bug in the interpreter
- Posted by Ed Davis <ed_davis2 at yahoo.com> Feb 28, 2006
- 453 views
- Last edited Mar 01, 2006
Daryl Border > It is not the responsibility of the interpreter to prevent >the programmer from using poorly formed expressions such as (4 < >n) < 8. Some people might say that "4 < n < 8" is a poorly formed expression. If you are coming from the C/Java world, you would say it is perfectly valid, but it does not mean "4 < n and n < 8", but rather the (4 < n) < 8. >It is the responsibility of the interpreter to evaluate the >expressions according to the rules of mathmatics. My code >evaluates both expressions correctly. Euphoria currently does >not. How does it correctly evaluate (4 < n) < 8? Does it treat (4 < n) as a boolean, and then compare against that? What about "4 < n < 8 < a < b"? How should that be evaluated? Is it "4 < n and n < 8 and 8 < a and a < b?" Should the interpreter allow that? How do your changes evaluate it? Along the same lines, what about: "4 = n = 8"? It is also currently accepted, and apparently interpreted as: (4 = n) = 8 The same way C would interpret it (well, replace the '=' with '=='). Without understanding all the possible ramifications, I'm not sure changing the current semantics is a good idea.
9. Re: A bug in the interpreter
- Posted by Daryl Border <Darylb5 at aol.com> Feb 28, 2006
- 449 views
- Last edited Mar 01, 2006
Ed Davis wrote: > > Daryl Border > > > It is not the responsibility of the interpreter to prevent > >the programmer from using poorly formed expressions such as (4 < > >n) < 8. > > Some people might say that "4 < n < 8" is a poorly formed > expression. If you are coming from the C/Java world, you would > say it is perfectly valid, but it does not mean "4 < n and n < > 8", but rather the (4 < n) < 8. > > >It is the responsibility of the interpreter to evaluate the > >expressions according to the rules of mathmatics. My code > >evaluates both expressions correctly. Euphoria currently does > >not. > > How does it correctly evaluate (4 < n) < 8? Does it treat (4 < > n) as a boolean, and then compare against that? You are correct. (4 < n) < 8 is not a valid math expression. My code can't evaluate it correctly because there is no valid way to evaluate it. It would be nice if the interpreter could catch the error. But without a way to distinguish between the integers 1 and 0 and the boolean values TRUE and FALSE it can't. This problem already exists in euphoria, my code does not create it. > > What about "4 < n < 8 < a < b"? How should that be evaluated? Is > it "4 < n and n < 8 and 8 < a and a < b?" Should the interpreter > allow that? How do your changes evaluate it? > This is a valid math expression and your interpretation is correct. If my code is bug free it will evaluate it correctly. > Along the same lines, what about: "4 = n = 8"? It is also > currently accepted, and apparently interpreted as: > 4 = n = 8 is a valid math expression and will be evaluated as 4 = n and n = 8. It of course always evaluates to FALSE, but it is the programmer's responsibility to write useful code. > (4 = n) = 8 Again (4 = n) = 8 is not a valid math expression because (4 = n) evaluates to a boolean value. > > The same way C would interpret it (well, replace the '=' with > '=='). > > Without understanding all the possible ramifications, I'm not > sure changing the current semantics is a good idea. The problems you're concerned about already exist. Until a means to distinguish between integers and boolean values is implimented, they will continue to exist. In the mean time we will have to rely on the programmer's knowledge of math for correct math expressions. Daryl Border
10. Re: A bug in the interpreter
- Posted by Ricardo M. Forno <rmforno at tutopia.com> Mar 01, 2006
- 457 views
Ed Davis wrote: > > Daryl Border > > > It is not the responsibility of the interpreter to prevent > >the programmer from using poorly formed expressions such as (4 < > >n) < 8. > > Some people might say that "4 < n < 8" is a poorly formed > expression. If you are coming from the C/Java world, you would > say it is perfectly valid, but it does not mean "4 < n and n < > 8", but rather the (4 < n) < 8. > > >It is the responsibility of the interpreter to evaluate the > >expressions according to the rules of mathmatics. My code > >evaluates both expressions correctly. Euphoria currently does > >not. > > How does it correctly evaluate (4 < n) < 8? Does it treat (4 < > n) as a boolean, and then compare against that? > > What about "4 < n < 8 < a < b"? How should that be evaluated? Is > it "4 < n and n < 8 and 8 < a and a < b?" Should the interpreter > allow that? How do your changes evaluate it? > > Along the same lines, what about: "4 = n = 8"? It is also > currently accepted, and apparently interpreted as: > > (4 = n) = 8 > > The same way C would interpret it (well, replace the '=' with > '=='). > > Without understanding all the possible ramifications, I'm not > sure changing the current semantics is a good idea. One of the languages that has something similar is good old COBOL, because you may omit the variable name in the second comparison, but anyway it uses 'and'. Anyway, I think the main issue is this: are there fixed rules for the syntax and semantics of mathematical expressions? Newton, Leibnitz, Fermat, Euler, Gauss, etc,. all of them used different notations. What I was taught at school is now totally different. And I see the time coming when mathematical notation will evolve from computer programming languages. Regards.
11. Re: A bug in the interpreter
- Posted by Jason Gade <jaygade at yahoo.com> Mar 01, 2006
- 468 views
Ricardo M. Forno wrote: > One of the languages that has something similar is good old COBOL, > because you may omit the variable name in the second comparison, > but anyway it uses 'and'. > Anyway, I think the main issue is this: are there fixed rules for > the syntax and semantics of mathematical expressions? Newton, > Leibnitz, Fermat, Euler, Gauss, etc,. all of them used different > notations. What I was taught at school is now totally different. > And I see the time coming when mathematical notation will evolve > from computer programming languages. > > Regards. It is actually pretty simple. Given parentheses to group operations and the precedence of operations, mathematical expressions are evaluated from left to right. No operator in Euphoria is trinary; therefore expressions such as 4 < n < 8 are considered as two binary operations evaluated from left to right. First, 4 < n is evaluated then its result, 1 or 0, is compared to < 8. Euphoria's precedence is found at http://www.rapideuphoria.com/refman_2.htm#2A -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
12. Re: A bug in the interpreter
- Posted by Ricardo M. Forno <rmforno at tutopia.com> Mar 01, 2006
- 464 views
Jason Gade wrote: > > Ricardo M. Forno wrote: > > One of the languages that has something similar is good old COBOL, > > because you may omit the variable name in the second comparison, > > but anyway it uses 'and'. > > Anyway, I think the main issue is this: are there fixed rules for > > the syntax and semantics of mathematical expressions? Newton, > > Leibnitz, Fermat, Euler, Gauss, etc,. all of them used different > > notations. What I was taught at school is now totally different. > > And I see the time coming when mathematical notation will evolve > > from computer programming languages. > > > > Regards. > > It is actually pretty simple. Given parentheses to group operations and the > precedence > of operations, mathematical expressions are evaluated from left to right. No > operator > in Euphoria is trinary; therefore expressions such as 4 < n < 8 are considered > as two binary operations evaluated from left to right. First, 4 < n is > evaluated > then its result, 1 or 0, is compared to < 8. > > Euphoria's precedence is found at <a > href="http://www.rapideuphoria.com/refman_2.htm#2A">http://www.rapideuphoria.com/refman_2.htm#2A</a> > > -- > "Any programming problem can be solved by adding a level of indirection." > --anonymous > "Any performance problem can be solved by removing a level of indirection." > --M. Haertel > "Premature optimization is the root of all evil in programming." > --C.A.R. Hoare > j. Of course, Jason. I know this from the time I first programmed in C and Euphoria. It is really simple. Hovever, simpler than that is APL and J (do not confuse with Java) in which everything is evaluated from right to left, as assignment is evaluated. My concern was not about Euphoria but about math itself. There is no undisputed syntax / semantics for mathematical expressions. So it makes no sense to say, for example, that Euphoria does not follow mathematical conventions, since they are not uniform. For example, in algebra "ax" is usually interpreted as "a times x", and not as a variable named "ax". Also, sometimes a dot was used to mean "times", as in "a.x + c.y". The multiplication operator was a sign resembling "x" and not "*" as in programming languages. There are also a lot of strange symbols for square roots, derivatives, integrals, etc., for which there is no equivalent in computer programming languages. Regards.
13. Re: A bug in the interpreter
- Posted by Jason Gade <jaygade at yahoo.com> Mar 01, 2006
- 493 views
Ricardo M. Forno wrote: > > Jason Gade wrote: > > > > Ricardo M. Forno wrote: > > > One of the languages that has something similar is good old COBOL, > > > because you may omit the variable name in the second comparison, > > > but anyway it uses 'and'. > > > Anyway, I think the main issue is this: are there fixed rules for > > > the syntax and semantics of mathematical expressions? Newton, > > > Leibnitz, Fermat, Euler, Gauss, etc,. all of them used different > > > notations. What I was taught at school is now totally different. > > > And I see the time coming when mathematical notation will evolve > > > from computer programming languages. > > > > > > Regards. > > > > It is actually pretty simple. Given parentheses to group operations and the > > precedence > > of operations, mathematical expressions are evaluated from left to right. No > > operator > > in Euphoria is trinary; therefore expressions such as 4 < n < 8 are > > considered > > as two binary operations evaluated from left to right. First, 4 < n is > > evaluated > > then its result, 1 or 0, is compared to < 8. > > > > Euphoria's precedence is found at <a > > href="http://www.rapideuphoria.com/refman_2.htm#2A">http://www.rapideuphoria.com/refman_2.htm#2A</a> > > > > -- > > "Any programming problem can be solved by adding a level of indirection." > > --anonymous > > "Any performance problem can be solved by removing a level of indirection." > > --M. Haertel > > "Premature optimization is the root of all evil in programming." > > --C.A.R. Hoare > > j. > > Of course, Jason. I know this from the time I first programmed in C and > Euphoria. > It is really simple. Hovever, simpler than that is APL and J (do not confuse > with Java) > in which everything is evaluated from right to left, as assignment is > evaluated. > My concern was not about Euphoria but about math itself. There is no > undisputed > syntax / semantics for mathematical expressions. So it makes no sense to say, > for example, that Euphoria does not follow mathematical conventions, since > they are not uniform. For example, in algebra "ax" is usually interpreted as > "a times x", and not as a variable named "ax". Also, sometimes a dot was > used to mean "times", as in "a.x + c.y". The multiplication operator was > a sign resembling "x" and not "*" as in programming languages. There are also > a lot of strange symbols for square roots, derivatives, integrals, etc., for > which there is no equivalent in computer programming languages. > > Regards. I think you and I are in agreement. I may have replied to your post to make the point to others. You make the exact point that I wanted to make -- namely that there is more than one way in mathematics to symbolize an expression and there is more than one way to symbolize it in the domain of programming languages. You could say it is different in LISP and FORTH as well, which do not follow the normal algebraic rules for expressions. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.