2015-02-06 16:18 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:

> On 06 Feb 2015, at 11:45, Yuriy Tymchuk <yuriy.tymchuk@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.5850009999999998e04������. 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.denker@inria.fr> wrote:
>>
>>
>>> On 06 Feb 2015, at 09:02, stepharo <stepharo@free.fr> wrote:
>>>
>>>
>>> Le 5/2/15 10:40, Sven Van Caekenberghe a ��crit :
>>>>> On 05 Feb 2015, at 10:36, Ben Coman <btc@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
>
>