On 28 Oct 2013, at 17:59, Marcus Denker <[email protected]> wrote:
> > On 28 Oct 2013, at 17:55, Yuriy Tymchuk <[email protected]> wrote: > >> >> On 28 Oct 2013, at 17:49, Marcus Denker <[email protected]> wrote: >> >>> >>> On 28 Oct 2013, at 10:41, Yuriy Tymchuk <[email protected]> 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
