Am 27.01.2012 11:30, schrieb Berend Hasselman:
On 27-01-2012, at 00:34, Allin Cottrell wrote:
> This leads to two questions:
> For those who favor accommodation of the decimal comma on GUI
> input: would you regard this as acceptable -- where "this" means
> that use of the decimal comma would work with simple uses of "genr"
> but would predictably fail on complex uses, and that sort of
> failure would not be considered a bug?
From the point of view of the pro-locale users, would such a
inconsistent gretl behavior really help them? I tend to think no,
because they would have to learn *more* (exceptions).
[Also I note, a pair of parentheses not only means a function call, but
can also simply indicate precedence; is 'genr hello=(2,5+my)*4,5'
already a complex statement? If I understand correctly, it would fail
even under the proposed rules. -- Allin: Yes, this is what I meant by bug.]
> For the rest of us: are we willing to tolerate the syntactical
> sloppiness implied by the above -- given that it won't actually
> compromise our own interaction with gretl so long as we use the
> decimal point?
Yes I could accept it, but I have my doubts that it really won't interfere.
More generally once more: Gretl (Allin) implicitly made the design
decision long ago, by choosing the comma as a different separator (for
arguments etc.). It doesn't make sense to overload the comma character's
meaning. If the comma were to be allowed as decimal mark, in principle
gretl would need a new argument separator, e.g. the semicolon.
As far as I am concerned, the only place where I would be prepared
accept a locale dependent decimal point character in GUI input is
where a user can input pure numbers only. Nowhere else.
In principle I can agree here, but as argued above, does this really
help the affected users? Are "pure numbers" inputs the common need of
gretl users, also given that gretl has deliberately outsourced most data
editing to specialized (text editor and spreadsheet) programs?