2010/2/12 <csrabak@bol.com.br>:
Em 12/02/2010 13:16, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com > escreveu:
2010/2/12 <csrabak@bol.com.br>:
Except if  my analytical  skills are impaired  by being  tired and groggy due a very short sleep  I think the solution to this is only a matter of putting: sourceStream peekFor: $+. just   before  eneg   :=  sourceStream   peekFor:   $-.  in SqNumberParser>>readExponent Did I miss something fundamental? my 0.01999. . . .
-- Cesar Rabak
 Yes,  it's   trivial.   It's  already   implemented  in  the DolphinNumberParser,  because Dolphin syntax  allow 1.0e+2  In st-80 and current squeak, this rather means 1.0 e + 2 (send #e to 1.0 then send #+ with argument 2 to the result)
I'm may be biased here but I don't follow ST-80 behaviour as reasonable (although sensible from the POV of Smalltalk syntax).
I guess one of st-80 goals was to have minimal syntax. With this respect, the plus sign is absolutely void (in the sense it adds no information). With this rationale, it was just useless to create rules for +2 and 1.0e+2. So it makes sense. Now, we can change this if there is consensus. I suggest in this case to also make a separator mandatory after end of sentence period.
Also, I don't know the origin of the fork, but while in Squeak performing in Workspace:
1.0012e+3 + 1 rises an error about Float(Object) DNU #e,
in Pharo (PharoCore1.0rc2 Latest update: #10509) the code above generates the answer " 1002.23" which is what I would expect.
I don't know about Pharo1.0, but Pharo1.1 fails (DNU #e) as most Smalltalk do (but Dolphin AFAIK).
 Other features are not so hard  either.  We have to measure all the consequences then just decide what is worth.
My only 'other feature' request would be to have the case sensitiveness for the 'e' of exponent notation removed, as it would ease the import of data from CSV files. . .
IIRC I already mentioned that in Pharo's mailing list.
From my exposition above, I _think_ we should fix SqNumberParser>>readExponent in order to have a system which is consistent internally.
This begs another question: from where Pharo converts the string in Shout Workspace to number which has a different behaviour than SqNumberParser??
Mysteries of OO in Smalltalk?
HTH
-- Cesar Rabak
PS.: On a side note I would like to comment that the method 'nextNumber' which is the one ultimately used to fetch the number from SqNumberParser seems to me to have a non intuitive name. . . Â Sorry I cannot concoct any better name right now to offer as a suggestion :-|
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project