Four tweaks to improve Haskell
Lessons learned—and easy solutions offered
As a company, Digital Asset derives a great deal of value from open source libraries, and we actively encourage our employees to use their DA accounts to share and collaborate with their peers by contributing code back to upstream projects that we use. This is particularly true when it comes to Haskell projects.
In the course of our work implementing Daml, we felt there were some things Haskell could do better—and so we went ahead and tried them! The ideas in this post are intentionally small but cumulatively we have found their impact to be quite positive. There are more changes that we made to suit Daml; these are the ones that we decided just had to be tackled first.
So, in no particular order and without further ado, here they are!
1. The “new colon convention”
If Haskell was designed today, ‘:’ would mean “type” and Hackage would be 1Mb smaller. We implemented an extension that reverses the roles of ‘:’ and ‘::’--that is, ‘:’ is read "type of" and ‘::’ as the list "cons" operator. Here's an example.
Yes, it's been proposed before. Our implementation builds on that proposal and addresses shortcomings with respect to warning and error messages. The proposal sadly was withdrawn though. We really think that was a mistake and it ought to be revisited. For the rest of this post we'll assume this extension is in effect.
2. Record “with” syntax
We didn't get around to proposing this one yet although it’s been part of Daml since inception. It is trivially implemented in just the parser but its impact on readability is profound! The idea is to introduce a new keyword with that can be used for record type declarations and updates. For example, instead of
you can write,
Or, since with is "layout inducing", that can also be written,or variations on that theme as appropriate. Similarly, for record updates, instead ofone can writeThis syntax places very nicely with the extensions RecordPuns and RecordWildcards but we'll not go on about that…
3. Inline function return type annotations
This proposal augments the ScopedTypeVariables extension to permit inline function return type signatures. For example, one can write
What’s interesting is that GHC has always parsed such signatures but merely thrown errors in a later phase—a good sign that they are a logical construct in Haskell.
4. Module qualified syntax
To import a qualified module you must specify qualified in prepositive position : import qualified M. In the Haskeller's eternal quest for alignment, this often leads to a "hanging indent". For example,
The syntax import M qualified is suggested in this proposal and implemented in this merge request, solving the hanging indent issue. The future of this one looks very favorable and is currently in the final stages of acceptance.
As mentioned in the opening of this post, there are more things we'd like to see upstreamed. In particular, we'd love to see the "no top-level record field selectors" proposal accepted. Implementation of that has eluded us so far however and our focus here is on the simple stuff.
We think the things listed above help close the gap on perfection and fervently hope they can make their way into Haskell.
Want to know more about Daml? Download the Daml SDK at daml.com and sign-up to receive notice of future blog posts and relevant information!
This story was originally published 5 May 2019 on Medium
About the authors
Shayne Fletcher, B.Sc. - Language Engineer – Daml Language Team, Digital Asset
Shayne joined Digital Asset’s language engineering team in 2018 where he works on the Daml compiler. Shayne has 20+ years experience with C++ and OCaml. He has a deep understanding of programming language theory and a wealth of experience in finance and building language based-products. In a previous role with Bloomberg, Shayne led the team that built the BLAN language for modeling exotic derivative securities. @shayne_fletcher
Neil Mitchell, Ph.D. - Daml Language Team Lead, Digital Asset
Neil leads the team responsible for the Daml Language. Neil has a Ph.D. in Computer Science from York University, where he worked on making functional programs shorter, faster and safer. Since 2008 he spent 8 years as a quant at Credit Suisse and Standard Chartered, before building a cross-asset risk engine as a Director at Barclays. Throughout, Neil has been taking the programming language techniques from his Ph.D. and applying them to get the same benefits in a commercial setting.
Neil is the author of popular Haskell tools such as Hoogle, HLint, and Ghcid - all designed to help developers write good code quickly. More recently Neil has been researching build systems with publications at ICFP and the Haskell Symposium, and a practical system based on those ideas named Shake. Neil’s home page. @ndm_haskell