1. Is it a bug or a feature?
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?
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?
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?
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
