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.htm...)
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?
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.htm...)
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?
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.htm...)
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
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
2008/8/31 Stéphane Rollandin lecteur@zogotounga.net:
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
2008/8/31 Stéphane Rollandin lecteur@zogotounga.net:
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
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
Igor Stasenko a écrit :
2008/8/31 Stéphane Rollandin lecteur@zogotounga.net:
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.
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" ncellier@ifrance.com To: squeak-dev@lists.squeakfoundation.org 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 lecteur@zogotounga.net:
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.
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 < aleReimondo@smalltalking.net> 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" <ncellier@ifrance.com
To: squeak-dev@lists.squeakfoundation.org 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 lecteur@zogotounga.net:
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.
{ 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
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
Igor Stasenko a écrit :
2008/8/31 Stéphane Rollandin lecteur@zogotounga.net:
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
squeak-dev@lists.squeakfoundation.org
-
Alejandro F. Reimondo -
David T. Lewis -
Eliot Miranda -
Igor Stasenko -
Karl Ramberg -
Klaus D. Witzel -
nicolas cellier -
Paolo Bonzini -
stephane ducasse -
Stéphane Rollandin