Hi Juan,


On Thu, Aug 7, 2014 at 9:40 AM, J. Vuletich (mail lists) <
juanlists at jvuletich.org> wrote:

>  Hi Folks,
>
> Just tried Smalltalk-80 (actually Apple Smalltalk-80 running in Mini vMac).
> 1e-3 "printIt" (1/1000)
> 1e-3 class "printIt" Fraction
> 1e3 "printIt" 1000
> 1e3 class "printIt" SmallInteger
>
> This has always been the behavior in Squeak too.
>

What happens if you try compiling a method containing a literal Fraction
and both debug it and decompile it.

> Also check these comments from Dan:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.html
>

Dan doesn't say anything about Fraction literals in this message.


> I don't think this is a bug at all.
>

What, that 1e-3 is a Fraction, not a Float?


> BTW, Cuis also supports 1r111111111111 = 12 after this :)
>
> Cheers,
> Juan Vuletich
>
> Quoting Eliot Miranda <eliot.miranda at gmail.com>:
>
>
>
>
> On Thu, Aug 7, 2014 at 9:05 AM, Levente Uzonyi <leves at elte.hu> wrote:
>
>> On Wed, 6 Aug 2014, Eliot Miranda wrote:
>>
>>  Hi Levente,
>>>
>>> On Wed, Aug 6, 2014 at 11:43 AM, Levente Uzonyi <leves at elte.hu> wrote:
>>>       On Wed, 6 Aug 2014, Eliot Miranda wrote:
>>>
>>>             Hi All,
>>>                 Squeak trunk also suffers from the Float parsed as a
>>> Fraction bug:
>>>
>>>             1e-8 class Fraction
>>>             1.0e8 class Float
>>>
>>>
>>> I'm not entirely sure about it being a bug. I've checked Squeak 3.8
>>> (pre-SqNumberParser), and it also parsed that literal as a Fraction. If I
>>> want a Float, I can be explicit and use 1.0e-8.
>>>
>>>
>>> IMO it very much *is* a bug.  Smalltalk-80 has never supported Fraction
>>> literals.  They're always written as division expressions.  Fraction
>>> answers false to isLiteral.  Just because it worked that way
>>> doesn't mean it was right.  I suspect no one noticed.  Allowing Fraction
>>> literals feels like a big change to me.
>>>
>>  It's more like undefined behavior than a bug IMHO, though the lack of
>> #isLiteral makes me think that the Fractions are not intentional.
>> Interesting how Nicolas's SqNumberParser behaves the same way as the
>> previous number parser in this case.
>>
>>
>>
>>>       I made a modified version of Fraction >> #printOn:base: which
>>> outputs the literal format if possible. The change "fixes" the debugger
>>> (note that itw was way less broken in Squeak than in Pharo
>>>       anyway).
>>>       The only drawback I found is that some fractions become a bit more
>>> "complex" when printed, e.g. 3/4 => 75e-2
>>>
>>>
>>> OK, but is this the right fix?  What does everybody think?  Keep the
>>> language unchanged or add Fraction literals and add another incompatibility
>>> with other dialects?
>>>
>>  I don't think that anyone ever used this "feature" before, so doing what
>> other dialects do is probably the best way to resolve this.
>
>
> Agreed.  Smalltalk-80 v2 had no literal fractions.  ObjectWorks and
> VisualWorks have never had literal fractions.  I can't speak for other
> dialects, but I'm fairly sure none of the Smalltalk/V, Team/V lineage had
> literal Fractions either.
>
>
>>  If Fractions are literals
>>> - what is the semantics of 1/0 (easy, it is not a literal, but needs to
>>> be stated)?
>>> - what is [1/0.1] on: ZeroDivide do: [:ex| #error] ?  Is it 10.0 or
>>> #error, i.e. is 1/0.1 10.0 or 1 / 0 followed by the Integer 1?
>>>
>>  I did not propose to make all fractions literals. My implementation
>> simply prints decimal fractions with the exponent notation, e.g. 3/4 is
>> printed as 75-e2, but 2/3 is still printed as (2/3).
>>
>>
>> Levente
>>
>>
>>
>>>       Levente
>>>             --
>>>             eek! Eliot
>>>
>>> --
>>> best,Eliot
>>>
>>>
>>
>>
>>
>
>
>
>
> --
> best,
> Eliot
>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140807/91be7f8e/attachment.htm