Hi nicolas We would really like to have only one number parser in Pharo as well as handling the 1.0s syntax marcus raised a question that I could not answer. Do you habve nfrmation to share with us so that we can take a decision? Stef so the strange thing is that this is *explicitly* implemented in SqNumberParser to not allow 2.0s - do not allow single s without following digits as ScaledDecimal It is not explained why this is a good idea. In general, we need to merge the whole NumberParser hierarchy into one class, i don't understand why we have three classes now.
I think just because 1.0s was explicitely not supported in Squeak? There should be some related tests... It should be rather simple to change. 2013/8/13 Stéphane Ducasse <stephane.ducasse@inria.fr>
Hi nicolas
We would really like to have only one number parser in Pharo as well as handling the 1.0s syntax marcus raised a question that I could not answer. Do you habve nfrmation to share with us so that we can take a decision?
Stef
so the strange thing is that this is *explicitly* implemented in SqNumberParser to not allow 2.0s
- do not allow single s without following digits as ScaledDecimal
It is not explained why this is a good idea.
In general, we need to merge the whole NumberParser hierarchy into one class, i don't understand why we have three classes now.
thanks! Stef
I think just because 1.0s was explicitely not supported in Squeak? There should be some related tests... It should be rather simple to change.
2013/8/13 Stéphane Ducasse <stephane.ducasse@inria.fr> Hi nicolas
We would really like to have only one number parser in Pharo as well as handling the 1.0s syntax marcus raised a question that I could not answer. Do you habve nfrmation to share with us so that we can take a decision?
Stef
so the strange thing is that this is *explicitly* implemented in SqNumberParser to not allow 2.0s
- do not allow single s without following digits as ScaledDecimal
It is not explained why this is a good idea.
In general, we need to merge the whole NumberParser hierarchy into one class, i don't understand why we have three classes now.
So what we decide to do with this? I can work on that case, but I have 2 questions: - do we care to provide parsing of numbers in other notations as Pharo one? - what is the number syntax that we want to support? Cheers! Uko On 19 Aug 2013, at 10:05, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
thanks!
Stef
I think just because 1.0s was explicitely not supported in Squeak? There should be some related tests... It should be rather simple to change.
2013/8/13 Stéphane Ducasse <stephane.ducasse@inria.fr> Hi nicolas
We would really like to have only one number parser in Pharo as well as handling the 1.0s syntax marcus raised a question that I could not answer. Do you habve nfrmation to share with us so that we can take a decision?
Stef
so the strange thing is that this is *explicitly* implemented in SqNumberParser to not allow 2.0s
- do not allow single s without following digits as ScaledDecimal
It is not explained why this is a good idea.
In general, we need to merge the whole NumberParser hierarchy into one class, i don't understand why we have three classes now.
On 28 Oct 2013, at 10:41, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
So what we decide to do with this?
I can work on that case, but I have 2 questions:
- do we care to provide parsing of numbers in other notations as Pharo one?
Thatâs a good question.. I completely misunderstood the code there because that sounds a bit strange that a language supports other languages syntax, but not âinsideâ the language but somehow as a tool⦠I fear that even if someone needs Fotran number parsing, the last place to look would be the Pharo base kernel classes...
- what is the number syntax that we want to support?
Yes, we we need to document it. Right now it is âsome extended Squeak formatâ which is just defined by the implementation. Marcus
Cheers! Uko
On 19 Aug 2013, at 10:05, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
thanks!
Stef
I think just because 1.0s was explicitely not supported in Squeak? There should be some related tests... It should be rather simple to change.
2013/8/13 Stéphane Ducasse <stephane.ducasse@inria.fr> Hi nicolas
We would really like to have only one number parser in Pharo as well as handling the 1.0s syntax marcus raised a question that I could not answer. Do you habve nfrmation to share with us so that we can take a decision?
Stef
so the strange thing is that this is *explicitly* implemented in SqNumberParser to not allow 2.0s
- do not allow single s without following digits as ScaledDecimal
It is not explained why this is a good idea.
In general, we need to merge the whole NumberParser hierarchy into one class, i don't understand why we have three classes now.
On 28 Oct 2013, at 17:49, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Oct 2013, at 10:41, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
So what we decide to do with this?
I can work on that case, but I have 2 questions:
- do we care to provide parsing of numbers in other notations as Pharo one?
Thatâs a good question.. I completely misunderstood the code there because that sounds a bit strange that a language supports other languages syntax, but not âinsideâ the language but somehow as a toolâ¦
I fear that even if someone needs Fotran number parsing, the last place to look would be the Pharo base kernel classesâ¦
There are 2 extremes here. If you want to parse a fortran number, you probably also want to parse other fortran parts, and so you have some dedicated parser. But if you want to just parse some general number and itâs +2, then you canât easily do that.
- what is the number syntax that we want to support?
Yes, we we need to document it. Right now it is âsome extended Squeak formatâ which is just defined by the implementation.
I can levee the implementation that is used now (a sq one). Or use extended. But it should be really nice to think about what we want to have instead of what we can use. Uko
Marcus
Cheers! Uko
On 19 Aug 2013, at 10:05, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
thanks!
Stef
I think just because 1.0s was explicitely not supported in Squeak? There should be some related tests... It should be rather simple to change.
2013/8/13 Stéphane Ducasse <stephane.ducasse@inria.fr> Hi nicolas
We would really like to have only one number parser in Pharo as well as handling the 1.0s syntax marcus raised a question that I could not answer. Do you habve nfrmation to share with us so that we can take a decision?
Stef
so the strange thing is that this is *explicitly* implemented in SqNumberParser to not allow 2.0s
- do not allow single s without following digits as ScaledDecimal
It is not explained why this is a good idea.
In general, we need to merge the whole NumberParser hierarchy into one class, i don't understand why we have three classes now.
On 28 Oct 2013, at 17:55, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 28 Oct 2013, at 17:49, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Oct 2013, at 10:41, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
So what we decide to do with this?
I can work on that case, but I have 2 questions:
- do we care to provide parsing of numbers in other notations as Pharo one?
Thatâs a good question.. I completely misunderstood the code there because that sounds a bit strange that a language supports other languages syntax, but not âinsideâ the language but somehow as a toolâ¦
I fear that even if someone needs Fotran number parsing, the last place to look would be the Pharo base kernel classesâ¦
There are 2 extremes here. If you want to parse a fortran number, you probably also want to parse other fortran parts, and so you have some dedicated parser. But if you want to just parse some general number and itâs +2, then you canât easily do that.
- what is the number syntax that we want to support?
Yes, we we need to document it. Right now it is âsome extended Squeak formatâ which is just defined by the implementation.
I can levee the implementation that is used now (a sq one). Or use extended. But it should be really nice to think about what we want to have instead of what we can use.
If we have to decide, we should take the simple path. The fact that I am completely confused about this is not a good sign (maybe more related to my intelligence⦠:-) Marcus
Concerning FORTRAN, I think it was removed for a long time, it was just an example of how the NumberParser could be used. Concerning the ExtendedNumberParser, I find it useful to have it, because it can parse inputs like: +1.4 -1.2e+3 .005 127.e6 A lot of languages/applications around the world would accept these as valid Number. Smalltalk syntax is much stricter... OK, it's just a DSL, and it could as well be implemented by other means... Whether such DSL implementation belongs to NumberParser hierarchy or not, is a choice that was guided by 2 things - NumberParser provides an implementation that will correctly round the number to nearest Float (or ScaledDecimal eventually) I've seen too many Smalltalk implementations departing from universal standards with this respect (IOW, wrong) - NumerParser tries to be efficient (as far as Smalltalk can be), especially in the cases with many digits The first point is mandatory. The second is just an optimization. Now that you have more insight about rationale which guided those decisions, it's up to you :) Cheers Nicolas 2013/10/28 Marcus Denker <marcus.denker@inria.fr>
On 28 Oct 2013, at 17:55, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 28 Oct 2013, at 17:49, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Oct 2013, at 10:41, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
So what we decide to do with this?
I can work on that case, but I have 2 questions:
- do we care to provide parsing of numbers in other notations as Pharo one?
Thatâs a good question.. I completely misunderstood the code there because that sounds a bit strange that a language supports other languages syntax, but not âinsideâ the language but somehow as a toolâ¦
I fear that even if someone needs Fotran number parsing, the last place to look would be the Pharo base kernel classesâ¦
There are 2 extremes here. If you want to parse a fortran number, you probably also want to parse other fortran parts, and so you have some dedicated parser. But if you want to just parse some general number and itâs +2, then you canât easily do that.
- what is the number syntax that we want to support?
Yes, we we need to document it. Right now it is âsome extended Squeak formatâ which is just defined by the implementation.
I can levee the implementation that is used now (a sq one). Or use extended. But it should be really nice to think about what we want to have instead of what we can use.
If we have to decide, we should take the simple path. The fact that I am completely confused about this is not a good sign (maybe more related to my intelligence⦠:-)
Marcus
I just used the parsing of a number like this: -1.2e+3 just a scant 15 minutes ago, so I appreciate the support. -cbc On Mon, Oct 28, 2013 at 11:46 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Concerning FORTRAN, I think it was removed for a long time, it was just an example of how the NumberParser could be used. Concerning the ExtendedNumberParser, I find it useful to have it, because it can parse inputs like: +1.4 -1.2e+3 .005 127.e6 A lot of languages/applications around the world would accept these as valid Number. Smalltalk syntax is much stricter...
OK, it's just a DSL, and it could as well be implemented by other means... Whether such DSL implementation belongs to NumberParser hierarchy or not, is a choice that was guided by 2 things - NumberParser provides an implementation that will correctly round the number to nearest Float (or ScaledDecimal eventually) I've seen too many Smalltalk implementations departing from universal standards with this respect (IOW, wrong) - NumerParser tries to be efficient (as far as Smalltalk can be), especially in the cases with many digits The first point is mandatory. The second is just an optimization.
Now that you have more insight about rationale which guided those decisions, it's up to you :)
Cheers
Nicolas
2013/10/28 Marcus Denker <marcus.denker@inria.fr>
On 28 Oct 2013, at 17:55, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 28 Oct 2013, at 17:49, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Oct 2013, at 10:41, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
So what we decide to do with this?
I can work on that case, but I have 2 questions:
- do we care to provide parsing of numbers in other notations as Pharo one?
Thatâs a good question.. I completely misunderstood the code there because that sounds a bit strange that a language supports other languages syntax, but not âinsideâ the language but somehow as a toolâ¦
I fear that even if someone needs Fotran number parsing, the last place to look would be the Pharo base kernel classesâ¦
There are 2 extremes here. If you want to parse a fortran number, you probably also want to parse other fortran parts, and so you have some dedicated parser. But if you want to just parse some general number and itâs +2, then you canât easily do that.
- what is the number syntax that we want to support?
Yes, we we need to document it. Right now it is âsome extended Squeak formatâ which is just defined by the implementation.
I can levee the implementation that is used now (a sq one). Or use extended. But it should be really nice to think about what we want to have instead of what we can use.
If we have to decide, we should take the simple path. The fact that I am completely confused about this is not a good sign (maybe more related to my intelligence⦠:-)
Marcus
On 28 Oct 2013, at 17:59, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Oct 2013, at 17:55, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 28 Oct 2013, at 17:49, Marcus Denker <marcus.denker@inria.fr> wrote:
On 28 Oct 2013, at 10:41, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
So what we decide to do with this?
I can work on that case, but I have 2 questions:
- do we care to provide parsing of numbers in other notations as Pharo one?
Thatâs a good question.. I completely misunderstood the code there because that sounds a bit strange that a language supports other languages syntax, but not âinsideâ the language but somehow as a toolâ¦
I fear that even if someone needs Fotran number parsing, the last place to look would be the Pharo base kernel classesâ¦
There are 2 extremes here. If you want to parse a fortran number, you probably also want to parse other fortran parts, and so you have some dedicated parser. But if you want to just parse some general number and itâs +2, then you canât easily do that.
- what is the number syntax that we want to support?
Yes, we we need to document it. Right now it is âsome extended Squeak formatâ which is just defined by the implementation.
I can levee the implementation that is used now (a sq one). Or use extended. But it should be really nice to think about what we want to have instead of what we can use.
If we have to decide, we should take the simple path. The fact that I am completely confused about this is not a good sign (maybe more related to my intelligence⦠:-)
I think that Iâll follow newt plan: - leave only the one clues that is currently used - write down the syntax that is provided - then one can think about what is odd and what is missing - improve parser if needed Uko
Marcus
participants (5)
-
Chris Cunningham -
Marcus Denker -
Nicolas Cellier -
Stéphane Ducasse -
Yuriy Tymchuk