[Pharo-project] [squeak-dev] Re: The Trunk: Multilingual-ar.87.mcz

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Feb 12 15:50:31 EST 2010


2010/2/12  <csrabak at bol.com.br>:
> Em 12/02/2010 13:16, Nicolas Cellier < nicolas.cellier.aka.nice at gmail.com > escreveu:
>
>> 2010/2/12 <csrabak at 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 at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>




More information about the Pharo-dev mailing list