Joachim Breitner

Less parentheses

Published 2017-09-10 in sections English, Haskell.

Yesterday, at the Haskell Implementers Workshop 2017 in Oxford, I gave a lightning talk titled ”syntactic musings”, where I presented three possibly useful syntactic features that one might want to add to a language like Haskell.

The talked caused quite some heated discussions, and since the Internet likes heated discussion, I will happily share these ideas with you

Context aka. Sections

This is probably the most relevant of the three proposals. Consider a bunch of related functions, say analyseExpr and analyseAlt, like these:

GHC proposal that I prepared, and I invite you to raise concern or voice support there.

Curiously, this problem must have bothered me for longer than I remember: I discovered that seven years ago, I wrote a Template Haskell based implementation of this idea in the seal-module package!

Less parentheses 1: Bulleted argument lists

The next two proposals are all about removing parentheses. I believe that Haskell’s tendency to express complex code with no or few parentheses is one of its big strengths, as it makes it easier to visualy parse programs. A common idiom is to use the $ operator to separate a function from a complex argument without parentheses, but it does not help when there are multiple complex arguments.

For that case I propose to steal an idea from the surprisingly successful markup language markdown, and use bulleted lists to indicate multiple arguments:

Well, let me know what you think!


It is not the first time you talk about sections and I find them a reasonable and useful addition. I wouldn’t use the word section though, or we’ll get in a mess when discussing expressions like (1+)!

I don’t particularly feel the need for “bulleted arguments” (maybe because we already put the “very complicated code” in a where clause? I don’t know). The “enforce alignment” doesn’t sound a feature to me when tweaking stuff of debugging.

The “whitespace precedence” looks so easy to get and visually appealing! I am so amazed at its simplicity and wrote some Haskell in ghci off the top of my head to see if it “holds” (as in, if it doesn’t bite back in more complex examples). To my surprise it worked flawlessly and I really hope to see this implemented one day: I am far for proficient in Haskell, but if you need a helping hand, drop me a line!

#1 Francesco Ariis am 2017-09-10

I wrote section in the blog post just to vary the concrete (because it matters less than the concept) and to get Coq users on board. The ghc proposal uses the Isar-inspired syntax context fixes … where ….

Alignment enforcement is already ubiquituous in Haskell (top level definitions, do blocks, pattern matches) etc. I think it would go well.

Glad to hear that the whitespace thing stuff works so well :)

#2 Joachim Breitner am 2017-09-10

The language “Fortress” distinguishes between “tight” and “loose” operands when discussing mathematical operators. Fortress is a (now defunct) language that tried to revive the Fortran heritage for modern software design and high-performance computing, and as such, had a number of very interesting features that are now slowly being rediscovered.

Apart from distinguishing between tight and loose operands, it also introduced a latex-like alternative syntax for unicode that can make code both concise on a graphical terminal as well as readable in plain ASCII. And its module system (modules are called “fortresses”) offers features that sit somewhere in between Haskell Stack and Haskell Backpack.

See section 16.2 (page 101) on the Fortress language standard for details.

Regarding the original discussion – a compiler warning for (potentially) misleading use or lack of white space would be much appreciated.

#3 Erik Schnetter am 2017-09-11

I used the last idea in a Lisp dialect of mine. (search for ‘infix’). Ross Angle has pointed out to me that an earlier language called Merd has used it as well.

I think it’s a neat idea, worth having in a language designer’s toolbox. But I wouldn’t go past distinguishing between operators with spaces and operators without. Operators with 2 spaces vs 1 (or 7 vs 6) would be the devil.

#4 Kartik Agaram am 2017-09-12

I support your idea for using absent internal whitespace as implicit bounding parentheses

It is a notation I have been using for a couple years in my personal mindmapping.

#5 Jeffrey Brown am 2017-09-14

Have something to say? You can post a comment by sending an e-Mail to me at <>, and I will include it here.