User-Defined Operators

[Wolfgang Jeltsch]

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