1. Is it a bug or a feature?
- Posted by Christian.CUVIER at agriculture.gouv.fr Oct 14, 2002
- 341 views
The following piece of code: include get.e integer i,j,e25 atom c e25=1 i=3j=2 --line1 c=3.0e25=0 --line2 ?i ?j ?c ?e25 i=wait_key() prints out: 3 2 0 1 This raises two questions: 1/ Is the ability to forget whitespace between some statements (when there's a clear boundary) a bug or a feature? 2/ If it is a(n undocumented) feature, then the same behaviour could be expected from line1 and line2 (would yield c=3.0 and e25=0). Instead, the parsing of real numbers comes in the way. This difference in decoding looks like a bug, IMO. Or did I overlook anything? CChris
2. Re: Is it a bug or a feature?
- Posted by Igor Kachan <kinz at peterlink.ru> Oct 14, 2002
- 337 views
Hello Christian, ---------- > ïÔ: Christian.CUVIER at agriculture.gouv.fr > ëÏÍÕ: EUforum <EUforum at topica.com> > ôÅÍÁ: Is it a bug or a feature? > äÁÔÁ: 14 ÏËÔÑÂÒÑ 2002 Ç. 15:04 > The following piece of code: > > include get.e > integer i,j,e25 > atom c > > e25=1 > i=3j=2 --line1 > c=3.0e25=0 --line2 > ?i ?j ?c ?e25 > i=wait_key() > > prints out: > 3 > 2 > 0 > 1 > > This raises two questions: > 1/ Is the ability to forget whitespace between some statements (when > there's a clear boundary) a bug or a feature? > 2/ If it is a(n undocumented) feature, then the same behaviour could be > expected from line1 and line2 (would yield c=3.0 and e25=0). Instead, > the parsing of real numbers comes in the way. This difference in > decoding looks like a bug, IMO. > > Or did I overlook anything? > > CChris Just try the piece below: include get.e integer i,j,e25 atom c e25=1 i=3j=2 --line1 c = 3.0e25 = 0 --line2 ?i --3 ?j --2 ?c --0 ?e25 ?3.0e25 i=wait_key() See 3.0e25 - this is the exponential form of a number, so line2 is just the correct logical expression and EU interpreter doesn't confuse it and e25 variable. This thing is the correct feature, it seems to be. But too imressive on the first look. The very good and clever interpreter, no? Regards, Igor Kachan kinz at peterlink.ru
3. Re: Is it a bug or a feature?
- Posted by Christian.CUVIER at agriculture.gouv.fr Oct 14, 2002
- 349 views
Well, I clearly see that ex.exe "cleverly" identified a number in scientific notation, and made a syntactically correct parsing of line2. Because this clever behaviour leads to different handlings for the same mistake (forgetting the space), leading to unpredicted result without an error, I find it slightly dangerous. I never deliberately glue statements in this way, so it doesn't bother me really. I'd expect c=3.0e25=0 to read as c=3.0 e25=0 (consistent with line1); a proper coding for the other solution might be c=(3.0e25=0). At least, why not issue a warning in such ambiguous cases? Regards. CChris ----------------Original message Just try the piece below: include get.e integer i,j,e25 atom c e25=1 i=3j=2 --line1 c = 3.0e25 = 0 --line2 ?i --3 ?j --2 ?c --0 ?e25 ?3.0e25 i=wait_key() See 3.0e25 - this is the exponential form of a number, so line2 is just the correct logical expression and EU interpreter doesn't confuse it and e25 variable. This thing is the correct feature, it seems to be. But too imressive on the first look. The very good and clever interpreter, no? Regards, Igor Kachan kinz at peterlink.ru
4. Re: Is it a bug or a feature?
- Posted by Igor Kachan <kinz at peterlink.ru> Oct 14, 2002
- 349 views
Christian writes: ---------- > ïÔ: Christian.CUVIER at agriculture.gouv.fr > ëÏÍÕ: EUforum <EUforum at topica.com> > ôÅÍÁ: Re: Is it a bug or a feature? > äÁÔÁ: 14 ÏËÔÑÂÒÑ 2002 Ç. 19:32 > > Well, I clearly see that ex.exe "cleverly" identified a number in > scientific notation, and made a syntactically correct parsing of line2. > Because this clever behaviour leads to different handlings for the same > mistake (forgetting the space), leading to unpredicted result without an > error, I find it slightly dangerous. I never deliberately glue > statements in this way, so it doesn't bother me really. > I'd expect c=3.0e25=0 to read as c=3.0 e25=0 (consistent with line1); a > proper coding for the other solution might be c=(3.0e25=0). > At least, why not issue a warning in such ambiguous cases? > Regards. > CChris Try please the case below: c=3.0a25=0 See 'a', not 'e'. Works fine without spaces, and 'e' is just the special letter for the exponente. Do not use 'e' at all for such the variable names. This 'e' is special not only in EU. Regards, Igor Kachan kinz at peterlink.ru