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 _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell