Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?
On Fri, Feb 6, 2015 at 7:45 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: We have merged the parsers into one, because we had 3 parsers that didn’t have any dedicated use-cases, juts were developed historical as at some point someone needed a bit more functionality, and then different parsers were used randomly on the system. As for the expression - yes we have to decide about it. If it’s only about being able to use exponent in float literals, one can use: “Number readFrom: '2.58500098e04’”. If it’s about being similar to the other languages, we can also decide does it make sense to have a +2 literal. Yes, I would allow that by default. This will ease serialization between Pharo and GemStone for example (which uses +). So. what I would do is to simply change to NumberParser allowPlusSignInExponent ^ true I opened: https://pharo.fogbugz.com/f/cases/14896/By-default-float-parsing-does-not-allow-plus-symbol-in-exponential Cheers, Uko On 06 Feb 2015, at 09:04, Marcus Denker marcus.den...@inria.fr wrote: On 06 Feb 2015, at 09:02, stepharo steph...@free.fr wrote: Le 5/2/15 10:40, Sven Van Caekenberghe a écrit : On 05 Feb 2015, at 10:36, Ben Coman b...@openinworld.com wrote: I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben Of course exponents are still supported ;-) The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose. I do not know I think that marcus removed it to avoid to have two parsers in the image. Maybe this was a mistake… Marcus -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?
Le 5/2/15 10:40, Sven Van Caekenberghe a écrit : On 05 Feb 2015, at 10:36, Ben Coman b...@openinworld.com wrote: I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben Of course exponents are still supported ;-) The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose. I do not know I think that marcus removed it to avoid to have two parsers in the image. On Thu, Feb 5, 2015 at 12:27 AM, Mariano Martinez Peck marianop...@gmail.com wrote: Hi guys, In Pharo 2.0, the expression Number readFrom: '2.58500098e+04' would answer 25850.01 , but in Pharo 3.0 it answers: 2.58500097 which is a kind of WTF to me. Checking the differences it seems in Pharo 2.0 ExtendedNumberParser (used from Number readFrom: ) implemented: allowPlusSign ^true However, in Pharo 3.0 it seems subclasses of NumberParser have been merged directly in NumberParser class (and so Number readFrom: uses this class now). But.. (and this is the difference), NumberParser implements: allowPlusSign ^false So I wonder...was this on purpose or a side effect? Why would we want to reject using + as part of the exponential notion?? So in my case now I must do an override to: NumberParser allowPlusSignInExponent ^ true Thoughts? -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?
On 06 Feb 2015, at 09:02, stepharo steph...@free.fr wrote: Le 5/2/15 10:40, Sven Van Caekenberghe a écrit : On 05 Feb 2015, at 10:36, Ben Coman b...@openinworld.com wrote: I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben Of course exponents are still supported ;-) The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose. I do not know I think that marcus removed it to avoid to have two parsers in the image. Maybe this was a mistake… Marcus
Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?
2015-02-06 16:18 GMT+01:00 Marcus Denker marcus.den...@inria.fr: On 06 Feb 2015, at 11:45, Yuriy Tymchuk yuriy.tymc...@me.com wrote: We have merged the parsers into one, because we had 3 parsers that didn’t have any dedicated use-cases, juts were developed historical as at some point someone needed a bit more functionality, and then different parsers were used randomly on the system. Yes, it was quite hard to understand what was going on. And it is strange to have 3 different parsers for numbers... No it's not strange. 2 different parsers respond to 2 different syntax and expectations. To me it's quite clear: - The SmalltalkNumberParser was there to parse a Smalltalk syntax (badly named SqNumberParser in the ages...) It should do this thru Number readSmalltalkSyntaxFrom: '1.0e4' - The ExtendedNumberParser was there to parse an extended syntax (the one most apps handling data from oustide world will wish to parse). It should do this thru Number readFrom: '1.0e+4' - The FortranNumberParser was just an unused experiment. Its sole goal was to expose an example of how a GenericNumberParser could be subclassed. Such class has a better place in a cook-book than in the image, so Bye bye. Date readFrom: '2015/02/06' readStream does not have to follow a Smalltalk syntax, so why Number readFrom: '1.0e+4' readStream would have to? As Yuriy underlined, we might extend the Smalltalk syntax to embrasse some of external world patterns, why not, but it's limited and is going to be a problem with formats like '.2' or '2.e0'. Whether the extended parser should be in the core image or not is a valid question. We all agree that Pharo is all but finished and need to be constantly cleaned up. The challenge is how can Pharo change but remain application-writer-friendly? So two different things are: - the value of the feature: is it worth maintaining it or not? If yes, should it be maintained outside the core, or inside by the Pharo-team? I agree that removing incomplete features is a valid strategy when the team is too small - the quality of implementation And there are two ways of cleaning: - clean a dirty implementation, but keep the feature (eventually with a different API) - remove the feature, based on a value/cost analysis Here, I feel like it's the dictatorship which sounds questionnable. Were the feature understood? There were unit tests and class comments, so pretending to not understand is not really an excuse. Were the value of the features discussed? Maybe in a small core team... From outside, we don't really know. Were an externalisation of the feature and transfer of maintenance to a 3rd party discussed? I'm not aware of. I'm sure it would have been a better decision. So from my POV, such decision process remains to improve. It sounds too light and arbitrary. In some cases, I have the impression that the volunty of cleaning is too much dogmatic. I agree that too much pragmatism won't lead to a clean image any time soon... I agree that Pharo team has a licence to change things and should decide, otherwise let's all stick to Squeak ;) But a bit of democratie, argumentation and COORDINATION does not hurt. Then how can user support be improved? - Is it possible to write release notes helping the transition? (were is located the add-on package that enables compatibility, who maintains it, is there a new and better API, etc...) - Could some automated AST-based refactorings be prepared and applied auto-magically? It's not necessarily the sole business of Pharo-team, user community could help writing such notes. Nicolas As for the expression - yes we have to decide about it. If it’s only about being able to use exponent in float literals, one can use: “Number readFrom: '2.58500098e04’”. If it’s about being similar to the other languages, we can also decide does it make sense to have a +2 literal. If it makes no problems with backward compatibility, why not have both? Uko On 06 Feb 2015, at 09:04, Marcus Denker marcus.den...@inria.fr wrote: On 06 Feb 2015, at 09:02, stepharo steph...@free.fr wrote: Le 5/2/15 10:40, Sven Van Caekenberghe a écrit : On 05 Feb 2015, at 10:36, Ben Coman b...@openinworld.com wrote: I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben Of course exponents are still supported ;-) The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose. I do not know I think that marcus removed it to avoid to have two parsers in the image. Maybe this was a mistake… Marcus
Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?
We have merged the parsers into one, because we had 3 parsers that didn’t have any dedicated use-cases, juts were developed historical as at some point someone needed a bit more functionality, and then different parsers were used randomly on the system. As for the expression - yes we have to decide about it. If it’s only about being able to use exponent in float literals, one can use: “Number readFrom: '2.58500098e04’”. If it’s about being similar to the other languages, we can also decide does it make sense to have a +2 literal. Uko On 06 Feb 2015, at 09:04, Marcus Denker marcus.den...@inria.fr wrote: On 06 Feb 2015, at 09:02, stepharo steph...@free.fr wrote: Le 5/2/15 10:40, Sven Van Caekenberghe a écrit : On 05 Feb 2015, at 10:36, Ben Coman b...@openinworld.com wrote: I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben Of course exponents are still supported ;-) The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose. I do not know I think that marcus removed it to avoid to have two parsers in the image. Maybe this was a mistake… Marcus
Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?
I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben On Thu, Feb 5, 2015 at 12:27 AM, Mariano Martinez Peck marianop...@gmail.com wrote: Hi guys, In Pharo 2.0, the expression Number readFrom: '2.58500098e+04' would answer 25850.01 , but in Pharo 3.0 it answers: 2.58500097 which is a kind of WTF to me. Checking the differences it seems in Pharo 2.0 ExtendedNumberParser (used from Number readFrom: ) implemented: allowPlusSign ^true However, in Pharo 3.0 it seems subclasses of NumberParser have been merged directly in NumberParser class (and so Number readFrom: uses this class now). But.. (and this is the difference), NumberParser implements: allowPlusSign ^false So I wonder...was this on purpose or a side effect? Why would we want to reject using + as part of the exponential notion?? So in my case now I must do an override to: NumberParser allowPlusSignInExponent ^ true Thoughts? -- Mariano http://marianopeck.wordpress.com
Re: [Pharo-dev] Parsing float difference between 2.0 and 3.0, was it on purpose?
On 05 Feb 2015, at 10:36, Ben Coman b...@openinworld.com wrote: I personally would prefer to be able to use exponents. No sure what the big picture is. cheers -ben Of course exponents are still supported ;-) The discussion is about the + sign for positive exponents. I am not sure, but I think that traditional Smalltalk did not support this, but it was added to support common practice in other languages. Now it is apparently gone again, probably not on purpose. On Thu, Feb 5, 2015 at 12:27 AM, Mariano Martinez Peck marianop...@gmail.com wrote: Hi guys, In Pharo 2.0, the expression Number readFrom: '2.58500098e+04' would answer 25850.01 , but in Pharo 3.0 it answers: 2.58500097 which is a kind of WTF to me. Checking the differences it seems in Pharo 2.0 ExtendedNumberParser (used from Number readFrom: ) implemented: allowPlusSign ^true However, in Pharo 3.0 it seems subclasses of NumberParser have been merged directly in NumberParser class (and so Number readFrom: uses this class now). But.. (and this is the difference), NumberParser implements: allowPlusSign ^false So I wonder...was this on purpose or a side effect? Why would we want to reject using + as part of the exponential notion?? So in my case now I must do an override to: NumberParser allowPlusSignInExponent ^ true Thoughts? -- Mariano http://marianopeck.wordpress.com
