[Haskell] Beyond ASCII only editors for Haskell

[Mads Lindstrøm]

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 at yahoo.dk>