[Haskell-cafe] Re: Richer (than ascii) notation for haskell source?

Yitzchak Gale gale at sefer.org
Thu May 15 04:33:50 EDT 2008

Brandon S. Allbery KF8NH wrote:
>>> Come to think of it, if you're after math notation, enough Greek
>>> letters are used as symbols that it might be necessary to just
>>> exclude them from use as letters.

Yitz Gale wrote:
>> While I have not yet noticed anyone from Greece on this list,
>> I don't think it would be appropriate for us to discriminate
>> against Greek speakers as a built-in feature of Haskell.

Achim Schneider wrote:
> /me shudders and tries not to remember those occasions when he read code
> written in french.

He he, yes. I've seen C++ written in transliterated Russian, too.
Very amusing - as long as I'm not the one who has to debug it.

> Code should be written completely in English, for practical reasons.

Yes, of course, that's the standard today for software development.
But I'm just saying that it would not be a good idea to
hard-wire that policy into our language syntax.

Just as an example - let's say you want to create an embedded
DSL for speakers of a language other than English.

The point is that it is always best to keep language syntax
as simple as possible, for many reasons. In the case of Unicode,
that means staying as close as possible to the spirit of Unicode and
minimizing our own ad hoc rules. Adding one more
keyword is way simpler than adding a bunch of complex
rules to the lexer. A lot less moving parts to break.
Especially if those lexer rules are not so consistent with
built-in Unicode concepts such as letter and symbol, glyph
direction, etc.

So I think the best and simplest idea is to make
the letter lambda a keyword. True, you need a space after it
then. You already need spaces between the variables after the
lambda, so anyway you might say that would be more consistent.
I always find my thumb hovering indecisively over the space bar
when I type a backslash "lambda" in Haskell.

Haskell syntax has always been inspired by mathematical notation
and reminiscent of it, never identical to it.


More information about the Haskell-Cafe mailing list