Johannes Waldmann wrote:
to only ASCII characters. For example, I would not write 'sqrt 2' but I would write a square root symbol with 2 underneath. Likewise, I would not write '2 ^ 5', but I would write a 2 with a 5 raised upwards to the right of the 2. ...
Remember Paul Halmos' advice (from "I Want To Be A Mathematician"): if you use (or dare to invent) "tricky" notation, imagine you had to read the formula to someone over the phone. Then you need to *name* and *pronounce* things, not just *write* them.
This also enforces a natural linear order on the representation, much like the sequence of characters in a file. On the other hand, most editors will represent it two-dimensionally, but it's not clear whether hard-wiring 2D into a language definition solves more problems than it creates. (So the Haskell designers were cautious and allowed to bypass the layout convention.)
It seems to me that the layout conventions work pretty well. I do not see much code where it is not used, so generally people must like it. And I personally, have newer experienced being confused about the block structure in Haskell. If this is just me or is general among people I cannot say. Also, there is a more theoretical argument why the C/C++/Java/... way of using '{', '}', and ';' is bad. Basically, your are defining your structure in two different ways. Namely, using indentation and using the '{', '}', and ';'. Two ways leaves room for inconsistency. And this inconsistency is unnecessary, as the compiler can and do deduce the block structure from the indentation. Compare this to both defining a function and commenting it. Here there is also room for inconsistency. But there is no way around it, as the compiler cannot deduce what your comment means and people need comments to understand the code.
With a few examples (sin, cos, log, ...), Mathematics has gone a long way to avoid multi-letter identifiers. Since there are only a few latin letters, it resorts to graphical (examples above) and calli-graphical resolutions (other fonts, boldface, italics, superscripts, subscripts etc. I think the \sqrt sign is in fact an "r" = first letter of "radix" = root)
From an "engineering" standpoint (readability, maintenance), this sometimes is questionable. See any software engineering textbook, section "choose sensible names for identifiers". By sticking to plain ASCII, we enforce longer (and hopefully more meaningful) names :-)
BTW, the Haskell standard itself does feature some unnecessary cleverness: abridged names like Bool, fst, snd just don't feel right.
As you also write, not all Haskell names are long and meaningful. Just look at (!!), ($), (.). And yes I do not like the fst and snd either. However, what I was trying to suggest was not to invent some completely new notation, but to use the most common math notation like square root. People already know this symbol, so no new symbols needs to be learned. What I also had in mind was things like case expressions and indexing. I think there are more people familiar with the subscript indexing than with the (!!). But how far do you want to take you long and meaningful names? Do you not also want some of the math symbol, like /, -, and + ? Or do you want to rename them divide, subtract, and add? As I see it, it is basically a balance between conciseness, intuitiveness, convention (and how know this convention is), and how often a particular function are used. The reason for turning to math symbols is that more people know math than any programming language out there. Also math is very concise. However, often not intuitive. This also means that I do think we should invent some symbols. Like the (->) used in function signatures. And we can live with the new notation, even though it is not intuitive, as it is used very, very often. On the other hand, I do not want to completely adopt math. The one letter disease is one thing I would not adopt and it is only tolerable in math, because math deals with problems of small scope. Whereas programming deals with problems of a much larger scope. As a side note, I think (but I am not sure) sticking to one letter comes from the implicit multiplier. If we are using a math function named 'sin', nobody can know if we are meaning s*i*n or are referring to the function 'sin'. So what we need to do is find the right balance (see two sections above). I do not know what the right balance is, but debating it here probably gives everybody involved a better idea. And I do think we could invent some kind of "framework", consisting of questions to be answered, that could help decide which symbols to use and which not to use. -- Mads Lindstrøm <mads_lindstroem@yahoo.dk>