Smalltalk › Squeak › Squeak - Dev

[squeak-dev] Number readFrom: can we remove some "accidental" features

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

Nicolas Cellier-3

[squeak-dev] Number readFrom: can we remove some "accidental" features

Strangely, Squeak Number class>>#readfrom: used to accept non Smalltalk
syntax like:
(Number readFrom: '.2') -> 0.2 .
(Number readFrom: '2.e3') -> 2000.0 .

(See
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/103137.html)

Don't know if accidental or on purpose, but to me, this is wrong and I
did not implement this behavior in SqNumberParser because there is no
such official Smalltalk syntax to my knowledge.

Up to any one to accept an alternate number syntax by subclassing
SqNumberParser.

Now I see that Dave Lewis (dtl) asserted this feature:

testAsNumberWithSuperfluousDecimalPoint
| sd |
sd _ '123.s2' asNumber.
self assert: ScaledDecimal == sd class.
self assert: sd scale == 2.
self assert: '123.00s2' = sd printString.

I'd like to remove this feature.
Is it ok?

stephane ducasse

Re: [squeak-dev] Number readFrom: can we remove some "accidental" features

Yes please remove that.

Stef

On Aug 31, 2008, at 2:13 AM, nicolas cellier wrote:

>
> Strangely, Squeak Number class>>#readfrom: used to accept non
> Smalltalk syntax like:
> (Number readFrom: '.2') -> 0.2 .
> (Number readFrom: '2.e3') -> 2000.0 .
>
> (See http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/103137.html)
>
> Don't know if accidental or on purpose, but to me, this is wrong and
> I did not implement this behavior in SqNumberParser because there is
> no such official Smalltalk syntax to my knowledge.
>
> Up to any one to accept an alternate number syntax by subclassing
> SqNumberParser.
>
> Now I see that Dave Lewis (dtl) asserted this feature:
>
> testAsNumberWithSuperfluousDecimalPoint
> | sd |
> sd _ '123.s2' asNumber.
> self assert: ScaledDecimal == sd class.
> self assert: sd scale == 2.
> self assert: '123.00s2' = sd printString.
>
> I'd like to remove this feature.
> Is it ok?
>
>
>

David T. Lewis

Re: [squeak-dev] Number readFrom: can we remove some "accidental" features

In reply to this post by Nicolas Cellier-3

On Sun, Aug 31, 2008 at 02:13:10AM +0200, nicolas cellier wrote:

>
> Strangely, Squeak Number class>>#readfrom: used to accept non Smalltalk
> syntax like:
> (Number readFrom: '.2') -> 0.2 .
> (Number readFrom: '2.e3') -> 2000.0 .
>
> (See
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/103137.html)
>
> Don't know if accidental or on purpose, but to me, this is wrong and I
> did not implement this behavior in SqNumberParser because there is no
> such official Smalltalk syntax to my knowledge.
>
> Up to any one to accept an alternate number syntax by subclassing
> SqNumberParser.
>
> Now I see that Dave Lewis (dtl) asserted this feature:
>
> testAsNumberWithSuperfluousDecimalPoint
> | sd |
> sd _ '123.s2' asNumber.
> self assert: ScaledDecimal == sd class.
> self assert: sd scale == 2.
> self assert: '123.00s2' = sd printString.
>

This originates from Mantis #156 (http://bugs.squeak.org/view.php?id=158).

> I'd like to remove this feature.
> Is it ok?

If you change it, please change the tests to match. IIRC, the
Mantis 156 patch corrected some bad problems that originated
from the addition of ScaledDecimal to the system. I wrote the
ScaledDecimalTest unit tests to document what I did, and I used
"Smalltalk-80 The Language" as a guide where I could. I am not
an expert in numerics or Smalltalk syntax, so it may not be right.
>From my point of view, as long as the tests are kept up to date
with the implementation, I'll be happy.

I would suggest opening a Mantis report for the change, and tie
it to Mantis 156 so folks will know the background.

Dave

Stéphane Rollandin

Re: [squeak-dev] Number readFrom: can we remove some "accidental" features

In reply to this post by Nicolas Cellier-3

nicolas cellier a écrit :
>
> Strangely, Squeak Number class>>#readfrom: used to accept non Smalltalk
> syntax like:
> (Number readFrom: '.2') -> 0.2 .
> (Number readFrom: '2.e3') -> 2000.0 .

> Now I see that Dave Lewis (dtl) asserted this feature:

> I'd like to remove this feature.
> Is it ok?

I would vote for allowing those formats.

Stef

Igor Stasenko

Re: [squeak-dev] Number readFrom: can we remove some "accidental" features

2008/8/31 Stéphane Rollandin <[hidden email]>:

> nicolas cellier a écrit :
>>
>> Strangely, Squeak Number class>>#readfrom: used to accept non Smalltalk
>> syntax like:
>> (Number readFrom: '.2') -> 0.2 .
>> (Number readFrom: '2.e3') -> 2000.0 .
>
>> Now I see that Dave Lewis (dtl) asserted this feature:
>
>> I'd like to remove this feature.
>> Is it ok?
>
> I would vote for allowing those formats.
>

My guess it can stay, but only as separate helper method, which reads
a numbers and expecting non-smalltalk syntax.
And making sure that this behavior is completely separated from compiler!

> Stef
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Stéphane Rollandin

Re: [squeak-dev] Number readFrom: can we remove some "accidental" features

Igor Stasenko a écrit :
> My guess it can stay, but only as separate helper method, which reads
> a numbers and expecting non-smalltalk syntax.

yes, useful for end-user input in numerical applications.
we could spare them the .2 = 2 experience...

Stef

Igor Stasenko

Re: [squeak-dev] Number readFrom: can we remove some "accidental" features

2008/8/31 Stéphane Rollandin <[hidden email]>:
> Igor Stasenko a écrit :
>>
>> My guess it can stay, but only as separate helper method, which reads
>> a numbers and expecting non-smalltalk syntax.
>
> yes, useful for end-user input in numerical applications.
> we could spare them the .2 = 2 experience...
>

Btw, everyone is content with such ambigility?

{ 0.2.3.4.5.6 } printString '#(0.2 3.4 5.6)'

> Stef
>

--
Best regards,
Igor Stasenko AKA sig.

Klaus D. Witzel

[squeak-dev] Re: Number readFrom: can we remove some "accidental" features

On Sun, 31 Aug 2008 20:20:43 +0200, Igor Stasenko wrote:

> 2008/8/31 Stéphane Rollandin :
>> Igor Stasenko a écrit :
>>>
>>> My guess it can stay, but only as separate helper method, which reads
>>> a numbers and expecting non-smalltalk syntax.
>>
>> yes, useful for end-user input in numerical applications.
>> we could spare them the .2 = 2 experience...
>>
>
> Btw, everyone is content with such ambigility?
>
> { 0.2.3.4.5.6 } printString '#(0.2 3.4 5.6)'

Why #printString, why evaluate things unneccessarily, why pollute .changes
file?

In some Squeak .images the menu entry "pretty print" works (even before
doing the first alt-s), so you can ask an expensive and unmatched expert
system if it already understands what you mean ;)

>> Stef
>>
>
>

Nicolas Cellier-3

[squeak-dev] Re: Number readFrom: can we remove some "accidental" features

In reply to this post by Igor Stasenko

Igor Stasenko a écrit :

> 2008/8/31 Stéphane Rollandin <[hidden email]>:
>> nicolas cellier a écrit :
>>> Strangely, Squeak Number class>>#readfrom: used to accept non Smalltalk
>>> syntax like:
>>> (Number readFrom: '.2') -> 0.2 .
>>> (Number readFrom: '2.e3') -> 2000.0 .
>>> Now I see that Dave Lewis (dtl) asserted this feature:
>>> I'd like to remove this feature.
>>> Is it ok?
>> I would vote for allowing those formats.
>>
>
> My guess it can stay, but only as separate helper method, which reads
> a numbers and expecting non-smalltalk syntax.
> And making sure that this behavior is completely separated from compiler!
>

Agree, that's a requirement, ambiguous syntax must be avoided, and
compatibility with other ST dialects not altered too much.

Then nothing prevents having two utility messages and/or two
NumberParser subclasses (or more).
As long as kernel code doing the conversion decimal->binary is not
duplicated (It's already hard enough to get it doing things exactly,
better not maintain two versions).

The question remains if the extended syntax should be part of the
kernel, or not, and if yes, what syntax exactly?

My feeling is that such extension should be a package.

>> Stef
>>
>>
>>
> ------------------------------------------------------------------------

Nicolas Cellier-3

[squeak-dev] Re: Number readFrom: can we remove some "accidental" features

In reply to this post by Igor Stasenko

Igor Stasenko a écrit :

> 2008/8/31 Stéphane Rollandin <[hidden email]>:
>> Igor Stasenko a écrit :
>>> My guess it can stay, but only as separate helper method, which reads
>>> a numbers and expecting non-smalltalk syntax.
>> yes, useful for end-user input in numerical applications.
>> we could spare them the .2 = 2 experience...
>>
>
> Btw, everyone is content with such ambigility?
>
> { 0.2.3.4.5.6 } printString '#(0.2 3.4 5.6)'
>

Yes funny.
Guess in which language you can evaluate

-3r=3r-.-3r-=3r

No, it is not /etc/printcap.
That's why Stef (Ducasse) asked for cleanup I guess.

Alejandro F. Reimondo

Re: [squeak-dev] Re: Number readFrom: can we remove some "accidental"features

Hi!

>> { 0.2.3.4.5.6 } printString '#(0.2 3.4 5.6)'

Under my eyes, the problem is related with
the non-smalltalk syntax of braces...
The problem is a side effect of queueing
sentences in a pseudo-array notation
(remove the braces and the ambiguity
vanishes).

IMO, all said to non-st numeric notation is
correct, and the same work (of remotion)
must be done on {....} syntax.
The same is applicable to ifNil:... and friends
because it promote the idea (in newbies) that
it is better to write faster...

cheers,
Ale.

----- Original Message -----
From: "nicolas cellier" <[hidden email]>
To: <[hidden email]>
Sent: Sunday, August 31, 2008 4:12 PM
Subject: [squeak-dev] Re: Number readFrom: can we remove some
"accidental"features

> Igor Stasenko a écrit :
>> 2008/8/31 Stéphane Rollandin <[hidden email]>:
>>> Igor Stasenko a écrit :
>>>> My guess it can stay, but only as separate helper method, which reads
>>>> a numbers and expecting non-smalltalk syntax.
>>> yes, useful for end-user input in numerical applications.
>>> we could spare them the .2 = 2 experience...
>>>
>>
>> Btw, everyone is content with such ambigility?
>>
>> { 0.2.3.4.5.6 } printString '#(0.2 3.4 5.6)'
>>
>
> Yes funny.
> Guess in which language you can evaluate
>
> -3r=3r-.-3r-=3r
>
> No, it is not /etc/printcap.
> That's why Stef (Ducasse) asked for cleanup I guess.
>
>
>

Eliot Miranda-2

Re: [squeak-dev] Re: Number readFrom: can we remove some "accidental"features

I feel very strongly that . as a statement separator *must* be followed with at least one whitespace character and that the ramar should reflect this. But I know some people disagree strongly. If I were designing a successor language to smalltalk I would add this to the syntax. The argument fort me is one of readability and flexibility. I don't see 1 foo.2 bar.3 baz as readable.

1 foo.

2 bar.

3 baz

is much more readable. Further, being able to use . in literal symbols is nice. The Borning/Ingalls multiple inheritance system used this feature so that one could say e.g.

self SomeSuperclass.selector

to indicate one wanted to use the implementation inherited from SomeSuperclass, instead of using the potentially ambiguous super.

So by requiring the statement separator to be a period and one or more whitespace characters the ambiguity disappears, and .2 could be legal Smalltalk syntax.

On Sun, Aug 31, 2008 at 2:33 PM, Alejandro F. Reimondo <[hidden email]> wrote:

Hi!

{ 0.2.3.4.5.6 } printString '#(0.2 3.4 5.6)'

Under my eyes, the problem is related with
the non-smalltalk syntax of braces...
The problem is a side effect of queueing
sentences in a pseudo-array notation
(remove the braces and the ambiguity
vanishes).

IMO, all said to non-st numeric notation is
correct, and the same work (of remotion)
must be done on {....} syntax.
The same is applicable to ifNil:... and friends
because it promote the idea (in newbies) that
it is better to write faster...

cheers,
Ale.

----- Original Message ----- From: "nicolas cellier" <[hidden email]>
To: <[hidden email]>
Sent: Sunday, August 31, 2008 4:12 PM
Subject: [squeak-dev] Re: Number readFrom: can we remove some "accidental"features

Igor Stasenko a écrit :

2008/8/31 Stéphane Rollandin <[hidden email]>:

Igor Stasenko a écrit :

My guess it can stay, but only as separate helper method, which reads
a numbers and expecting non-smalltalk syntax.

yes, useful for end-user input in numerical applications.
we could spare them the .2 = 2 experience...

Btw, everyone is content with such ambigility?

{ 0.2.3.4.5.6 } printString '#(0.2 3.4 5.6)'

Yes funny.
Guess in which language you can evaluate

-3r=3r-.-3r-=3r

No, it is not /etc/printcap.
That's why Stef (Ducasse) asked for cleanup I guess.

Paolo Bonzini-2

[squeak-dev] Re: Number readFrom: can we remove some "accidental"features

In reply to this post by Alejandro F. Reimondo

>>> { 0.2.3.4.5.6 } printString '#(0.2 3.4 5.6)'
>
> Under my eyes, the problem is related with
> the non-smalltalk syntax of braces...

Not really. Using GNU Smalltalk just because it prints the result of
every statement separately, I get:

st> 0.2.3.4.5.6
0.2
3.4
5.6
st>

Braces are not a problem in this case.

I would be in favor of only accepting . as a statement separator if it
is followed by whitespace, but I would rather see other dialects do the
same.

Paolo

Karl Ramberg

Re: [squeak-dev] Re: Number readFrom: can we remove some "accidental"features

Paolo Bonzini wrote:

>>>> { 0.2.3.4.5.6 } printString '#(0.2 3.4 5.6)'
>>>>
>> Under my eyes, the problem is related with
>> the non-smalltalk syntax of braces...
>>
>
> Not really. Using GNU Smalltalk just because it prints the result of
> every statement separately, I get:
>
> st> 0.2.3.4.5.6
> 0.2
> 3.4
> 5.6
> st>
>
> Braces are not a problem in this case.
>
> I would be in favor of only accepting . as a statement separator if it
> is followed by whitespace, but I would rather see other dialects do the
> same.
>
> Paolo
>
>
>

Problem could be dealt with with a syntax colorizer that made such
things obvious, but then you would have to use the syntax colorizer all
the time...

karl