[Pharo-dev] About SqNumberParser

Chris Cunningham cunningham.cb at gmail.com
Mon Oct 28 17:17:15 EDT 2013


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 at 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 at inria.fr>
>
>>
>> On 28 Oct 2013, at 17:55, Yuriy Tymchuk <yuriy.tymchuk at me.com> wrote:
>>
>>
>> On 28 Oct 2013, at 17:49, Marcus Denker <marcus.denker at inria.fr> wrote:
>>
>>
>> On 28 Oct 2013, at 10:41, Yuriy Tymchuk <yuriy.tymchuk at 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131028/2d3cc34d/attachment-0002.html>


More information about the Pharo-dev mailing list