Re: [Gretl-devel] some bugs and issues

Hello, I agree mostly with Jack. After all, hansl is also a _language_ and as such has its syntax rules, wherever they came from. However, Talha's GUI-argument does have some validity IMHO, given that gretl tries to be localized (a unique and noteworthy endeavour in the realm of statistics software as I said before). I'm feeling uneasy about the fact that now in some places in the localized GUI you can enter "2,5", whereas in other cases you cannot do that (as discussed in this thread). This causes potential confusion or frustration. So let me have another go at a suggestion for the GUI inputs (including function calls, not just pure numbers). The proposal goes as follows: * Starting point (sic! -- and which I said before): allowing double meanings for commas in a single expression is out of the question IMHO. So that means that somebody who uses commas as decimal separators *must* use something else as function argument separator. I suggest(ed) the semicolon. * Needless to say (?), all this does not apply to hansl scripts. * First solution: Gretl already has a preference option for choosing the localized decimal separator. (Personally I prefer to work with the '.' for example.) If that preference is set to localized, it seems logical to actually _require_ the input in GUI windows in this localized form. For example under the German (de_DE) locale: "2,5*corr(ser1;ser2)" Note the semicolon (see above)! * Extended solution "1b": Gretl could try to be clever and apply a conversion according to the following algorithm, which tries to maintain the current behavior where hansl-style input is always allowed: - Are both a semicolon and a dot present? raise an error - Is a semicolon present? Then treat it as localized and internally convert the local decimal separator to dot, and semicolon to comma. - Is a dot present (irrespective of the presence of a comma)? Then assume hansl (C-style) rules and do not convert. - Is only a comma present (and no dot or semicolon)? If the comma is not inside parentheses, must be a decimal separator, treat everything as localized. If the comma is inside parentheses, it gets more difficult and nasty... But again, given the existing GUI preference option for choosing the style of the decimal separator, I think there is a strong case for requiring this chosen style in the GUI, which resolves all ambiguities. (At the cost of introducing a new character for function argument separation in the GUI, which would have to be suitably documented.) thanks, sven