On Thursday, 2003-07-17, 09:08, CEST, Johannes Waldmann wrote:
[...]
in my code, I don't define any operators at all (only functions). I do think that self-defined operators make a programm less readable. All you get is a A short cryptic sequence of non-alphanumeric characters.
I think, that in some situations using operators makes a program more readable. For instance, if we wouldn't have special list syntax, we could still write something like 1 : 2 : 3 : 4 : []. Without operators we would get 1 `cons` 2 `cons` 3 `cons` 4 `cons` [] (uhh, much harder to type) or even cons 1 $ cons 2 $ cons 3 $ cons 4 $ [] or cons 1 (cons 2 (cons 3 (cons 4 []))) which doesn't look much like [1,2,3,4]. I think that similar situations exist with user-defined functions/operators.
No-one would want to export functions named f, g, f1, fg, f' etc., so why should this be any better with operators?
Ok, that's a point I never thought of.
A similar discussion sometimes surfaces in mathematics - where they have "user-defined" operators all over the place, and especially so since LaTeX.
Well, for the most part, LaTeX only provides common operators. One problem, I came across some weeks ago, is that it is *not* possible to define his/her own operators (or, at least, that Lamport's "LaTeX - A Document Preparation System" doesn't tell you how you can define them).
But it's not enough if you can write down something, you also have to talk about it - so a standard test is to imagine you have to read out a formula (in mathematics) or a program text (in Haskell) to someone over the phone.
Yes, this is a problem. But it can be solved by assigning a "pronounciation" to an operator like it's done in standard mathematics.
And what's absolutely horrible (IMHO) is to allow the user to declare arbitrary precedence and associativity for his creations. This requires that the source text of the defining module be there, only to parse (i. e., build the syntax tree of) a program that uses it.
Maybe the infix declarations should have to be separated from the rest of the code?
And - the corresponding definitions in the standard seem rather ad-hoc: we have a funny expression grammar http://haskell.org/onlinereport/exps.html, with arbitrary restrictions (why just ten precendence levels?)
Yes, something more sophisticated would be nice.
I could live with Haskell's predefined operators (arithmetics, comparisons, bool-ops, (:), (++), (!), (!!), (.), ($)). I often use them, and I sometimes overload them (arithmetics, comparisons), but nothing more. (This is the design of Ada - there are operators, you can overload them, but you cannot change their precedence, or add new ones - so you can always parse a program text.)
I dislike, having a fixed set of operators with each having a fixed precedence. I would say: "Either no operators at all or a facility for defining operators which is complex enough to allow the definition of the standard operators." One thing of Haskell, I really like, is that only very few things are hard-wired into the compiler/interpreter.
Anyway, this was just for the record (I'm a happy Haskell user, I just ignore some of its features :-), so back to real work now.
Wolfgang