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