Hi,
While playing around, I've found that Number readFrom: '1.' returns 1.0 ... I'd expected a 1. Is this expected behaviour? frank |
Yes, in Squeak this behavior is obtained with the ExtendedNumberParser.
You can read these floats for example: 1. 1.e+30 .1 -.1e+30 Though, in Smalltalk source code, the SqNumberParser is used and you can't. Nicolas 2011/8/12 Frank Shearar <[hidden email]>: > Hi, > > While playing around, I've found that Number readFrom: '1.' returns > 1.0 ... I'd expected a 1. > > Is this expected behaviour? > > frank > > |
This was changed in:
The Trunk: Compiler-nice.125.mcz The Trunk: Kernel-nice.404.mcz The rationale is that (Number readFrom: ) is a very poor way to report a syntax error in the number. SqNumberParser can do much better when invoked with ad hoc API. This release the necessity for Number>>readFrom: to strictly adhere to Smalltalk syntax (which it did not since it also interprets infinity and nan). Nicolas 2011/8/12 Nicolas Cellier <[hidden email]>: > Yes, in Squeak this behavior is obtained with the ExtendedNumberParser. > You can read these floats for example: > > 1. > 1.e+30 > .1 > -.1e+30 > > Though, in Smalltalk source code, the SqNumberParser is used and you can't. > > Nicolas > > 2011/8/12 Frank Shearar <[hidden email]>: >> Hi, >> >> While playing around, I've found that Number readFrom: '1.' returns >> 1.0 ... I'd expected a 1. >> >> Is this expected behaviour? >> >> frank >> >> > |
For the sake of it, I would say things are not worse than before I put
my big nose in the code: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/103137.html Nicolas 2011/8/12 Nicolas Cellier <[hidden email]>: > This was changed in: > > The Trunk: Compiler-nice.125.mcz > The Trunk: Kernel-nice.404.mcz > > The rationale is that (Number readFrom: ) is a very poor way to report > a syntax error in the number. > SqNumberParser can do much better when invoked with ad hoc API. > > This release the necessity for Number>>readFrom: to strictly adhere to > Smalltalk syntax (which it did not since it also interprets infinity > and nan). > > Nicolas > > 2011/8/12 Nicolas Cellier <[hidden email]>: >> Yes, in Squeak this behavior is obtained with the ExtendedNumberParser. >> You can read these floats for example: >> >> 1. >> 1.e+30 >> .1 >> -.1e+30 >> >> Though, in Smalltalk source code, the SqNumberParser is used and you can't. >> >> Nicolas >> >> 2011/8/12 Frank Shearar <[hidden email]>: >>> Hi, >>> >>> While playing around, I've found that Number readFrom: '1.' returns >>> 1.0 ... I'd expected a 1. >>> >>> Is this expected behaviour? >>> >>> frank >>> >>> >> > |
I went and looked (rather belatedly, in hindsight) at the tests, and
indeed we explicitly support (as in there are tests documenting the behaviour) the parsing of '1.' as a string representation of 1.0. My immediate issue is that this makes my work on Coral more complicated, because in Pharo Number readFrom: '1.' returns 1 and leaves '.' on the stream (just like it would for Number readFrom: '1x'). But it also means we have an ambiguity in our grammar: there's no way to know whether in '1.' the dot belongs to the number literal, or whether it terminates the statement. frank On 12 August 2011 09:26, Nicolas Cellier <[hidden email]> wrote: > For the sake of it, I would say things are not worse than before I put > my big nose in the code: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/103137.html > > Nicolas > > 2011/8/12 Nicolas Cellier <[hidden email]>: >> This was changed in: >> >> The Trunk: Compiler-nice.125.mcz >> The Trunk: Kernel-nice.404.mcz >> >> The rationale is that (Number readFrom: ) is a very poor way to report >> a syntax error in the number. >> SqNumberParser can do much better when invoked with ad hoc API. >> >> This release the necessity for Number>>readFrom: to strictly adhere to >> Smalltalk syntax (which it did not since it also interprets infinity >> and nan). >> >> Nicolas >> >> 2011/8/12 Nicolas Cellier <[hidden email]>: >>> Yes, in Squeak this behavior is obtained with the ExtendedNumberParser. >>> You can read these floats for example: >>> >>> 1. >>> 1.e+30 >>> .1 >>> -.1e+30 >>> >>> Though, in Smalltalk source code, the SqNumberParser is used and you can't. >>> >>> Nicolas >>> >>> 2011/8/12 Frank Shearar <[hidden email]>: >>>> Hi, >>>> >>>> While playing around, I've found that Number readFrom: '1.' returns >>>> 1.0 ... I'd expected a 1. >>>> >>>> Is this expected behaviour? >>>> >>>> frank >>>> >>>> >>> >> > > |
2011/8/12 Frank Shearar <[hidden email]>:
> I went and looked (rather belatedly, in hindsight) at the tests, and > indeed we explicitly support (as in there are tests documenting the > behaviour) the parsing of '1.' as a string representation of 1.0. > > My immediate issue is that this makes my work on Coral more > complicated, because in Pharo Number readFrom: '1.' returns 1 and > leaves '.' on the stream (just like it would for Number readFrom: > '1x'). > > But it also means we have an ambiguity in our grammar: there's no way > to know whether in '1.' the dot belongs to the number literal, or > whether it terminates the statement. > > frank > Well, no, because we do not use Number class>>readFrom: in the Parser. Nicolas > On 12 August 2011 09:26, Nicolas Cellier > <[hidden email]> wrote: >> For the sake of it, I would say things are not worse than before I put >> my big nose in the code: >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/103137.html >> >> Nicolas >> >> 2011/8/12 Nicolas Cellier <[hidden email]>: >>> This was changed in: >>> >>> The Trunk: Compiler-nice.125.mcz >>> The Trunk: Kernel-nice.404.mcz >>> >>> The rationale is that (Number readFrom: ) is a very poor way to report >>> a syntax error in the number. >>> SqNumberParser can do much better when invoked with ad hoc API. >>> >>> This release the necessity for Number>>readFrom: to strictly adhere to >>> Smalltalk syntax (which it did not since it also interprets infinity >>> and nan). >>> >>> Nicolas >>> >>> 2011/8/12 Nicolas Cellier <[hidden email]>: >>>> Yes, in Squeak this behavior is obtained with the ExtendedNumberParser. >>>> You can read these floats for example: >>>> >>>> 1. >>>> 1.e+30 >>>> .1 >>>> -.1e+30 >>>> >>>> Though, in Smalltalk source code, the SqNumberParser is used and you can't. >>>> >>>> Nicolas >>>> >>>> 2011/8/12 Frank Shearar <[hidden email]>: >>>>> Hi, >>>>> >>>>> While playing around, I've found that Number readFrom: '1.' returns >>>>> 1.0 ... I'd expected a 1. >>>>> >>>>> Is this expected behaviour? >>>>> >>>>> frank >>>>> >>>>> >>>> >>> >> >> > > |
On 12 August 2011 14:35, Nicolas Cellier
<[hidden email]> wrote: > 2011/8/12 Frank Shearar <[hidden email]>: >> I went and looked (rather belatedly, in hindsight) at the tests, and >> indeed we explicitly support (as in there are tests documenting the >> behaviour) the parsing of '1.' as a string representation of 1.0. >> >> My immediate issue is that this makes my work on Coral more >> complicated, because in Pharo Number readFrom: '1.' returns 1 and >> leaves '.' on the stream (just like it would for Number readFrom: >> '1x'). >> >> But it also means we have an ambiguity in our grammar: there's no way >> to know whether in '1.' the dot belongs to the number literal, or >> whether it terminates the statement. >> >> frank >> > > Well, no, because we do not use Number class>>readFrom: in the Parser. Fair enough: a := 1.. a "=> 1, so '..' means 'end statement, end (empty) statement'." But that means that we have a number parser that permits a grammar that doesn't match the host language's grammar, right? To be precise, SqNumberParser says "SqNumberParser is a NumberParser specialized in reading Number with Squeak syntax." but actually accepts something slightly different from Squeak syntax. Again: if there's good reason for this, that's fine - that would just mean I've been surprised. It just seems... odd. For my personal needs, the right thing's probably to extend PetitSmalltalk to parse numbers, instead of "calling out" to Number class >> readFrom: to parse the numbers. > Nicolas > >> On 12 August 2011 09:26, Nicolas Cellier >> <[hidden email]> wrote: >>> For the sake of it, I would say things are not worse than before I put >>> my big nose in the code: >>> >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/103137.html >>> >>> Nicolas >>> >>> 2011/8/12 Nicolas Cellier <[hidden email]>: >>>> This was changed in: >>>> >>>> The Trunk: Compiler-nice.125.mcz >>>> The Trunk: Kernel-nice.404.mcz >>>> >>>> The rationale is that (Number readFrom: ) is a very poor way to report >>>> a syntax error in the number. >>>> SqNumberParser can do much better when invoked with ad hoc API. >>>> >>>> This release the necessity for Number>>readFrom: to strictly adhere to >>>> Smalltalk syntax (which it did not since it also interprets infinity >>>> and nan). >>>> >>>> Nicolas >>>> >>>> 2011/8/12 Nicolas Cellier <[hidden email]>: >>>>> Yes, in Squeak this behavior is obtained with the ExtendedNumberParser. >>>>> You can read these floats for example: >>>>> >>>>> 1. >>>>> 1.e+30 >>>>> .1 >>>>> -.1e+30 >>>>> >>>>> Though, in Smalltalk source code, the SqNumberParser is used and you can't. >>>>> >>>>> Nicolas >>>>> >>>>> 2011/8/12 Frank Shearar <[hidden email]>: >>>>>> Hi, >>>>>> >>>>>> While playing around, I've found that Number readFrom: '1.' returns >>>>>> 1.0 ... I'd expected a 1. >>>>>> >>>>>> Is this expected behaviour? >>>>>> >>>>>> frank >>>>>> >>>>>> >>>>> >>>> >>> >>> >> >> > > |
2011/8/12 Frank Shearar <[hidden email]>:
> On 12 August 2011 14:35, Nicolas Cellier > <[hidden email]> wrote: >> 2011/8/12 Frank Shearar <[hidden email]>: >>> I went and looked (rather belatedly, in hindsight) at the tests, and >>> indeed we explicitly support (as in there are tests documenting the >>> behaviour) the parsing of '1.' as a string representation of 1.0. >>> >>> My immediate issue is that this makes my work on Coral more >>> complicated, because in Pharo Number readFrom: '1.' returns 1 and >>> leaves '.' on the stream (just like it would for Number readFrom: >>> '1x'). >>> >>> But it also means we have an ambiguity in our grammar: there's no way >>> to know whether in '1.' the dot belongs to the number literal, or >>> whether it terminates the statement. >>> >>> frank >>> >> >> Well, no, because we do not use Number class>>readFrom: in the Parser. > > Fair enough: > > a := 1.. > a "=> 1, so '..' means 'end statement, end (empty) statement'." > > > But that means that we have a number parser that permits a grammar > that doesn't match the host language's grammar, right? To be precise, > SqNumberParser says "SqNumberParser is a NumberParser specialized in > reading Number with Squeak syntax." but actually accepts something > slightly different from Squeak syntax. > Not exactly, apart NaN/Infinity, SqNumberParser adheres to SqueakSyntax, but it is another class ExtendedNumberParser which is used in Number readFrom:. > Again: if there's good reason for this, that's fine - that would just > mean I've been surprised. It just seems... odd. > I would see this in the perspective of Date readFrom:, which accepts some formats which are not literal Smalltalk expressions, but rather DSL. > For my personal needs, the right thing's probably to extend > PetitSmalltalk to parse numbers, instead of "calling out" to Number > class >> readFrom: to parse the numbers. > Sure, this sounds wiser, but you'll have a Squeak/Pharo specific flavour. I understand that Lukas was using Number readFrom: to handle differences between Smalltalk dialects: - VW 1.0e 1.0d 1.0s - Dolphin 1.0e+0 - Squeak 2r1.01e-3 (broken in Squeak 4.1 or 4.2 for base > 14 since we now accept lower case digits, and we can't distinguish e the digit and e the exponent) Anyway, there are other differences, like number of characters and allowed characters in binary selectors, #[], {}, ##() , #{}, international characters in messages/variable names, etc... so having a dialect specific parser does not hurt... Nicolas >> Nicolas >> >>> On 12 August 2011 09:26, Nicolas Cellier >>> <[hidden email]> wrote: >>>> For the sake of it, I would say things are not worse than before I put >>>> my big nose in the code: >>>> >>>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/103137.html >>>> >>>> Nicolas >>>> >>>> 2011/8/12 Nicolas Cellier <[hidden email]>: >>>>> This was changed in: >>>>> >>>>> The Trunk: Compiler-nice.125.mcz >>>>> The Trunk: Kernel-nice.404.mcz >>>>> >>>>> The rationale is that (Number readFrom: ) is a very poor way to report >>>>> a syntax error in the number. >>>>> SqNumberParser can do much better when invoked with ad hoc API. >>>>> >>>>> This release the necessity for Number>>readFrom: to strictly adhere to >>>>> Smalltalk syntax (which it did not since it also interprets infinity >>>>> and nan). >>>>> >>>>> Nicolas >>>>> >>>>> 2011/8/12 Nicolas Cellier <[hidden email]>: >>>>>> Yes, in Squeak this behavior is obtained with the ExtendedNumberParser. >>>>>> You can read these floats for example: >>>>>> >>>>>> 1. >>>>>> 1.e+30 >>>>>> .1 >>>>>> -.1e+30 >>>>>> >>>>>> Though, in Smalltalk source code, the SqNumberParser is used and you can't. >>>>>> >>>>>> Nicolas >>>>>> >>>>>> 2011/8/12 Frank Shearar <[hidden email]>: >>>>>>> Hi, >>>>>>> >>>>>>> While playing around, I've found that Number readFrom: '1.' returns >>>>>>> 1.0 ... I'd expected a 1. >>>>>>> >>>>>>> Is this expected behaviour? >>>>>>> >>>>>>> frank >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >> > > |
Free forum by Nabble | Edit this page |